« Web services choreography standard 18-24 months away | Main | XML-RPC case study »

The Java ceiling

Jelly - Jelly : Executable XML. Jelly is a scripting/tag language that uses XML for its syntax.

This is supposed to be good because you can use Jelly to process Jelly, or any other XML, and since like XSLT it has the property of lexical closure, you can pipeline the stuff (of course with XSLT, the reality of doing this is not so straightforward). Why not use an existing scripting language (ie embed Mozilla Rhino for using Javascript) is not discussed.

I suspect Jelly was invented for the following reasons:

  • someone felt a genuine need for a procedural scripting language for munging XML.
  • it would be cool if the language was also in XML, so we could build processing chains and filters (lexical closures).
  • using Ant as a scripting language is officially bad practice.
  • in reality XSLT sucks for pipelining.

What I don't understand is why anyone would want to write code in XML, when they could use powerful languages, such as Python/Jython, Perl or the aforementioned Javascript.

Jelly is informative nonetheless. Ant clearly has limitations when it comes to multiple projects and versioning (arguably it's not designed for that, but even the ASF use it as though it were). I've experienced this first hand, and it's good to see that Jakarta has implicitly acknowledged it with the Maven project [I'm putting something together to deal with managing Java code, somewhere in between Maven and Cruisecontrol - watch this space]. It tells me that neither XSLT or JSP are sufficiently repurposable or hacker friendly to be used for anything other than generating (X)HTML.

Most importantly, it suggests along with some other goings on in the world of Java open source, that Java as a language and platform is reaching a natural level of incompetence. Java in short is under strain. That strain is centered around making code adaptable and repurposable at runtime. To really do that, you need a language that lets you change the software while it's running. In the past, this need was not a business need - it was limited to a minority using Lisp Machines and Smalltalk, or experimental scripting environments. Only the mainframe needed to stay up 24x7 and businesses requirements tended to be a tad more stable. Today, with the client-server web, it is crucial to a business to be able adjust running code without taking servers offline.

Jelly, XDoclet, XRAI, the strong interest in Aspects and scripting runtimes, suggests that Java is perhaps getting in the way. Not so much because these things exist, but because the form they take seems entirely designed to get around the Java language while remaining inside the JVM.

The first clues we had on the limitations of the Java language proper were the absence of runtime introspection and type generics. Runtime introspection was fixed years ago with the Reflection API (a kludge nonetheless, compared to what can be done in Smalltalk|Python|Lisp). Arguably, Java with generics is a new language that supersets Java. Generics are a huge leap forward. It's weird that while many of us Java developers would spit on C++, C++ remains the more powerful and expressive language, primarily because you can use it for generic programming. Consider what Alex Stepanov (of C++ STL fame) has to say about Java:

You can't write a generic max() in Java that takes two arguments of some type and has a return value of that same type. Inheritance and interfaces don't help. And if they cannot implement max or swap or linear search, what chances do they have to implement really complex stuff? These are my litmus tests: if a language allows me to implement max and swap and linear search generically - then it has some potential.

Doing something that would be trivial in Lisp, awkward in Python or C++, seem to be hard in Java and require either non-standard extensions to the language with a custom compiler (AspectJ), using Javadoc as preprocessing engine (XDoclet), or byte code tweaking (CGLIB). Note that no-one in the Perl or Python communities would dream of creating anything like Jelly (or Ant for that matter).

My point is that the Java Open Source community is gradually finding the Java language is an obstacle in itself. I think over the next year we'll see it come into general awareness that Java as designed is a bottleneck. Indeed innovation in Java today is too often using Java to write interpreters for little languages to do things in Java you can't do in Java. Or adding new standard libraries.

I'm not actually interested in beating up on Java, though it may sound that way. I use it a lot and like it. The reason the situation concerns me is that in my experience business people don't actually care a whole lot about Java the language, they care about J2EE. Of course, J2EE is underwritten by Java and the JVM, but that is a detail. You might as well be saying that aluminium and ABS underwrites a car.

But as businesses requirements roughly translate into the technical need for continuously adaptive systems flung across the Internet (as opposed to highly scalable and modular ones flung across the LAN, the classic J2EE pitch), the dissonance between what is needed at the business level and what can be achieved with the Java language in reasonable time and money will widen. Adaptive businesses need adaptive systems. Adaptive systems need adaptive languages.

Even Gosling's current anti-.NET slogan "J2EE is a marketplace" misses the point. So does all the rest of the .NET v J2EE nonsense . Adaptation is what matters to a modern business. The biggest risk to the J2EE franchise is not .NET, but Java itself. The minute businesses figure out that the Java equates to inflexible systems (the way they did with Mainframes, CICs, COBOL and C++), J2EE ceases to be marketable proposition.

The thing is, Sun has the talent to make Java a truly flexible programming language. Guy Steele Gregor Kiczales, and Richard Gabriel are or have been involved with Java, and they know a lot about how to make languages adaptive.

December 1, 2002 03:43 PM