Thursday April 06, 2006
Modularity on the Java SE horizon
Filed under: javase7
I have confined myself thus far to talking about things in Java SE that are within hands reach. I thought it was time, especially with JavaOne coming up, to take a peek further ahead, see what's on the horizon for Java SE beyond Mustang.
For a technology that has found the range of venues for deployment that Java technology has, it still amazes me that under these competing demands, Java the language and Java the platforms have remained so consistent. But in places, the signs of age and stress are showing. In order that Java can continue to be many things to many people, its natural to look to ways to flex under the stress, rather than snap. And with an industry depending on the technology, in an evolutionary, not revolutionary way: Modularity.
So where are the stress points, and what can we make out on the horizon ?
1. Packaging and Deployment Modularity
The JAR format was first introduced in JDK 1.1 as a way to package application classes needed by an applet. Now its used as a general purpose format for deployment, packaging, caching, execution and distribution. On view on the horizon is the Java Module System JSR. Its vision is that instead of a tangle of JAR files (some needing a diet) of unknown versions secreted in various places, strung together in hope by a complicated classpath checked only at runtime, organization will be brought to application packaging and deployment in the form of a neat repository of medium sized code archives quietly expressing detailed and fully resolved dependencies on one another. Easy to manipulate, easy to distribute.
Easier to bring some much needed help 10% of PC users ?.
2. Language Modularity
Of course, as I mentioned last time, this is about supporting your other favorite language rather than turning Java into something it isn't. OK favorite within reason: dynamic ones. Maybe if your favorite language is c we'll need to talk. As I'd mentioned, quite close to hand is the Scripting for the Java Platform JSR makes a start by providing a basic facility for layering an interpreter on top of the JVM, enabling applications to mix Java and other languages.
But the compilers for dynamic languages are difficult to write well. Why is that ? Well, its a bit like doing your taxes without either an accountant or TurboTax.
Its about form filling: The main problem for writing a dynamic language compiler that creates Java bytecode that behaves optimally at runtime is that the Java VM depends on finding the method parameter and return types of a method call in the class file of the object making the call. The whole point of dynamic languages is that you don't know the types at the time you make the class file i.e. compilation. So todays dynamic language compilers usually employ complicated schemes of generating interfaces on the fly to represent unknown types, just to provide the form filling required to make a class file. It makes them slow, and when the developer changes code and recompiles, those magical interfaces need to checked and/or generated.
So on the horizon, the newly approved Supporting Dynamically Typed Languages on the JavaTM Platform JSR aims to remove that beaurocratic barrier to to dynamic language support by adding a new slot in the bytecode format. A slot not used by the Java language ! (not yet...)
Relief for the dynamic language folks ?
3. Application Code Modularity
Java already has various tools for decomposing and organising program code. At the small scale, classes to organise related functions and operations. OK so far. At the team, larger program scale, packages. But packages are a little stressed out too.
Let's say you want to publish a data model you wrote representing players in a tennis league. So you make the relevant classes and methods public. No harm in anyone picking up the code to do that. Like the developers of your tennis club's website. As the code evolves, you find yourself adding some interesting data exporting methods to help you interface to a database. Great, better make all that public for your database developers. Now your web developers and your database developers have exactly the same view to your code. Oh dear. The web developers are confused by the database related methods and some are using them by mistake. Better move that to a different package. But didn't you want it in the same package because its all related ? And, sigh, now you have to turn some of the package-internal classes public so the classes in the new package can still use them. Now the crazy web developers are using those classes, and they are asking what the new package is for. Double sigh !
Replace tennis club with insurance brokerage and a few thousand lines of code with a few hundred thousand and you probably already got the point.
Gilad amongst others has been toying with a few ideas here which I hope will come into range soon. Think 'friendly' packages, think 'organized' packages.
So, some interesting things on the horizon. Come to JavaOne, or stay tuned here - if I squint I can see a few more things out there...
