Linux Containers Authors: Elizabeth White, Liz McMillan, Yeshim Deniz, Pat Romanski, Zakia Bouachraoui

Related Topics: Linux Containers

Linux Containers: Article

TURNER'S VIEWPOINT: Why Do Java Developers Like to Make Things So Hard?

TURNER'S VIEWPOINT: Why Do Java Developers Like to Make Things So Hard?

Usually, as Senior Editor of LinuxWorld Magazine, I restrict my potshots to complaining about how much work is left to make Linux a usuable desktop OS, or heckling SCO and Microsoft. But it's a little-known fact that I have an secret identity as a Java developer. So, for a change, I thought I'd take a potshot at Java.

First off, a caveat. I'm not some wet-behind-the-ears newbie who longs for Visual Basic. I've been coding in Java for over 5 years and have written 2 books on JSP development (MySQL & JSP Web Applications and Struts Kick Start, both from SAMS, run out and buy them right now). I'm a committer on the Jakarta Struts project. So I think I can claim I know my way around a polymorphism or two.

So when I say that Java developers seem to be in love with unneeded and confusing layers of complexity, I'm not say it from a position of ignorance. I'm saying it because I find myself frequently finding the Java way of doing something about 10 times as difficult as in other languages.

For example, I recently needed to automate encrypting and transmitting some files via FTP. Since I was already generating the plaintext file in Java, I figured it would be easy enough to tack on PGP and then send it. In fact, I already knew how to send it because I had other Java programs that did FTP. So all I needed to do was find a native Java PGP implementation, and sure enough, the Bouncy Castle folks had a native Java implementation free for the downloading.

Immediately, I ran into the thing I hate most about Java developers. They (as a group) are in love with how clever they can be. The Bouncy Castle code was a morass of Factories, multiple different classes that needed to be configured in order to make everything work right, and even at that I couldn't get it to work after a day of messing around. The mantra in Java seems to be to never hardwire anything, so that in the hypothetical "someday", you can rip out class X and put in class Y by just adding a Factory. The end result however, is code that's confusing to use, hard to maintain, and never seems to be very well documented.

In desperation, I turned to option 2, doing it in Perl. What a difference! One CPAN install got me the entire suite of packages I needed to make the Crypto::OpenPGP package work (and BOY could the Java community take a lesson from the success and good design of CPAN) The package was straightforward to use, maybe not the most elegant, infinitely extensable design possible, but easy to get up and working in 10 minutes.

I moderated a panel at COMDEX last fall where Rasmus Lerdorf (Mr. PHP) and a Perl proponent ganged up on the person representing Java, complaining about how slow it was and hard to develop in. I tried my best to help defend Java, but it was hard. The trouble is, I see their point.

Java is a great language. But for some reason, the Java community has decided to take it and make all the ancillary packages as complex and difficult to use as possible. It's like a racehorse that's had a wet bar and a hot tub mounted on it. The Perl folks have the right idea. Make supporting technologies that are simple to use, rather than so elegant that they become incomprehensible.

Imagine if the Perl cafe and Javahut were across the street from each other. You walk into Javahut, and ask to sit down. "I'm sorry," says the person at the door. I'm not actually the hostess, I'm a Factory class that can give you a hostess if you tell me what type of seat you want." You say you want a non-smoking seat, and the person calls over a NonSmokingSeatHostess. The hostess takes you to your seat, and asks if you'll want breakfast, lunch, or dinner. You say lunch, and she beckons a LunchWaitress. The LunchWaitress takes your order, brings over your food, but there's no plates to put it on because you forgot to get a CutleryFactory and invoke getPlates, so the Waitress throws a null pointer exception and you get thrown out of the place.

Dusting yourself off, you walk across the street to the Perl cafe. The person at the door asks what kind of seat you want, what you want to eat, and how you want to pay. They sit you at your seat, bring over your food, collect the money, and leave you to eat in peace. Sure, it's not the most elegant dining experience you ever had, but you got your food with a minimum of pain.

The long and the short of it is that, in my opinion, Java is a great language being destroyed by Rampaging Computer Science. There's a time for elegance, and a time for usability. If developers want to make the internals of packages flexible and extensible, that's all well and good. But the external interfaces should be clean, simple to use, and have wrappers for the most commonly accessed functionality. For example, in a PGP package, I should be able to encrypt or decrypt a file in 5 lines of code or less. After all, I can do it in Perl in 3.

More Stories By James Turner

James Turner is president of Black Bear Software. James was formerly senior editor of Linux.SYS-CON.com and has also written for Wired, Christian Science Monitor, and other publications. He is currently working on his third book on open source development.

Comments (55) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
James E. Ervin 08/28/05 09:08:21 PM EDT

I find alot to agree about with your posting and I am a Java partisan. I think part of the trouble is based on two things. Number one, almost everyone who is a Java programmer is a recovering C/C++ programmer. C/C++ programmers are notorious for being too clever, the language forces them to be. If you think I am kidding, take a look at the latest set of improvements that were made to Java 5.0, they are all about getting the C programmer. The next point is that almost to a man, we software developers do not understand that the best analogy to software development is not a factory, but writing. When someone goes about writing an article that is to be read by the widest audience possible, they don't use everything they know about grammar and all the words that they know. Take a look at the keyboard, there are alot of punctuation marks for which I am certain there are uses, do you use them? I sure don't. If java platform and api developers thought about their code and interfaces as an artifact of writing then they would start by making the purpose of the api clear and how to use it clearer.

Just my humble opinion,
James E. Ervin

Sean Ogden 05/24/04 05:57:37 PM EDT

Loved the artical and the comments.
Had to comment:
Did you get chopsticks or a knife & fork at the Perl cafe?

My opinion is these are not language issues, but cultural ones.

AKP 05/13/04 06:59:51 AM EDT

Just use the great, rich, and soooo easy to learn and use C#, VB.Net, or any other .Net language and I am sure you will not suffer ANY of this pain. Just take your pick... Gosh, you can even use COBOL if you are still stuck with that language and get similar great results. Go dot net.

