Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2573 posts at DZone. You can read more from them at their website. View Full User Profile

Project Jigsaw Being Pushed to Java 9

  • submit to reddit
A blog today by Mark Reinhold, the OpenJDK project lead at Oracle, might have come as a shock to many in the Java community: It looks like Project Jigsaw (a standard module system for Java SE) is lagging behind in development and probably won't make it into the Java 8 release next summer.

Steady progress is being made, but some sig­nif­i­cant tech­ni­cal chal­lenges re­main. There is, more im­por­tantly, not enough time left for the broad eval­u­a­tion, re­view, and feed­back which such a pro­found change to the Plat­form de­mands. I there­fore pro­pose to defer Pro­ject Jig­saw to the next re­lease, Java 9. In order to in­crease the pre­dictabil­ity of all fu­ture Java SE re­leases, I fur­ther pro­pose to aim ex­plic­itly for a reg­u­lar two-year re­lease cycle going for­ward.

--Mark Reinhold

For a while OpenJDK has had a prototype (download and evaluate here). Reinhold says that maintaining compatibility with existing code has been a "delicate task".  They also have not started to plan how they will support various containers for IDEs, app servers, etc. 

The comments on Reinhold's blog were split pretty evenly between supporters and 'the annoyed'.

From Guillaume Laforge (major Groovy contributor)

We didn't go too far with modularity in Groovy 2... because we didn't want to duplicate what was supposed to be coming in Java 8. 

But now, it means it won't be in the hands of developers before 2 years, and in production before 3 years :-(

It means that Jigsaw, if it ever ships, will have been 5+ years in the making. That sounds a lot, even for such a big feature and task.

Johannes Brodwall
however, was fully in agreement that Jigsaw should not be allowed to hold up Java 8:

DON'T HOLD THE TRAIN. The five years from Java 6 (which itself was disappointing) to Java 7 nearly killed the language.

But understandably, some were disappointed that Jigsaw, which was first proposed for Java 7, is probably not coming till Java 9 now.  Markus Karg suggested they give up on the idea and just tell people to use Maven.

So... How does this news sit with you?  Are you with the "Just use Maven" crowd?  Do you think it's important that Java 8 not be delayed?


Lester Burnham replied on Tue, 2012/07/17 - 6:03pm

"Just use Maven" has got to be a joke. As a build system, Maven doesn't begin to address the issues of modularization that Jigsaw was supposed to address. Luckily, it doesn't need to, and neither does Jigsaw, as OSGi is here today and has been for a long time. Why the JSR folks saw fit to build another approach to solve the same problems will remain their mystery.

Otengi Miloskov replied on Tue, 2012/07/17 - 6:34pm

As  Johannes Brodwall  said DON'T HOLD THE TRAIN and kick out Jigsaw and welcome OSGi. OSGi should be already the standard long time ago, As we know reinventing the wheel sometimes is not the way to go. If they somehow can include quickly OSGi to the standard and ship Java8 with OSGi that will be great. 2c. 

Jacek Furmankiewicz replied on Tue, 2012/07/17 - 8:05pm

Excellent news.

 As someone who had to suffer from having OSGi pushed down my throat for a year long project, I am very happy this thing is off the table and the JDK team can focus on far more important enhancements.

 And Maven works just fine and great. We've done in it everything we did before in OSGi and with far less headaches...and not a single darn ClassCastException after which you waste hours and days.

I for one congratulate the JDK team on a pragmatic decision. All Java programmers can rejoice that this whole OSGi hype is well and over by now. 

Abani Behera replied on Tue, 2012/07/17 - 10:29pm

Its a long time that we have waited for a modularity in java. After all those wait, again its pushed.. probably we havre to adopt OSGi.

Reza Rahman replied on Thu, 2012/07/19 - 8:40am

I think this was a hard decision but also the right decision. Having first and second hand witnessed OSGi fiasco projects (via the now all but abandoned Spring dm/server), I strongly believe it is very important to have a simple, solid, unhurried, stable modularity solution. In the meanwhile, Maven works just fine 90%+ of the time for real-world enterprise application requirements...

Andreas Haufler replied on Wed, 2012/07/18 - 2:08am

