While I enjoy a good technical discussion I try to avoid conflict where I can. So it's somewhat worrying to wake up and realize that all the projects I work on are involved in heated debates!
The most obvious one is between
OSGi and
Jigsaw - now personally I have no issue with a modularity system that's optimized for the JVM. Having done time as a JVM developer I realize that often what's best for the JVM is not what's best for applications, and vice versa. Sometimes you just need shortcuts that you can trust to 'internal' users but would be dangerous if exposed to everyone, for example the Unsafe class. That said, I would be cautious in using Jigsaw for modularity outside of the JVM - this is not based on any technical point at the moment, it's purely inertia on my side while Jigsaw is being fleshed out. I don't have much spare time and I'm currently in my comfort zone with OSGi.
My hope is that JSR
294 can act as a bridge between OSGi and Jigsaw by standardizing some of the details needed to declare and define modules - like naming, version ranges, imports, exports, etc. We could then use JSR 294 metadata to configure OSGi bundles in place of the dependable (but non-type-safe) manifest, removing a major bugbear of new developers. Unfortunately it looks like JSR 294 might fudge this issue and go with opaque strings that only the target module system understands :(
In my ideal world JSR 294 would define a small common module API without trying to standardize a complete module system. Trying to capture too much detail can lead to long, contentious discussions and puts a straightjacket on future solutions. Specifying not enough (opaqueness) makes portability a joke.
Does this sound familiar? This is essentially what's happening with JSRs
299 (Contexts and Dependency Injection) and
330 (Dependency Injection for Java). JSR 299 defines the API and semantics for a complete dependency injection system for Java EE, whereas 330 is defining a much smaller API that just covers injection points and configuration in Java SE. Ideally people could code to the smaller 330 API to gain some portability between DI frameworks without having to rewrite or use a completely different API for the more complete JSR 299 specification. Developers can choose the level of portability they want.
While there has been some recent friction on the JSR 330 list, it does look like people are making significant concessions to standardize this reduced API. This is great news for people like me who provide DI extensions (in my case
peaberry) because by adopting this API my extension could conceivably be used with Guice, Spring, or any other framework that supports JSR 330 - even fully-fledged JSR 299 systems.
Now if the same thing happened with JSR 294 I could package peaberry so it could be used as an OSGi bundle, or a Jigsaw module, or even as an element in some future modularity framework I've not yet heard of.
Unfortunately finding the sweet spot between defining too much and too little is a hard process, and isn't helped by personality clashes. Another example of this is the recent flare up between
P2 and
OBR... both provide a form of requirement/capability model to help decide what bundles should be deployed to satisfy a given need, but P2 goes further and defines additional details necessary for Eclipse installations. That doesn't mean they can't co-exist or there isn't a common subset of metadata they could share, which is what RFP
122 is hoping to achieve.
Indeed the
Nexus Maven repository manager (Professional Version) already supports P2 and will support OBR in 1.3.5 - and when the updated OBR spec is finalized I'm sure it will be just as straightforward to handle that as well.
The last project from my title is
Maven - a name associated with peace, harmony, and logical discussions that has never been involved in this kind of dispute ;) Seriously though, it is interesting that the next version of Maven may be based on both Guice (hopefully using the JSR 330 API) and OSGi (abstracted via the JSR 330 API using peaberry). Its artifact resolver will probably be pluggable, allowing it to take advantage of both P2 and OBR metadata.
So in the end these spec discussions are not the end of the world: even without agreement it is often possible to map between different forms of API and metadata. Of course it is much easier if things like version formats are standardized (any chance of this 294 gurus?) but even with opaque strings I bet someone will end up writing a Jigsaw-OSGi adapter...