krm 04/09/04 02:27:29 AM EDT

Making things overly complex means more job security for those that can still do it. Then more paid work later to modify it for new uses. Then more people will be needed to teach it. It is a money making proposition all around, with only a few idealistic but naieve people making it complex because it is fun to be able to keep all that complexity in mind and still make it work.

Einstein did say to make things as simple as possible (and I know he added "but no simpler"). You can waste a lot of your life on overly complex pursuits, even if you make a lot of money doing it. You make something very complex work, and gain a little euphoria from being able to do it, and from you being able to do it and hardly anyone else, but it is still a waste, and something much more productive could have been done.

So there is a lot of this making languages more complex than they need to be for job security and ego satisfaction. Then the rest of the people trying to use it are going to waste a lot of their time too.

If things are as simple as possible, more people will be able to handle them, and the general technical level of the whole country will increase. However, because of the desire to have financial security however it can be obtained, we have this over complexity situation. It is good for the programmers that can do it, good for teachers, good for professors, and bad for everyone else.

Stephen Strenn 04/06/04 11:53:12 AM EDT

Right on!

But allow me to argue that the Java community needs *more* design patterns, *not less*.

In particular, our libraries and packages need the FACADE design pattern. The facade sits atop our complex, powerful library, providing a very easy to use interface that lets 90% of us use the package with a minimum of fuss, but doesn't preclude the other 10% from accessing the flexibility provided by the underlying library.

So here is to a *new* Java paradigm - every new Java library must come with a facade!

Kieran Dolan 04/06/04 07:36:45 AM EDT

Maybe the real problem is the insidious creep of "patterns". Patterns are great aids to implementation design but often they seem to be used as an excuse for not thinking the problem through.

In particular, the excessive use of factories seems a real problem in Java. Frequently I see a factory that has only one implementation and returns only one type of object. If we take a simple API, add a factory, an interface, its concrete implementation in a class, a factory interface, a factory implementation class and possibly add in a "factory factory" with its implementations, a single API has bloomed into a complex system. Multiply this by 10 or 20 and we have an unusable system and a maintenance nightmare !

TX 04/06/04 05:37:01 AM EDT

Something tells me a simple form submission wouldn't require 200 screens either.

Also MVC model 2 doesn't necessarily result in three files per screen. Firstly, you usually only need to make the model and the view, since the controller is done by whatever system you are using (e.g. Struts.) Secondly, multiple screens can be done by having multiple views to a single model (this is actually one of the points of using MVC in the first place.) If you put one file per screen then you will quickly find code bloat, which you would agree is bad.

George Costanza 04/06/04 01:56:08 AM EDT

I think James Turner is right on the nose with his article.

Java makes it easy to write OOP and so developers take on this holy journey of abstraction/patterns often burying the actual problem to be solved within several layers of unnecessary (at times) wrapper calls.

I am not against good design, but it should not mean "code bloat". Part of the charm of languages like Perl, PHP, C is that you write succinct code to get the job done.

Take MVC Model 2 for example, great pattern but its 3 source files. In a large project with 200 screens, I am looking at 600 source files. Is that really necessary for a simple "form submission"?

Robert Wilson 04/05/04 11:59:05 AM EDT

1.1 What Is ColdFusion?
In 1995, J.J. and Jeremy Allaire introduced a product they believed would revolutionize application development for the Web. They too called their creation ColdFusion. The two brothers formed the Allaire Corporation and began selling ColdFusion. Unlike its infamous namesake, ColdFusion has delivered on the promises put forth by its creators. In 2001, Macromedia acquired Allaire, and along with it, ColdFusion. ColdFusion MX represents the second ColdFusion product release under the Macromedia banner.