I'd prefer to have closures and extension methods as soon as possible. Jigsaw sounds nice, but on the other hand, there are already some more or less usable module systems around.

Andreas Schilling replied on Wed, 2012/07/18 - 2:42am

I never understood why we need Jigsaw when there is OSGi around already for ages.

So, probably this is good news.

And I have to second lester: "Just use maven" is a great joke, right? Modularity in the sense of Jigsaw or OSGi doesn't have anything to do in the first place with your build system...

Christian Schli... replied on Wed, 2012/07/18 - 3:27am

RIP JigSaw, long live OSGi!

Seriously, I'm not advocating OSGi for all projects because it adds a fair level of complexity. But there are valid use cases for it and if you need it, then you need it.

However, modularity is architecture! As a designer you need to obeye certain constraints to enable modularity. For example, you can't allow circular compile time references between packages if they ought to be the entities of modularization.

Now look at the JSE 7 API: For example, it introduced a circular reference between the packages and java.nio.file via the signature of the methods File.toPath() and Path.toFile(). This means you will never be able to split these packages into separate modules.

Considering these constraints, it's clear that project JigSaw is a failure-by-design because it's impossible to solve these problems without introducing binary backwards incompatible changes to the JSE API.

Now what to do? I think the opportunity for introducing a module system for the JSE API itself is gone. If you need a modular architecture for your own project, then there are two options: If you just need compile time support, Maven is a good choice. If however, you need run time support for modules (e.g. to solve the diamond problem), then OSGi is the right tool.

Seb Cha replied on Wed, 2012/07/18 - 5:56am

i agree about maven for compilation time and osgi for runtime modules.

IMO having multiple jars to apply separation of concerns, is the same as package/classes organization... we should not call this practice a "modularization". This can lead to confusions...

Kaan yy replied on Wed, 2012/07/18 - 6:20am

osgi and maven is enough; spend your energy on other things

Jonathan Fisher replied on Wed, 2012/07/18 - 9:41am

Does OSGI break the Java Class Library into smaller pieces? As I understand that was Jigsaw's primary goal. 

Wujek Srujek replied on Wed, 2012/07/18 - 9:44am in response to: Jacek Furmankiewicz

How on earth do you plan to solve modularization issues with maven? This is a joke.

Let me explain the problem: suppose you have library A and library B, both depend on library C, but different versions of it. A depends on C1, B on C2, and C1 and C2 are incompatible enough, so that A with C2 and B with C1 just don't work.

If you are looking for a good candidate for C, let me mention asm or cglib. For A and B the candidates are numerous: you mix Guice with Groovy, or Spring with Groovy, and test the thing with mockito, but want to use the latest hamcrest, and you happen to use one more library that requires hamcrest in another version. That's a start. Now, please explain, how do you 'fix' it with maven.

Sure,  there are 'solutions' - mockito-all packing hamcrest (mockito-core already packs cglib and asm), spring jars repacking cglib, Groovy as well. For it to work, they use different package prefixes for the common classes. Now suppose cglib gets a bugfix that you need becuase otherwise one of you 'outer' deps doesn't behave well in your use case - now you have to repackage the jar yourself, or wait until the outer dep repackages it itself and releases a new version. Not exactly nice. 

I agree that OSGi is not the ultimate solution, though. I was hoping for Jigsaw to be a 'better, lighter OSGi'...

Harald Wellmann replied on Wed, 2012/07/18 - 1:04pm

OSGi is a mature solution providing compile-time and run-time modularity for Java applications, as witnessed by large systems like Eclipse or GlassFish which are built on top of OSGi.

I'd rather have no Jigsaw in Java 8 or no Jigsaw at all, ever,  than a Jigsaw incompatible with OSGi.

Modularity and component versioning is not for free, it requires a paradigm shift compared to kitchen sink design, no matter which technology you use. Retrofitting legacy software to any given module technology can be painful or even impossible without breaking API changes.

Given the number of package cycles in the JRE class library, I'd say that modularizing the JRE while maintaining backward compatibility is like squaring the circle.

