Friday April 21, 2006

The Hard Work of Making Java Easy

The Java backlash that began a few years ago was mostly a J2EE backlash, not against the Java language per se. Too many people took the blueprints too seriously, too literally or just too damned religiously. Too many applications that didn't need EJBs were using them, letting the container manage low level application plumbing invited slow and buggy behaviors that were painful to debug. The backlash has made a lot Perl/Python/PHP enthusiasts express self-righteous vindication and have helped morph the J2EE backlash into a broader Java backlash. Geez, even IBM is getting all spun up on PHP, whodathunk? But I think the dismissal of Java is premature. None of the P languages or Java are without hazards. These days a lot of developers are over the blueprint kool-aid and are standardizing on a simplified and productive stack:

• Spring Framework
• Apache (httpd and Tomcat)
• SQL (MySQL or PostgreSQL)
• Hibernate (optionally)

However, there is still a rapid development gap. I've heard Java called a "high ceremony" language. Where you can often prototype a lot of functionality in a modest amount of code with the P languages, you end up writing a lot more code to do the same things in Java. On the other hand, the run time errors, sorcerers and hackers adherent to the P languages are at least as guilty of the same brand of excessive zealotry as the blueprint adherents. The practical heresy demands recognizing that you can get it really wrong in just about any programming language. As far as the high ceremony, Java and J2EE are guilty as charged. As if to punish Sun, the developer community has innovated just fine without advance posturing within Sun's prescribed processes (the good news there: many within Sun seem to realize that they can't carry on as a cathedral and, in fact, are embracing the bazaar, bravo!). Spring and Hibernate each offer a degree of code simplification but require a bit of XML-hell. Even though the XML is way simpler to maintain than say, struts-config.xml and EJB deployment descriptors, you've reduced your compile-time safety code maintenance but increased your runtime hazards with more XML. Xdoclet or JSR-175 annotations can simplify a lot of the XML configulation required for Struts and Hibernate but then you might end up in another kind of hell: annotation hell. Choose your hell well!

To really bring rapid development and prototyping to a Java environment, there a lot options to look at such as dynamic JVM languages:

Jython

By most accounts, a mature but quirky Python for the JVM

JRuby

An immature but progressing Ruby for the JVM

Groovy

A failed experiment or work in progress, depending on who you talk to

Ruby on Rails doesn't run on JRuby (supposedly, it's coming). Grails (the artist formerly known as Groovy on Rails) is on v0.1, I'm not holding my breath. What about getting the simple life "convention-over-configuration" in Java? You get some of it simply by using Maven; organize your code to the Maven convention and compiling, testing and packaging your application just works. Eclipse provides so much developer support for Java already, using Maven and Eclipse together is great way to keep a lot of the high ceremony out of your way. But for application development, there are a few rails-alike frameworks for Java that I'm still interested in trying: rife and trails.

I expect in the months ahead to be writing applications with plugin support and that the big win for the dynamic JVM languages for me will be in easing the rapid development of plugins. In other words, I probably wouldn't write an end to end application with them but given a set of interfaces for extension points that can be automatically tested, writing the extensions in JRuby or Groovy sounds compelling.

I actually haven't had time and opportunity to substantially try half the things I've mentioned thus far. Surveying the number of tools, languages and frameworks it's clear that there are a lot of things to consider and that a lot people are concerned with (and working hard on) bringing the down the high ceremony of Java. I'll still be using P languages in the future, too. Down the road, I suspect virtual machines (JVM? parrot? mono/CLR?) will make a lot of these issues fade away and the questions at hand will be around when to use closures and when to use objects, when to annotate and when to externally declare, when to explicitly type or auto-type and so forth. The languages will be incidental as they support shared constructs and virtual machines.

java   rubyonrails   groovy   jruby   jython   maven   eclipse   xdoclet   springframework   programming  

( Apr 21 2006, 09:03:42 PM PDT ) Permalink