CTO - jClarity Ikasan Community Lead (Java based - Open Source Middleware platform) PCGen Community Lead (Java based - Open Source Character Generator for D20 role playing games) Bartender at the Javaranch London Java Community (JUG) Co-leader Speaker Author Java Champion (java-champions.java.net) Martijn is a DZone MVB and is not an employee of DZone and has posted 10 posts at DZone. You can read more from them at their website. View Full User Profile

Modularity is Hard. Lets do a Jigsaw.

03.03.2011
| 7658 views |
  • submit to reddit

Before we get underway, we want to make the point that all of this is based on our current understanding of the positions of both the OSGi folk and the current plans for Jigsaw. We're not an expert in either, so there may well be egregious lies in this post! Informed comments from people who are an expert in either technology would be very welcome. Also this item is more or less a copy of our recent blog post, you may find further comments there :).

Technologists don’t possess crystal balls. Early releases of technology platforms often have problems in them that are not ironed out (or even discovered) until much later.

One example of this is the Java platform’s lack of generalised modularisation and dependency management capability in the core. Sure, there are jar files, and as a basic means of shipping around units of functionality which are larger than a class, they’re OK.

However, when dealing with larger systems, the model of “just ship around a bunch of jars and manually manage the dependencies” starts to break down. What’s needed is a way to automatically manage the dependencies between functional units, via some metadata which is shipped within each unit.

This is where systems like Apache Ivy and Maven come from – they run outside of the core platform and automatically manage a repository of jar files. Build and runtime dependencies are then much easier to manage – all the jars are in one place. However, note that the platform doesn’t provide any support for these platforms out of the box – a classpath still has to be managed for start scripts, etc.

What would be better is if the platform provided for automatic management of dependencies in the core. Both of the mostly widely used systems broadly agree about which relationships between functional units need to be expressible, so there’s no major disagreement about what needs to be expressed.

The simplest cases are that a unit needs to be able to say that it requires:

  • A particular version of a certain other unit
  • a particular version or anything higher
  • any version within a given range.

Dependencies should also be able to be marked as mandatory or optional, and different isolated contexts within the same JVM should be able to have different, incompatible versions of the same unit.

This much is basically agreed upon. Where the different viewpoints diverge is over what constitutes a functional unit, and at what stage of platform startup the dependency management and modularity functionality should kick in. The two big schools of thought are the OSGi view and the Project Jigsaw view.

OSGi
  1. Unit of deployment should be based around the package or a group of packages that form a bundle. This reduces conceptual burden on developers to learn a new model and is simpler.
  2. Dependency management should start once the platform is fully bootstrapped. This allows the benefits to be brought to any compliant installation, and doesn’t require changes to the core platform.

 

Project Jigsaw
  1. Unit of deployment should be a new concept – the module. This is “larger” than a package, and packages can also be split between modules.
  2. Changes should be made to the core, and the platform itself should be aware of module dependencies as early as possible. This is more work, and requires more co-ordination between implementations, but has potentially has big wins (quicker startup time, smaller footprint).

Which should you choose for your application? Well, Jigsaw is still being developed, and won’t land as part of Java 7 – it’s targeting Java 8. OSGi is a production technology, used in a surprising number of places (if you’ve ever used Eclipse, you’ve used OSGi technology, you just probably weren’t aware of it). However, it is still maturing – there are gaps around tooling, and there are gaps in the standard which has led to different approaches between vendors, with regard to e.g. bundle deployment.

If you want to learn a new technology, then Jigsaw is still very new, and a moving target, whereas OSGi is here today. On the other hand, unless you have a clear benefit from deploying something like this today, it may be preferable to live with the pain of Ivy/Maven and wait for the space to mature.

Finally, as a modest proposal, let’s talk about deprecation:

Java has always been bad at deprecation. We’ve known that Thread#stop and friends were the wrong thing to do for a very long time, but they’re still there, hanging on as deprecated methods. In the current setup it seems impossible to do anything to remove them. With a wide-ranging modularity solution, such as Jigsaw, in place – could we produce a release of a core module which removed the likes of Thread#stop and Object#finalize ?