The tremendous value of the Java ecosystem is not based on the Java language, but on the abundance of existing open source libraries, frameworks and tools built in Java.

The language itself is secondary, and any language like Scala, Groovy, Ceylon, you name it, cannot really compete with Java unless it provides an equally rich ecosystem or a seamless integration of its own libraries and tools with existing Java solutions.

Ceylon, for example, is trying to rebuild the world from scratch, and I wish them good luck... But Ceylon does have a very interesting modularity approach, and if Java will really take another 5 years or so to hack the JRE into pieces, Ceylon may be able to catch up.

On the other hand, given that more and more people start moving to other languages, why not simply ditch backward compatibility, and define a Java++ language and class library which is still recognizable as Java but drops all legacy.

Recompiling all of Maven Central with Java++ is certainly more feasible than rewriting all of it in some other language.



Jilles Van Gurp replied on Wed, 2012/07/18 - 1:58pm

Having seen how non java systems are managed and deployed, I've come to believe that the need for modularization is not that desperate in the Java world. Most Java deployments are comparatively complicated and tedious. Mostly the complexity is not justified by the benefits. For most setups, a sane unit of deployment is "the application" or "the server" (including os and config). Typically this is a bunch of servlets/jsps with some vanilla spring setup and maybe a dash of JMS and misc other comonents. 

Part of the perceived need for modularization is a mentality problem. When server hardware is scarce (like in an enterprise), you tend to baby sit it a lot more and fiddle with the knobs and compete for space with other applications. We use amazon AWS. Hardware is not scarce, time to fiddle with individual nodes is. So, for me a server is something that I do only a few things with: boot it, run os & app install, puppet config, monitor until it dies for whatever reason, post mortem, restart. We never go anywhere near /etc/init.d/tomcat manually. Either it boots or we have to fix why it didn't boot and we destroy the node after we're done and fire up a fresh one.

I have no clue whatsoever why you would want to mess with individual modules in a live server environment. Personally, I'd be in favor of a vast simplification of the way Java applications are deployed rather than making it even more complex.

OSGI was a nice idea and half decent implementation but (like maven) it suffers from a few deficiencies:

1) it is not native to the language or platform and tries to bolt on features to the Java platform and libraries (Manifest files, seriously?!)

2) it is hopelessly complex for what it does.

3) it tends to require everyone to play by the rules for things to work properly (i.e. not backward compatible).

4) like all frameworks, people have bolted on everything and the kitchen sink and reinvented a lot of perfectly good wheels in the process. These things tend to overlap with other stuff that you might want to use and the integration of these things tends to suck.


Jacek Furmankiewicz replied on Wed, 2012/07/18 - 10:56pm in response to: Wujek Srujek

We have an app with nearly 40 MB of dependencies and we've never run into a showstopper library incompatibilty that you describe. usually Java libs are pretty amazing at backwards compatibility, in most cases.

OSGi fanboys are taking an extreme edge case like what you describe and using it as an excuse to make everything that is simple ultra complicated and over engineered.

OSGi is a great solution for truly modular platforms (e.g. Eclipse RCP, Netbeans Platform, etc.). For all other typical Java apps it is gross overkill that solves one issue but introduces 1,000 new ones.



Wujek Srujek replied on Thu, 2012/07/19 - 1:07am in response to: Jacek Furmankiewicz

I currently have a small app that mixes and matches a few libraries and cglib _is_ a real problem. That's probably the reson for my bitterness lately.

Why would you think I am an OSGi fanboy? I do see its merits, but I don't think it's _the_ thing. 

David Whatever replied on Sat, 2012/07/21 - 10:53pm in response to: Christian Schlichtherle

Jigsaw was/is not modularity at the package level and had a few specific capabilities to account for some of the lack of historical modularity in the JRE.

 While OSGi you are meant to treat packages and services requirements as interface to be specified and fulfilled by the OSGi framework, with Jigsaw a module typically indicated the specific dependancy modules and versions desired. These are some of the reasons that OSGi was not suitable as-is for Jigsaw.

That said, I hope the extra two years allows for much more talk of interoperability between OSGi and Jigsaw. Ideally the two systems could share infrastructure within the java runtime. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.