According to Macromedia's marketing materials, ColdFusion is "the rapid server scripting environment for creating rich internet applications." Internet applications exist as a collection of pages, also known as templates, which work together to allow users to perform such tasks as reading email, buying books, or tracking packages. Internet applications often act as the front-end to back-end services, such as legacy applications and databases, and can be accessed through various means such as web browsers, cell phones, and other Internet-enabled devices. Some examples of web sites and applications built using ColdFusion include Autobytel.com's application for researching and purchasing a car (http://www.autobytel.com/), Williams-Sonoma's storefront application (http://www.williams-sonoma.com/), and the online reservation system at the Broadmoor Hotel's web site (http://www.broadmoor.com/).

One key aspect of an Internet application is that it is dynamic; it is not just a static collection of pages. The benefits of dynamically driven design are obvious. If you think of it in practical terms, which would you rather do each time a new press release has to be added to your web site? Would you rather the marketing department send you the text for the new press release so you can convert it to an HTML page, upload the page to your server, then go add a link to the menu of available press releases? Or, would you rather provide an online form to the marketing department so they can enter the text from the press release themselves and store it in a database that can then be queried to dynamically build the press release menu and associated pages? ColdFusion allows you to create just this kind of application.

Of course, there are a lot of different technologies you can use to create dynamic applications, from open source technologies such as Perl/CGI scripts or PHP, to such commercial options as JavaServer Pages and Java servlets or Microsoft's Active Server Pages. With all these choices, why use ColdFusion MX?

One reason has to do with ease of development. Unlike most of the other technologies I mentioned, you don't have to be a hard-core programmer to get started with ColdFusion. This doesn't, however, mean that ColdFusion isn't powerful. Quite the contrary. ColdFusion makes it simple to do common tasks, such as processing form data and querying a database. But when you need to perform more complex operations, such as transaction processing and personalization, ColdFusion makes that possible too.

ColdFusion is also designed for rapid application development (RAD). ColdFusion abstracts complex, low-level programming tasks, such as establishing connectivity with a mail server or querying a database, with simple HTML-like tags. The result is an application development cycle that is second to none.

Another advantage of ColdFusion is that it is available for a broad range of popular operating systems and web servers. ColdFusion can be run on Windows 98/ME/NT 4/2000/XP/Server 2003, Linux, Solaris, HP-UX, and the AIX operating system. Additionally, the developer version of ColdFusion MX Enterprise can be deployed on Mac OS X when the J2EE configuration is used. ColdFusion works in conjunction with several popular web servers including Microsoft IIS, Netscape Enterprise Server, iPlanet Enterprise Server, Apache, and ColdFusion MX's standalone web server. In general, you can migrate ColdFusion applications between different operating systems, web servers, and databases, for instance, when you upgrade your databases for scalability purposes. There are, however, some minor incompatibilities between platforms (i.e., there is no COM support in the Unix/Linux version of ColdFusion). Although minor for the most part, these differences are explained in relevant sections of this book.

ColdFusion MX is also an integral part of Macromedia's overall MX product line, which includes Dreamweaver MX for authoring, Fireworks MX for web graphics, and Flash MX for developing rich user interfaces for Internet applications. As Macromedia's cornerstone server product, ColdFusion MX is tightly integrated with the rest of the MX products.

ColdFusion is a mature, robust product; the current version as of this writing is ColdFusion MX 6.1. When ColdFusion was released in 1995, it provided simple database and SMTP mail connectivity and supported basic output formatting. Each successive release of ColdFusion has added features and functionality. Today, ColdFusion contains over 90 tags and 265 functions for handling almost any task imaginable. Add to that scalability features such as load balancing and failover to handle high-traffic sites, and it is easy to see why ColdFusion is so popular among developers and administrators alike.

There is a vibrant community of ColdFusion users who are active both in shaping the future direction of the product and in supporting others who use it. A number of ColdFusion-related conferences are held each year by both Macromedia and members of the developer community. Macromedia also runs several web-based forums and Usenet-style newsgroups, where developers can post and answer questions related to ColdFusion development (http://webforums.macromedia.com/coldfusion/). The forums are monitored by Macromedia support engineers as well as a volunteer group known as Team Macromedia. In addition, Macromedia sponsors a number of user groups around the world. Known as CFUGs (ColdFusion User Groups) and MMUGs (Macromedia User Groups), these groups provide a place for ColdFusion developers to get together and share information on a variety of ColdFusion-related topics. Finally, there are a number of web sites devoted to furthering the ColdFusion community. For a complete list of community resources, see Appendix D.

Zing 04/04/04 09:40:21 PM EDT

Whoops. Obviously a typo there on the last line of code. Just try to ignore that. :-)

Zing 04/04/04 09:39:06 PM EDT

Executing GPG from Java is only hard if you want to use the native Java API. Of course if you were like the rest of us, and had a utility class lying around which took an input stream for the input to a program and an output stream for the output to a program, you could do the sane thing and exec "gpg", capture its output, and so on.

GPG really isn't going to be a simple thing to use any time soon. But I guess we could make it somewhat simpler, because in an ideal world:

InputStream src;
OutputStream dst;
GPGKeyStore ks = GPGKeyStoreFactory.create("somewhere/pubring.gpg");
GPGKey k = ks.getKey("0xFFFFFFFFFFFFFFFF");
GPGEncryptor enc = GPGEncryptorFactory.create(k, src, dst).encrypt();

So I guess the question is, assuming the BC implementation is at least as difficult to use as the Cryptix implementation, why wouldn't you just write a wrapper class which *does* work this way? In reality, you will want to cache the KeyStore and possible even the Key objects, otherwise you will be hunting through the keystore every time you use it. Right?

Horacio Lopez 04/03/04 05:45:58 PM EST

Mr Turner,

I couldn't agree more with you about Java.
On the contrary, dissent on your remarks about Perl and how well its CPAN is constructed.

Fortunately, for a bunch of us who don't want, or don't need to be told what to use, there's something in the middle.

The Ruby programming language was created handy and easy to master as "A better perl" still being Object-Oriented as in a "better Smalltalk".

There's no lack of other languages, there's also Python, and more recently Groovy, I just personally prefer Ruby because of the handy RAA (Ruby's version of CPAN raa.ruby-lang.org) Rubyforge.org (Ruby's version of sourceforge) the great *libre/free "Programming Ruby" book, and the amazing friendly community that has been built around it (check out irc://freenode.net/#ruby-lang)

As if it wasn't enough with that, there's JRuby, which is a Java-based implementation of the Ruby language that lets me access Java objects from within my Ruby application.

A breeze.

Perl is an aged language now, in process of being completely rewritten, borrowing features from Python and Ruby.

If anyone wants to discuss this, please contact me
vruz ( A.t) digipromo (d.ot) com

No flame wars please, just willing to help here.

E Nishada 04/02/04 04:01:18 PM EST

I have been writing software in Java for about 6 years now. Java does have its warts but due to its simplicity, garbage collection and useful set of standard packages, I switched from Smalltalk to Java. Besides, Smalltalk jobs disappeared pretty fast. As I see ever more complex packages and APIs that don't always work well enough, I have been pushing for Java + a few packages as the implementaion tools and it has worked well for us. If you stay away from EJBs and other complexities, I think you will be fine.

I think the real issue behind Java's complexity (Java packages really) is overuse of design patterns. Design patterns have a context that is routinely ignored and applied where it is unnecessary. Where I work, we had to abandon the entire codebase developed by a team and rewrite it with KISS principle for performance and understandability. Sure, the abandoned code was full of beautiful pieces, *all* the GoF patterns were faithfully implemented, everything had a factory, implemented a number of seemingly useful interfaces, had an abstract class and implementation. But reading a single object from the database required complex and expensive gyrations. The end result was that the team which worked on this highly flexible framework felt they needed to refactor it even more and finally blamed it on the lack of clear specifications for the product.

While design patterns are a great idea (in a previous life, I evengelized them and mentored people on its use), they can easily fool people into thinking that they are doing the right thing by following them. The overly general Java frameworks will work okay for average use but for applications with severe constraints (performance or volume or both), I find that the stock packages of Java don't always cut it. Anyone ever tried XMLEncoder and XMLDecoder with a large number of objects? Or how hard the author/s tried to make it work?

I think the competant ones are recognizing the folly of Java's complexity and rejecting them. The recent converts to OO and design patterns are forging ahead creating ever more complex beasts. But not to worry, things have a way of getting sorted out. People will balk at all this complexity and the pedulum will swing the other way soon!

David 04/02/04 01:07:41 PM EST

Bravo. I'm a longtime Java programmer since the JDK 1 days and it's only gotten worse. You should see the XML DSign APIs! What a joke. I have an XML doc, so I should just do something like say, sign("/doc/part"), or if I need to sign 4 or 5 fields, I would be okay with something like:


But it's never that easy, yet 99% of all programmers want to do that.

The entire DOM API for XML makes working with XML nearly impossible, yet XML is such a simple and elegant format.

EJB is another joke. It's shame because it's FINE to have that complexity UNDER THE HOOD, but it's downright ignorant that we all have to write wrapper classes that hide all that complexity.

Go figure! At least it lets me get paid more than I should for doing a job that really shouldn't be that hard.

Ivan Handler 04/02/04 12:31:26 PM EST

Very good article. I recently went crazy trying to integrate JaXB into a project. Luckily I found JiBX which does the same thing but without all of the unnecessary complication.

Java is a good language to program in and it can be very clean and elegant, but you need to be careful what packages you use and how you create them.

I have been writing code for over 40 years, every language has its strong and weak points. If used properly, I find that Java is far more elegant and clear than most other languages. It can keep you focused and doesn't have a lot of syntatical constructions to learn (as in Perl) or backend ways to corrupt your structures (as in C++).

I do think the tendency to overgeneralize is present in many programmers. I think some of it is sheer arrogance, writing code as if it is going to be used in the most general circimstances rather in the specific circumstances the programmer is confronting smacks of someone who is trying too hard to show how knowlegeable they are.

True knowledge is shown by solving the problems at hand elegantly. If the circumstances change, most likely some rather basic assumptions will change with it and instead of a few classes having to be rewritten, a bunch of interfaces, classes and factories will have to be rewritten. Trying to second guessing the future usually doesn't work in my experience.

Dave T 04/02/04 10:12:31 AM EST

I couldn't agree more. We had a tight group of developers who wrote simple fast reliable code in Java. Then we hired one of these "flexibility" guys, and he spent weeks re-writing code to be "flexible". Finally the conflict got too great and he quit. Now we are spending time re-writing the code back to how it was originally written. We haven’t used any of his so-called improvements, and I’ve had more than one person come to me and say “When I wrote the code in this package, it provided this functionality, now I can’t tell how it’s doing that.” And we have to go into the 36 classes that replaced the 3 that originally made up the package and figure it out. 36 classes means more code, more bugs, more headaches.

Keep it simple until you NEED to make it complex. Then only add complexity for BUSINESS reasons, not ego, and not elegance. More harm has been done in the name of elegance than most people realize. Elegance that provides functionality that is USED is good. Elegance for elegance’s sake is just ego and stupidity.

Honestly, this is some of the reason for off-shoring. Many programmers think if they solve a problem using code they deserve an “A”. If you code the solution to the problem the business guys described you get a “D”. Now do all of the work to handle the real world. File transfer problems. Ability to re-send a file. Tracking what was sent.
Handling users who click submit and then realize they need to change something. Not to mention deadlocks, transaction timeouts, power failures, etc. If you can’t kill an update process and then re-start it without editing the input file or database tables, you really haven’t written code that a real human being can operate.

the real difference 04/02/04 09:45:05 AM EST

They're both the same and they both suck.

In our day jobs we have to do this:

for (int i = 0; i < collection.length; i++) {
result += somefunc( collection[ i ] );

and when we play air guitar we do this:

(set result (apply '#somefunc collection))

jeremy lightstone 04/02/04 12:22:31 AM EST

I will not profess to be a super programmer.
I understand the finite/logic concepts, i am observant,
and i wud rather do other things than code and find error.

All comp lang r difficult cuz too much complexity, comp geek egos, and the human condition to make silly mistakes(++many:). Let's stop telling eachother how long is our schlongScript, and make comp progs that work and help ppl, while keeping us sane + excited. GarbageCollect the complication.

My quick thoughts as an artist and a semi-programmer.
Perl is too criptic, Java has too much typing and seems to push data all over a program. In the end most OO programs are semi-procedural, and most scripts(ie.PHP/CFM) r trying to be OO. I have reviewed a national adservers using full perl and their system was impressive, however, Java just seems be heading towards a bigger standard and offered by more software providers.
Anyways i m now getting complicated in my writings.. Bye for now. jrl http://artsandtv.com/jrlightstone/

Trevor 04/01/04 11:58:20 PM EST

Design is the art of making decisions.

I think that developers often add needless complexity to their code because they aren't willing to choose between alternative designs, or to consciously limit and restrict the functionality of a library. I don't think this is a symptom restricted to only Java, although it may be more prevalent in Java than Perl because Java programmers, IMHO, tend to be slightly more idealistic than the more practically minded Perl programmers.

Overall, I don't attribute bad design to the language, but to the APIs and coding standards developed around that language. I've always found Microsoft's usage of C++ to be highly confusing, while Unix's to be relatively easy to understand.

Scritchy 04/01/04 07:03:48 AM EST

Perl to Software Developers as Gaffa Tape is to Roadies.

Jack Herrington 04/01/04 01:20:48 AM EST

This is not a troll, Turner knows what he is talking about and he is spot on. If you think it's a troll it's probably because you have never tried Perl. The majority of engineers that I know who hate Perl do so in complete ignorance.

Perl is a fine language that is only getting better, and the CPAN is an amazing resource that has an inertia that is unmatched in any other language community.

alexxa 03/31/04 09:20:50 AM EST

TWO WORDS: Regular Expressions

Doing regular expressions in Java is about as complex as writing the regexp parser yourself. Perl? I've never used anything simpler. I'll never forget how excited I was with the advent of Oromatcher - and then so disappointed. How cumbersome!

I love Java, but perl is my soulmate.

a 03/31/04 04:53:54 AM EST


Aaron Trevena 03/31/04 03:24:05 AM EST

As I said earlier, Perl is perfectly suitable for medium to large projects (say 10 to 40 developers, only because I haven't seen it used for larger stuff than that myself).

As much as I love Perl I probably wouldn't try to build the next OpenOffice or Air Traffic Control with it. However I would be more than happy to build significant Business Applications with it for Financial Transactions, Internet Infrastructure, Data Mining, Web Everything, Problem Solving, XML and Data processing, etc.

Despite working with perl for years I have not actually seen very much bad perl. Even the worst perl I saw in a work context (a cgi script that didn't work with Apache::Registry) was fixed in under 20 minutes. If people are seeing others get their job done in perl and are unhappy with the code, they can either improve it with modularisation, some OO (if necessary) or ignore it (perhaps those scientists, etc just needed to get something done once - afte all if it aint broke, don't try fixing it).

Something that nobody has mentioned so far is the ability to utilise C++ and C libraries from perl. This gives Perl developers the opportunity to lean on a vast resource of proven code. I already use many C++ libraries in our perl like Xerces (the Apache XML processor) for XML, OpenSSL for Crypto, etc.

And as somebody pointed out most Complex Libraries can easily be wrapped to simplify them for common cases - I have wrapped Both Xerces and SOAP::Lite's SOAP::Date/Header libraries so that I can produce high quality code quickly and easily.

As for the FUD about not being able to get what you want from Cafe Perl - that is nonsense - perl is not like fast food (thats more PHP and ASP), it is just eclectic and grows to include what people want - be it the Maypole MVC equivilent to Structs or Plucene Lucene port or Traits or Logging or Design Patterns.

So far the only thing I have wanted that Perl doesn't provide is an ebXML MSH and I have already built a prototype and got it talking to the Java Hermes MSH, hopefully we can port most of what we need into perl quite quickly, and if not we can still use Hermes through INLINE::Java until we migrate fully to perl.

Java has lots of good elements, but there are many places (and not just small or web oriented projects) where Perl is a better tool for the task.

has 03/31/04 03:18:10 AM EST

"Java is a great language being destroyed by Rampaging Computer Science"

(The high-pitched whine you hear is the sound of Prof Edsger W Dijkstra spinning in his grave...)

Rane 03/31/04 12:40:44 AM EST

If think this article has a solid point. OO-believers tend to make things much too complex. Why facilitate all possible changes while only 1% of the changes will ever be needed. Code gets complex and utilisation takes time without any benefits.

Scott Ellsworth 03/30/04 03:40:34 PM EST

> The lesson people should carry away from this article, I think,
> is that it's way easier to write bad Java than it is to write bad Perl.
> (And oh, I know it's possible to write bad Perl, believe me.)

I have had exactly the opposite experience - I have found it far easier to write crummy Perl than crummy Java at equivalent levels of expertise. The Perl masters I know write excellent code, as do the Java masters I know, but I have seen far more unmaintainable crud written by the Perl tyros. Perhaps this is sampling bias based on the beginners I have seen - those starting out write crummy code in most languages until they learn better. Mentoring helps, code reviews help, XP helps, but in the end, they have to learn the expert moves, and that takes time and effort.

A better lesson to carry away, IMO, is that you cannot afford to be a slave to backwards compatibility, just like you cannot afford to ignore it if someone depends on it. Library design is tough, and deserves your best people, but many organizations put library design in the hands of unproven new hires. This causes a problem.


alcazar 03/30/04 03:23:42 PM EST

The lesson people should carry away from this article, I think, is that it's way easier to write bad Java than it is to write bad Perl. (And oh, I know it's possible to write bad Perl, believe me.)

I administer a sprawling, GUI-managed Java app. Damn, I wish my satisfaction was guaranteed with Java! Instead, I literally have nightmares about administering this app.

See also http://www.itweb.co.za/sections/software/2004/0403191257.asp?A=APD&S=Sof...

How come all the Java defenders can't spell? :)

Ian Bicking 03/30/04 03:09:56 PM EST

I'm seeing in this discussion a conflict between those who think You Ain't Gonna Need It, and those who feel, well, otherwise.

Perhaps this philosophical and cultural difference can be tracked back to the communities themselves. In Perl (or Python) if you have a library that is too simple, you *change* it. This works because all the sort is exposed and people are used to the open source feedback cycle where libraries are generalized on an as-needed basis.

This doesn't work nearly as well with black box components and close source methodologies, where lack of generality can often stymie the programmer. So it's understandable that people would protect themselves with more generalized libraries.

Just another way of phrasing Cathedral and the Bazaar, I suppose.

Timm Murray 03/30/04 02:56:35 PM EST

Randy, have you ever done crypto in Perl? Just look at the documentation for Crypt::CBC: http://search.cpan.org/~lds/Crypt-CBC-2.08/CBC.pm. The synopsis is 16 lines and contains everything you need to encrypt and decrypt an existing string or open a file and encrypt its contents. You can even shorten it by 4 lines by only passing the 'key' and 'cipher' params to the constructor (the other parameters have perfectly reasonable defaults).

The equivilent Java requires getting the right values to java.security.Provider, loading your java.security.KeyStore or java.security.KeyFactory (depending on if you want to use an existing key or create a new one), getting a java.security.Key instance, getting the needed javax.crypto.Cipher instance from your Provider, and encrypting with that. (I hope I got all this right--it's been a while). That's 4 classes to deal with compared to Perl's 1. And don't forget to explicitly specify the type of padding you need, because Lord forbid we should have sane defaults.

Also, one of Perl's points is that if you make good use of the language, you should avoid needing to write 1000 lines of code in the first place. Don't blame the langauge for failure to modularize.

Randy Poznan 03/30/04 01:56:07 PM EST

What a bunch of whiners. Java is simple, works, and can do compilcated stuff cleanly. Try to do Perl crypto or anything complicated. OR what do you do when your perl cgi is >1000 lines and you have to debug it. Java is great for integrating with complex API's of working ready to run code. It realizes the OO dream of building blocks for applications. And all tools to develop/deploy range from completely free gnu to expensive commercial products. Your arent locked in you have alot of choices and freedom and you can put together complex stuff rather quickly.

Gandalf 03/30/04 01:08:25 PM EST

I agree with the author about the complexity of Java language. It comes with the richness of java.

The authors compares perlcafe and javahut.
One difference. perlcafe is a cheap fast food restaurant.
You can go get your food very quickly, sit wherever you like. And your choice of food is very limited. Drinks even more limited.

Where as, javahut is a rich dining experience.
You might have to wait for a long time to get a seat.
You can take your own time, order wonderful customized food and drinks. Satisfaction guaranteed at javahut.

Gandalf 03/30/04 01:06:28 PM EST

I agree with the author about the complexity of Java language. Complexity comes with the richness of java.

The authors compares perlcafe and javahut.
One difference. perlcafe is a cheap fast food restaurant.
You can go get your food very quickly, sit wherever you like. And your choice of food is very limited. Drinks even more limited.

Where as, javahut is a rich dining experience.
You might have to wait for a long time to get a seat.
You can take your own time, order wonderful customized food and drinks. Satisfaction guaranteed at javahut.

Scott Ellsworth 03/30/04 01:01:46 PM EST

I agree with Cay - the problem is not the language but the number of APIs. Further, a great many of these APIs never get beyond effective 1.0 releases, which means that any lessons they learned about overuse of factories, crummy naming conventions, and the like never get resolved. There are gems in the libraries, too, which make up for the bad ones. Further, there is a fairly vibrant community of Java folk, just like the vibrant Perl community, which means that both languages will continue to evolve to meet actual, not perceived, needs.

Besides, crufty APIs are a problem in the Perl world as well, especially since "TMTOWTDI" usually gets implemented as "There's Several Crummy Ways To Do It, and Perhaps One Good One, But Good Luck Finding It". I believe this comes from the majority use case of Perl - hacking a solution in a day or two, rather than components of apps that get extended for years. (I know there are Perl apps that get maintained for years, but these seem to be the exception, based on the Perl scripts I see our scientists, engineers, and IT folk generating.) If a CPAN module works for the majority of the simple cases, it is going to look good, because you do not see the problems for a while.

I know both languages, and Python to boot. I spent a year coding up a server app in Perl, and found some good spots, but some bad as well. As an illustration: if you want Perl-to-Perl SOAP, it is pretty easy to just dump objects on the wire using SOAP::Lite. If you have a WSDL that allows Java and C# to talk to each other, though, and you want to add Perl to the mix, you have entered the way of pain. (It may be better now - this was in December.)

Would I use Java to code up a problem I wanted solved in an hour? No. I probably would use Python or Perl. Would I use it to solve a problem I expect to take a couple days to a couple of months to solve? Yes. It will get solved fastest that way, and the solution will grow to what the problem becomes over time.

In other words, while it is easy to point at bad spots in the Java APIs, there are corresponding icky areas in most languages. By sheer usage, though, it sure looks like Java is a good solution for an awful lot of problems.


Steve Holden 03/30/04 12:33:22 PM EST

I sometimes (jokingly) say "Java is object-oriented COBOL", but in fact that's a bit unfair to COBOL, which did allow you to do simple things simply, and had useful formatting features. Java has definitely suffered from bloat, and from the inability or unwillingness to admit that some API design decisions were wrong and correct them.

Mr T 03/30/04 12:26:42 PM EST

The reason why Java will always be preferred over Perl is simplly Easu of Use. Yes Java is not oerfect but its easier to get into. I think ppl who do PERL do it just to show how smart they are. The truth is that PERL is sooo BUTT UGLY, responsible for many terrible CGI scripts.

Most of these PERL advocates are sooo out of touch.

Alex Blewitt 03/30/04 12:11:05 PM EST

I've got to say, one of the most spot-on articles I've read recently -- and I'm a Java developer.

A lot of problems have evolved into Java, becuase it was done the Wrong Way first of all (Bloch's got a lot to answer for) and then never changed. You only have to cringe at the Date class to see why.

Unfortunately, Java's mantra is 'Backwardly compatible: always'. They could (should!) have fixed Date when they went from 1.0 to 1.1; or even 1.1 to 1.2. Now it's way too late to do anything other than come up with a new class (hello, GregorianCalandar) and they still screwed that one up.

Then you've got wonderful design decisions like the Collections API with methods like 'size()' instead of 'getSize()' because Block didn't want to type the extra three letters. And this was after the JavaBeans spec came out -- so everyone has to hack 'size' specifically for collections in a JavaBean (JSP) environment.

And thanks to Sun's great marketing ability, the Java 2 mantra (hey! We've got a real programming language now!) in 1997 has effectively buggered up Java ever getting past 1.x -- unless it leaps to Java 3.0

The big problem is that everything is still backwardly compatible, to the exclusion of refined design. One thing that many other languages (Perl, python, ruby to name but a few) have as a major advantage is they evolve. Sure, older stuff gets broken, but it's not painful to make the switch. And stuff improves.

Personally, I think Java got a lot of things right, and it really helped kick off the platform-compatibility and VM support that we've come to expect of a current language. But I'm pretty sure that someone's going to fix Java's problems with a new language pretty soon ...

Cay Horstmann 03/30/04 11:29:26 AM EST

Boy do I feel your pain! I am writing a book on JavaServer Faces, and I have to go through this stuff all the time. Only, in JSF, you first need to use the FactoryFinder to get a CutleryFactory.

I don't think that Java is the issue. Java is just a language. I think it is programmer insecurity. It takes courage and experience to put out a clean and simple API. The weaker designers will waffle and say "well, who knows, I really don't know this domain all that well, and maybe someone, somewhere will want to do something that my API can't handle. I'll just cover my butt and toss in a factory."

Why do you see all that mediocricity in Java APIs? It looks to me as if more APIs are published in Java than in any other language. A good fraction are bound to be bad, following the rule of thumb that 90% of everything is crap.

I think it is unfair to call mediocre API design "computer science". Computer science has given us many useful concepts and tools and doesn't deserve the insult. If you must use a derogatory term, how about "software engineering" :-)

Both sides of the story 03/30/04 10:12:57 AM EST

Right on.

Swing and EJB being the most frequently cited offenders in this regard, but (sorry) Struts is also up there. I might want to add another statistic here.. On CPAN, look at the number of modules which have "Simple" tacked onto them. More often than not, those are actually wrappers "around" existing (already easy to use, IMHO) modules.

My particular trauma happens to be HTTPClient (2.x, I like 1.x a lot) vs LWP in Perl. Any metric you like, number of lines to code, amount of time to get started and finish a job.. Perl seems to be better. I have more years experience programming Java than Perl, but as a general plea, save the complexity for people who *really* need it. Most API designers would be surprised at how many just want to get in and finish the job.

Charles Miller 03/30/04 08:42:35 AM EST

There are two sides here.

Java libraries are over-complicated in the sense that they often don't make the easy things easy. Developers need to look very carefully at the most obvious uses of their library, and shorten the path for writing those applications to the fewest number of lines of code they can.

On the other hand, programming for extensibility is a good thing. I've been working on a significant commercial Java application that uses Velocity to render its web-pages, and there's very few of its extension-points we _haven't_ taken advantage of so far. If Velocity didn't have all those factories, pluggable resource-loaders, replaceable caches and so on, we'd have pretty much had to fork the codebase to fit it into do what we wanted it to do.

David Mohring 03/30/04 06:13:40 AM EST

Higher level Java libraries suffer from the desire to be frameworks.
Higher level Java frameworks, from J2EE to even Struts, suffer from the desire to become the codeing equivalent of double entry bookeeping.
Higher level Java code generation tools, such as XDocklet , suffer from having to generate code that has to fit into all the above.

The result? In comparison to the single or dual layered PHP and .NET's pet shop type solutions, the current Java multi-layered solutions are more complex. However, the layered Java solution can also be easier to customise and maintain a common code base for multiple customers.

That does not mean that the resulting chaotic collection of Java libraries, frameworks, generators and abhorrent
aberrations ( such as aspect orientation, which is a good idea by itself, but mixed with the above is a disaster ) could not be improved by a massive global refactoring imitative.

The Great Renaming of Usenet started July 1986 and ended in March 1987 ( http://www.vrx.net/usenet/history/rename/ ), utter chaotic collection of namespaces was refactored into a relatively orderly hierarchy. It could be possible to hammer out in a similar massive flame fest a global open source functionality framework for Java.

Dump Sun's core J2ME,J2SE and J2EE libraries along with a collection of open sourced code covering as much as possible functionality into one pot. Make it accessable under a common LGPL type free license. Then refactor the hell out of it and endure almost a years worth of flamefest fighting to produce a hierarchy of standard code bases of much less complex to use code, frameworks and tools.

For such a massive undertaking to be successful, it would require a similar benign *non-political* dictatorship as has been managing the development of the Linux kernel.

New coding techniques that promise more productive development, such as aspect orientation, begin to make much more sense when the code you are "hooking" into is much less complex.

mch 03/30/04 06:03:36 AM EST

This has to be a joke:
"I wonder exactly why he could only come up with a single example of a hard-to-use library? Maybe because all the others were very easy?"

Java is a vast improvement on C++ - for example, it makes it much easier to integrate team work. And it can run fast. I've been doing Java for 7 years and I like it. C# has overtaken the language in many areas, but IF Java 1.5 can gain momentum it will be make up some ground. But the Java API's have always been a disappointment.

The API designers were spread to thin - Java was going to be the one true language to rule them all - forget your old OS, browser, spreadsheet, business app, 3D app - java will do all. The libraries for all these areas suffered from being developed too quickly to target too many different objectives. As a result, all the API's started off clunky. It hasn't always been possible to dig them out of the mess they started in - instead multiple API's were added to the mix. Many mistakes were made -

AWT - oops - better try again
- API too complex - jtable was a nightmare.
- still quirky today.
- made the big mistake of going "lightweight".
EJB - API and configs too complex
- huge learning curve
- system architecture too complex for most small business
apps (such as a pet shop).
- oops better add local interfaces.
OS integration API
- being able to call native isn't enough.
- not needed because JavaOS would win big.
- took them a while to get that right - and now we've got a
bunch of confusing overlap.
JSP - JSP+Servlets - JSP+Servlets+Templates - Server Faces
- Would the real way to do web pages please stand up.
- Server faces look good - but is it too late.
- but everyone seems to stuff this one up.

The API complexity has been further compound by a vast number of different attempts by Java developers and to fill the gaps. I don't know how many different ways there are to build web pages with Java.

Java today is just too much of a learning curve for new players - there is simply too much ground to cover. New players can find their projects dominated by technology selection and integration issues instead of application design/development issues. Java needs a focused set of API's - a Java-Hotstuff edition with only the new/good stuff - Language version 1.5, Java Server Faces, Java Data Objects, Local and Remote Session beans (only), Swing-replacement, Collections Classes (only), rich OS integration API, ...

Colin Froggatt 03/30/04 03:23:49 AM EST

As a long term Java developer (7+ yrs) I like java and the power it give you. But as with all things powerful, it can be abused. This article brought to mind two quotes:

Make everything as simple as possible, but not simpler.
(Albert Einstein) [1]

This author apologized for writing a long document which he had `not had time to make short.'
(Jean de la Bruyère (1645-96)) [2]

So, code that needs to be flexible may also need to be complex, but you should then spend the time to make it 'short' with a usable API.

In my experience the complexity is the 'exciting' stuff and the 'usable' API is often harder and gets over looked. After all, if you've been immersed in the code, its the easiest thing in the world to use so why should anyone else have a problem with it!

Nice article James.

cheers, Colin

[1] http://www.brainyquote.com/quotes/quotes/a/alberteins103652.html
[2] http://pages.ca.inter.net/~jhwalsh/quote.html

Aaron Trevena 03/30/04 03:03:17 AM EST

The anonymous perl proponent was 'Gnat', I found this article through this blog.

I have used Java briefly (set up Tomcat to run stand-alone JSP application, swing client to a server application, used the java freebxml ebXML MSH) and am aware of how it works, but each time I sit down to code in Java, I get frustrated with the lack of results and return to perl.

Its not that I don't know OO - I have written enough C++ and smalltalk to know how to design my classes and where to inherit what. I also know enough perl to build an OO application with all the design patterns I need as well as logging, configuration, etc.

Anyone who claims you can't build large perl project hasn't tried it. I have made a living for 5 years building large perl projects and they have frequently been delivered on time and on-budget. I have worked in teams from 3 to 10 programmers as well as designers and project managers delivering perl solutions and the only thing that is hard is merging more than 3 CVS branches - but I'd like to see any Java or Python or Ruby Hacker merge 3 CVS branches quickly and correctly.

My current place of work is using perl to deliver a complex N-Tier web application providing multiple web interfaces as well as multiple web services as well as proprietary client/server support. We use a self-built UML->code tool that autogenerates Javascript and Perl classes, we have test scripts and logging components. Tell me why we should move to Java? what can it offer that Perl doesn't - I know we could take on 4 more programmers and Perl wouldn't be a problem (we haven't even needed to resort to coding standards - just common sense), the only problem would be ensuring that the critical path is prioritised and enough of the work can be parallelised. Any programming team larger than 5 is more likely to be held up by project management than by their choice of language, although really bad languages like PHP and ASP could exasperate problems.

Ian Bicking 03/30/04 12:34:28 AM EST

I think some of the problem comes from OO, or at least some distorted vision of what OO should be. I see some of the same problems (though never so extreme) in Python libraries when people get a little to enthusiastic about objects and frameworks.

Objects are great for certain situations, but I think exposing objects in libraries is usually the wrong thing -- a simple function-based interface is almost always easier to work with. You can use objects internally all you want, and even return objects or accept well-defined objects as input (preferably objects that are not unique to the library), but it's worth avoiding if you can.

Python manages to avoid some of this by (a) having decent built-in data structures, like dictionaries and tuples, which take the place of lots of little objects, and (b) having real functions. Forcing everything to be a method is stupid, stupid, stupid! I like Python libraries that are made up of a few functions with lots of keyword arguments -- it seems crufty and lacking orthogonality, but it's wonderfully usable and documentable, and those "elegant" features that you're talking about only matter *inside* the code, they aren't what makes an elegant exterior. Long live prodecural programming!


Got it working.. 03/30/04 12:33:28 AM EST

Great article!!

I have the same experience, and taking the Bouncy example, I managed to get rsa & 3des working after ripping the flesh out of the +500 files from bouncy combining it with some flesh from cryptix... (I am vegeterian by the way) and I must say that the author is absolutely right!! There is really nothing wrong with Java itself, it is the implementation of it that may or may not be the most exalted on the face of god’s grey
Earth. Sorry my bad Englisch.

Dave 03/30/04 12:26:14 AM EST

HehHehHeh, right-on J.T. Maybe a bit of hyperbole in there, but all-in-all you are preaching to the choir here.

Done fast - Perl.
Run fast - C.
Nowhere fast - Java.

Steve J 03/29/04 09:07:54 PM EST

I'm not here to defend Java (truth is I would need a book just to remember how to invoke a build), but is it fair to say that you can encrypt something in Perl in 3 lines? The appropriate module may allow you to do that, but that module hides code that took time to create.

Bobo Jenkins 03/29/04 04:26:42 PM EST

You have a huge beard!

Dan 03/29/04 04:21:22 PM EST

James, you should take a look at Ruby. Cleaner than Perl, with the OO-ness of Java, plus you get mixins. Mind you, I don't think there's an OpenPGP package handy yet, although openssl is part of the standard distro now. Maybe I'll work on one.

I programmed almost exclusively in Perl for about 4 years before switching to Ruby. I think it has helped me in terms of fostering a "write the API first, implementation second" viewpoint.

Just thought I'd mention it.



IoT & Smart Cities Stories
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT staff augmentation services for software technology providers. By providing clients with unparalleled niche technology expertise and industry experience, Chetu has become the premiere long-term, back-end software development partner for start-ups, SMBs, and Fortune 500 companies. Chetu is headquartered in Plantation, Florida, with thirteen offices throughout the U.S. and abroad.
The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
SYS-CON Events announced today that DatacenterDynamics has been named “Media Sponsor” of SYS-CON's 18th International Cloud Expo, which will take place on June 7–9, 2016, at the Javits Center in New York City, NY. DatacenterDynamics is a brand of DCD Group, a global B2B media and publishing company that develops products to help senior professionals in the world's most ICT dependent organizations make risk-based infrastructure and capacity decisions.
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
Cloud-enabled transformation has evolved from cost saving measure to business innovation strategy -- one that combines the cloud with cognitive capabilities to drive market disruption. Learn how you can achieve the insight and agility you need to gain a competitive advantage. Industry-acclaimed CTO and cloud expert, Shankar Kalyana presents. Only the most exceptional IBMers are appointed with the rare distinction of IBM Fellow, the highest technical honor in the company. Shankar has also receive...
Headquartered in Plainsboro, NJ, Synametrics Technologies has provided IT professionals and computer systems developers since 1997. Based on the success of their initial product offerings (WinSQL and DeltaCopy), the company continues to create and hone innovative products that help its customers get more from their computer applications, databases and infrastructure. To date, over one million users around the world have chosen Synametrics solutions to help power their accelerated business or per...
DXWorldEXPO LLC announced today that ICOHOLDER named "Media Sponsor" of Miami Blockchain Event by FinTechEXPO. ICOHOLDER gives detailed information and help the community to invest in the trusty projects. Miami Blockchain Event by FinTechEXPO has opened its Call for Papers. The two-day event will present 20 top Blockchain experts. All speaking inquiries which covers the following information can be submitted by email to [email protected] Miami Blockchain Event by FinTechEXPOalso offers sp...
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...