Cheers, Martijn and Ben (@java7developer)
Published at DZone with permission of Martijn Verburg, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Andy Till replied on Thu, 2011/03/03 - 3:52am

Anything that increases java startup time at the moment is definitely a bad thing, which means any library that loads configuration about plugins definitely should not be in core java. 

I'm definitely in the camp where a unit of deployment should be bigger than a package.  There is sometimes a conflict between package protection and a package becoming too big to navigate.  Packages like org.junit.internal should not have to exist.

Mladen Girazovski replied on Thu, 2011/03/03 - 8:45am

Unit of deployment should be the package. This reduces conceptual burden on developers to learn a new model and is simpler.

 This is not how OSGi is used, a package could be the smallest unit of deployment, but in practise, it is not just a package, but more than one, representing a component, a bundle.

There is a difference in OSGi between deployment of bundles and how dependant modules/packages are refered to.

Martijn Verburg replied on Thu, 2011/03/03 - 12:59pm in response to: Mladen Girazovski

Hi Miaden, That's a fair point, I'm going to edit the article to make that clearer. Thanks for the feedback!

Lester Burnham replied on Thu, 2011/03/03 - 6:54pm

To make my prejudices clear - I don't understand why Jigsaw is even being considered, given that OSGi is here, works, and has several open source implementations under reasonable licenses available. And I think it's disingenuous to say that there are gaps around OSGi tooling - IDE vendors could close those fast if they were properly incentivized (by making OSGi part of JRE), and Jigsaw, obviously, has no tooling whatsoever at this point.

But the more important question is this: why does this need to be part of Java the language? Or if it needs to be, why not integrate OSGi? DOM and SAX proved that outside standards can be made part of the JRE, whereas java.util.logging proved that ignoring outside standards (a.k.a. log4j) leads to a lot of unnecessary extra work (Commons Logging, slf4j) for lots of developers that want to keep options open and are not ready to abandon more powerful alternatives.

It really boggles the mind.

Peter Kriens replied on Fri, 2011/03/04 - 5:04am

Thanks for the good article! As usually the frustrating argument about packages versus artifact dependencies triggers me to write too much text, so I moved it to my blog http://www.osgi.org/blog/

   Peter Kriens

 

Martijn Verburg replied on Fri, 2011/03/04 - 7:32am in response to: Lester Burnham

Hi Lester, take my knowledge with a grain of salt, but I think one of the nice things about Jigsaw is that it can be applied before you bootstrap the Java runtime. I believe that it also can split artifacts down to a level lower than that of packages, which is what the core JDK/JRE needs in order to to be modularised effectively. I've heard some pretty dedicated OSGi folks stating that Jigsaw is probably the right solution for breaking up the JDK/JRE. For apps built on top? I'm hoping that the two sides can meet :).

Martijn Verburg replied on Fri, 2011/03/04 - 7:34am in response to: Peter Kriens

Hi Peter, thanks for your reply - your post certainly adds some interesting points! I got into separate discussion about tooling etc with Neil Barlett, Zoe Slattery and Alaisdair Nottingham, you can find those details here.

Arie Van Wijngaarden replied on Fri, 2011/03/04 - 10:57am in response to: Lester Burnham

Lester,

I could not agree more....

The waste of useful specification/developer time, especially in the Java world, just because of Not Invented Here reasons is amazing.

Regards,
Arie

Cloves Almeida replied on Sun, 2011/03/06 - 1:21pm

I'm all for Jigsaw.

It's the solution to improve the core API without breaking compatibility. CORBA coud be in a "java-corba" module and don't bother us. Server deployments would not need to include AWT/Swing...

Gauthier, Hough... replied on Thu, 2011/08/04 - 1:07pm

Some of there stuff is really interesting. From a purely Free Software perspective, it now clear to me that all of this play is become nicely with Linux package manager. -Gauthier, Houghtaling and Williams

Comment viewing options

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