{ by david linsin }

January 05, 2009

Java 7, Jigsaw and the Missing JSR

A couple of weeks ago, at Devoxx, Mark Reinhold released some details about what's in scope for Java 7, as well as its planned release timeframe. Joe Darcy blogged about this before, so I'm not gonna recap all of the stuff. Instead I'll try to summarize my understanding of the Devoxx kenyote as well as the BOF with Mark and Alex Buckley.

The most interesting Java 7 announcement for me was the proposed language changes, which are steered by Sun. The Devoxx whiteboards as well as the keynote by Mark Reinhold suggested various "small improvements". Among others are:

  • a for-each construct for Maps
  • a for-each iteration control
  • an array-like list/map access
  • type inference on generics declaration
  • multicatch of Exceptions
  • resource management

    For further details check Stephen Colebourne's slides.

    My understanding is that those changes are not set in stone. Josh Bloch told me that Sun is still gathering feedback from the community, on which changes to implement. However, eventually it's up to Sun which changes to include and how to implement them. One thing is for sure though: Closures are not going to be in Java 7. I won't go into this again. I simply think and I'm not alone on this, it is a missed opportunity for Java.

    If you didn't attend Devoxx and look for a way to give feedback on the proposed changes, check out my poll and make your voice heard.

    Modularization is another topic, which was mentioned by Mark in his keynote. Like me, you've probably heard about Sun's plans to split up the JRE's libraries into separate modules. What surprised me though, was the fact that this effort won't be specified and implemented by a JSR, but rather an open source project called Jigsaw. According to Mark there is no time for a JSR.

    Jigsaw will be a module system, which bootstraps the JRE. It's available to developers as well, to modularize applications, similar to OSGi. Speaking of which, my understanding is that Sun wants to work with OSGi. How this is going to look like, is yet to be determined.

    I think it's quite difficult to work on something like a module system without a proper specification. Let's say you want to port your application, which is based on Equinox and OSGi, to the new Java 7 module system. How is this supposed to work? Is this going to work at all? If it's technically possible, I think OSGi will eventually support Java 7 modules. However, I find it rather odd that there's no spec for this endeavor.

    Despite all of my rants here there is at least JSR 294, which specifies the language and JVM changes. Don't get me wrong, I'm not a spec freak. I just think that for interoperability and compatibility with other module systems a spec is a necessity. In my current project we invested a lot of work in OSGi. I just don't like the fact that those efforts are probably in vain, if we would like to use Jigsaw instead. I know it's a little far-fetched, but I'm just thinking it should be possible to switch module systems.

    In general I like where Java 7 is going. Language changes are finally starting to take shape and Sun's efforts to modularize the JRE, however they might turn out, sound promising.

  • 0 comments:


    com_channels

    • mail(dlinsin@gmail.com)
    • jabber(dlinsin@gmail.com)
    • skype(dlinsin)

    recent_postings

    loading...