a little madness

A man needs a little madness, or else he never dares cut the rope and be free -Nikos Kazantzakis


Devoxx: Future of the JVM

Today’s theme at Devoxx, at least from the talks I chose, was very much the future of the JVM, including the future of Java. Two big things were highlighted: modularity and dynamism.


The focus of JDK 7 will be a new module system for Java which will in turn be used to modularise the JDK itself. The plan is to develop the system in the open (no more JSR-277-style project management) as part of the recently-announced Project Jigsaw. I encourage you to read Mark Reinhold’s blog entry for details.

One neat point that stood out for me was the desire to make this fit well with OS packaging systems (think RPMs, .debs, etc) — so it will be trivial to create an OS package for a Java module. This should couple nicely with the easy availability of the Sun JDK on Linux these days (now it is open source), making Java software more integrated with the native platform.

A much more critical point, however, is the idea of versioning as an enabler to make incompatible changes. Even as the news of Java’s death continues to roll in, it appears Sun is looking to put a mechanism in place that will allow them to finally make incompatible changes. Once you have a modular JDK and the ability to express dependencies on particular versions of modules, it follows that it should be possible to make incompatible changes to those modules in new versions. Perhaps in time this will allow a much-needed cleanup of the dark corners of the platform.

This also raises big questions for both OSGi and Maven. I don’t expect either of these entrenched projects to disappear, but there is certainly overlap and a need to adapt. On the OSGi front Sun is aiming for interoperability, but they claim that the Jigsaw module system will go down to a lower level than OSGi is capable (Update: it appears that this claim is controversial, see the comments below.).


Stepping away from Java the language and looking at the JVM platform, Brian Goetz and Alex Buckley spoke about the move “Towards a dynamic VM”. The talk focused on the efforts in JSR-292 (aka the invokedynamic JSR) to make hosting dynamic languages on the JVM easier and more efficient. The key component of this JSR is a new invokedynamic bytecode which can be used for dynamic method dispatch (when the actual method to call depends on more than just the type of the instance it is being invoked on).

The cool thing about invokedynamic is it will allow the various dynamic language runtimes to effectively plug method lookup functionality into the JVM. This will allow each dynamic language implementation, many of which have very flexible method binding, to take full control of method selection. This is key to efficient implementation of these languages on the JVM.

So hey, even if Java has lost its mojo, that isn’t the point anymore. It’s the platform, stupid!

Liked this post? Share it!

5 Responses to “Devoxx: Future of the JVM”

  1. December 12th, 2008 at 8:55 pm

    Neil Bartlett says:

    the Jigsaw module system will go down to a lower level than OSGi is capable.

    This is incorrect. OSGi can go down to that level, as Apache Harmony has already proven. Harmony was modularised long ago using OSGi. Sun is just playing catch-up.

    Jigsaw should be OSGi-based. It may not be, but if Sun decide to go that route it will be for political rather than technical reasons.

  2. December 12th, 2008 at 9:30 pm

    Jason says:

    Hi Neil,

    Thanks for your comment, I am happy to be corrected if I have repeated something incorrect. I guess you have also voiced this view to Sun — it seems they disagree? Given the history of the JSRs on this matter I presume the argument has been ongoing for some time. To be frank I’m not in a position to make a call either way, so I will update the post to highlight that this point is controversial.

  3. December 12th, 2008 at 9:48 pm

    Neil Bartlett says:

    Hi Jason

    I have blogged about the matter.. the link to the post is below (warning, it’s rather long). Also Sun has promised to work with the OSGi Alliance and I know that Peter Kriens (the Alliance’s Director of Technology) is committed to working with them as much as they allow. He knows better than anybody exactly what OSGi’s capabilities are, and will be pointing them out to Sun.



  4. July 1st, 2009 at 6:50 am

    mxc's status on Tuesday, 30-Jun-09 19:50:52 UTC - Identi.ca says:
  5. July 1st, 2009 at 6:50 am

    mxc's status on Tuesday, 30-Jun-09 19:51:42 UTC - Identi.ca says:

Leave a Reply