Thursday, May 24, 2007

Where Will JSR 277 End Up?

Sun has opened up the mailing lists of JSR 277 for observers. As I am denied membership, I now can at least have the privilege of hearing the conversation in this group. And interesting it is. Last week there was a discussion about importing classes, modules, or packages. As I argued vehemently (too) many times, importing packages is better than importing modules because it decreases coupling to a minimum. Some JSR 277 members seem to feel similar and are pushing for a similar solution. However, I think Glyn Normington gave the right answer:

Of course "import package" is superior to "require bundle" in many situations, but I think it would be a vast waste of time for JSR 277 to play "catch-up" with JSR 291.

A better approach would be for the Java 7 platform to provide first class support for JSR 291. This boils down to standardising the experimental class loader deadlock fix ([1]) and enabling JSR 291 to exploit JSR 277's repositories and JSR 294's superpackages.
I like this idea! JSR 277's unique aspect is the repository. Repositories have a clear value and Java does not have one at the moment. Instead of trying to invent a vastly inferior modularity layer that will take years to mature, it would be so much better to use the existing OSGi technology standardized in JSR 291 instead. Modularity from 291, repository from 277, and a new keyword from 294, I would almost start looking forward to Java 7!

Which brings me to another point. Why actually needs a Java 7? I have just started using Java 5 in my daily work, though most of my customers force me to use 1.4 bytecodes. This week I installed Java 6 but I have not found a single item that interests me so far. I understand that in a non-modular system one has to rev the whole system, even if the updates to the parts of the system are minor. Major new VM releases are painful and the steady release of new Java environments are increasing the distance between J2ME and J2SE with every release. Making it harder and harder to run on all platforms.

The industry needs modular Java technology so that we can go back to achieving the goal of "write once, run anywhere". If Java 7 can bring us closer to that goal, I guess it is worth it. If not, then why bother?

Peter Kriens


  1. I can not agree about JDK 1.6.
    Sun made great work on performance jvm. I think we must use last jdk for development(exclude can be only desktop application because JDK 6 does released at Mac OS X) and last jre for running application.

    When I watch screencast at AppFuse I think that I am living in past (my current project uses JDK 1.4)

  2. I think you confuse two issues. JREs, VMs, JDKs, and such should be updated frequently to increase speed, reduce memory consumption etc. Not only by SUN, but by all vendors that support the language.

    However, three is in my mind no absolute necessity to add features to the core environment, the more stable the core is the better.

    I also like several of the features that Java 5 brought us, however, what did Java 6 bring to the table, and therefore it is not clear what Java 7 will bring. These changes are very disruptive (I had to backport several applications) because they concern the basis of many of the things we do.

    Kind regards,

    Peter Kriens

  3. Hi Peter,

    I couldn't agree more on your comment to have a first class support for JSR 291.

    What beats me is what gap does 277 see in 291 that merits a separate modular system altogether?