imaginary family values presents

yesh omrim

a blog that reclines to the left

Logo

Why Java is the wrong language for “enterprise” applications

17 August 2005

Two and a half years ago, after I was laid off, I had the search engines send me a daily list of every job posting in the Boston area containing the words “Perl” or “Java”. Virtually nobody wanted to hire a Perl programmer, and virtually every Java position required not only Java, but J2EE; not only J2EE, but experience with a particular brand of J2EE application server. I had worked with Java in my previous position, but not J2EE, so I stayed unemployed for ten months.

While I was pounding the electronic pavement, I decided to submit to the discipline of the free market, so I signed up for a free online course taught by someone at Sun and downloaded the Linux version of Sun’s J2EE reference platform. After a few sessions of learning the arcana of the EJB, I told my wife: “Now I understand why they have all these positions for J2EE programmers. Something a Perl hacker can do in an hour, a team of J2EE programmers have to spend a week on.”

Developers’ backlash against the complexity of J2EE is now in full swing, and it seems to be taking two forms. Some people are pushing for expanded use of lighter-weight Java frameworks, such as Hibernate. Others are arguing that the proper solution is to abandon Java altogether, and work with more dynamic languages—a proposal that has sparked much debate, and inspired a Java framework that’s even simpler than Hibernate. I can’t boast years of experience implementing the high-traffic database-intensive Web applications, but I have reason to believe that the dynamic-language folks are on the right track.

Suppose you’re writing a Java component to extract information from a relational database and construct objects appropriate for some other application. The classical way to do the job is to write the procedure, in Java code, to extract fields from the result set and construct your objects. J2EE and its competing frameworks give you an alternative: you can write a description of how database fields map onto your objects, and let the framework generate code that does the translation for you.

The authors of your framework have no way of knowing in advance what classes you would be using in your business logic or what schema your database tables would have. The only way they can connect one to the other is by exploiting loopholes in the Java static typing system: for example, J2EE CMP systems generate code, while Hibernate uses reflection at run-time. The more your object-relational mapping diverges from “one database row equals one object”, the greater the flux through those loopholes.

So you need to look at how your architecture is split up between the business logic, the persistence layer, and the mapping, and ask yourself: given that the mapping layer has to work around one of the fundamental traits of Java, its type system, do you really benefit from having a mapping layer that’s implemented in Java?

You might answer, “because we’re a Java shop.” But when you’re sweating over the proper contents of XML configuration files, or writing annotations for a tool that “generates 85% of the code for you”, you’re not writing Java. So if you expect to be stuck writing a lot of not-Java, you might as well survey all your options, and see which not-Java is best for your needs. Even if your business logic is thousands of lines of Java code, you can still use a more dynamic language for the mapping layer and use JNI, wrappers like Perl’s Inline::Java module, or JSR 223, when it becomes available, to talk to your business objects’ factories.

In the above paragraphs, I keep using the word “database”, but the same logic applies to LDAP directories, MQSeries messages, HTTP requests, and XML documents—all of which have some kind of structure whose variations (a) depend on the application they are used for and (b) are not constrained by the type system of whatever code ends up processing them. Yet, if you read the J2EE documentation to glean some non-cynical definition of what the “Enterprise” is all about, you would conclude that the stunning complexity of J2EE, and the five-figure price for its application servers, is what you need to integrate your Java code with XML files, Web servers, databases, and messaging systems. It’s ironic that Sun devotes so much marketing hype to this use of Java in the “enterprise”, and yet this kind of integration goes against the grain of the language.