One thing about high technology is there's always something new coming along. Usually, it's better, at least in some way. Yet, you can't throw out what you already have until you are sure you have a replacement. That's still one of the things that makes technology assessment a bit of an art. Look at the recent machinations around Jigsaw, for example.

Recently, Oracle's Mark Reinhold blogged to the effect that Project Jigsaw will not be ready for the next rev of Java -- that is, Java 8, planned for September 2013. That could very well place Jigsaw as a standard reality somewhere in the 2015 timeframe.

Perhaps one could kind of see this coming. It doesn't take a seer. OSGi does some difficult work, and it took time to happen. Jigsaw may do the work more easily or differently, but it, too, takes time to happen. We recall SearchSOA.com's coverage of Jigsaw when described as part of a 2011 story on then-new OSGi bundling.

Read the news at SearchSOA.com and let us know what you think about the proposed Jigsaw delays.

Jigsaw is lots of things:

1. A simple module system integrated into the language, buildtime, and runtime environments.
2. Modularization of the JDK itself.
3. Integration with native packaging systems.

I'd really like to see just #1 available to developers in Java 8.

The rest of the pieces can wait -- we don't need them nearly so badly.  Oracle needs them for its own hopes to unify Java SE, ME, embedded, Blu-Ray, ...., and be more competitive in spaces outside the server-side sweet spot.  Most Java developers don't actually need #2 and #3, though some mysteriously seem to feel that some magic utopia will be reached when the JVM is modularized.

OSGi strikes all but the biggest fans as more complex.  That's not without some reason as it does fancy module lifecycle management, allows juggling of multiple versions of a library, etc.  That's well beyond what most developers need.  It also doesn't deal with legacy code that requires a package span across modules -- a situation that exists in the JDK and in code elsewhere.  Finally, through no fault of its own it's not integrated at the language level.

I rather think that majority of developers (at least these with 5+ years in Java) were hoping for the modularization of JDK itself, to be able to easly replace/get rid of at least 50% of rt.jar's content. I'm sure someone needs CORBA (e.g., me sometimes), but it's not the reason to put it into stantard library.

For me Jigsaw was (still will be?) a key point in the discussion what should and what shouldn't be a part of standard library. Many rt.jar's packages should've never been there - especially all these enterprise APIs. These should be a part of application server (in well known versions) and be always available through some central repository (the most important feature of Maven). In the simpliest form, Enterprise APIs should be just loaded using parent class loader. Now my first step during deployment of JavaEE apps to app server/target environment is to be sure that e.g. JAXB2 or JAX-WS API/impl is in the known/predictible version regardles of JDK version used.

So, in conclusion, new module syntax and keywords are not going to be put in existing Enterprise Java applications (in operation from e.g. 2002). They're not going to change JavaEE in at leas 6 years. What's most important is ensuring the safety of applications in case of changes in JDK/application servers. And that requires professional approach to naming, separating, versioning and publishing the source code (which gives us transparency, access to history and to information on people responsible for changes in key areas of Java) of Java/JavaEE packages/modules.

(The modularization of JDK is only half of success - there should also be something done in the area of JavaEE packages - just look at some APIs - some are available through Maven Central, some don't (JTA, JMS). Some APIs (Servlets) have several different Maven groupIds (javax.servlet, org.glassfish.javax.servet,
org.apache.geronimo.specs.geronimo-servlet_3.0_spec, org.mortbay.jetty.servlet-api). Is this a way to describe application's dependencies?)

regards

Grzegorz Grzybek

I rather think that majority of developers (at least these with 5+ years in Java) were hoping for the modularization of JDK itself, to be able to easly replace/get rid of at least 50% of rt.jar's content. I'm sure someone needs CORBA (e.g., me sometimes), but it's not the reason to put it into stantard library.

For me Jigsaw was (still will be?) a key point in the discussion what should and what shouldn't be a part of standard library. Many rt.jar's packages should've never been there - especially all these enterprise APIs. These should be a part of application server (in well known versions) and be always available through some central repository (the most important feature of Maven). In the simpliest form, Enterprise APIs should be just loaded using parent class loader. Now my first step during deployment of JavaEE apps to app server/target environment is to be sure that e.g. JAXB2 or JAX-WS API/impl is in the known/predictible version regardles of JDK version used.

Yes, some were really hung up on getting rid of CORBA, etc.  On a server-side deployment, such cleanup is really, really low priority in terms of any real impact.  I'm sure it gives ivory-tower purists a sense of clean perfection, but it really does precious little to improve development or runtime behavior in any substantive way.

As for the various XML APIs, -Djava.endorsed.dirs should suffice to replace the defaults, so I'm not sure what the real issue is there.  Could this be prettier/cuter?  Sure.  Does it really hurt any server-side usage in any substantive fashion?  No.

The JDK developers are busy folk -- they can't be chasing ivory tower dreams.  That said, modularization of the JDK must be a priority for their own maintainability, portability, and deployability goals.  It just doesn't have any substantive benefits to server-side development in the near future -- and thus can easily be dropped from Java 8 in favor of other things.

A simple, language-level modularity feature, on the other hand, would have a huge impact.

Sure, the OSGi api's feel a bit old and sometimes you end up working at more low level code than you'd want, but in the end, the difficult part is not related to what particular framework you use.

OSGi mercilessly exposes modularity problems in your code, and forces you to fix those. Jigsaw might be more forgiving, but you will have to face these demons at some point.