Webcam

The sad state of application packaging

By Damien B on Saturday 22 March 2008, 10:01 - Cyberpunk - Permalink

First, RFE #4648386, opened more than 6 years ago: 6th March 2002. The request is to allow the compositing of jars, ie. having J2SE providing a ClassLoader able to load classes from archives nested into another archives (typical case of an EAR containing WARs themselves containing JARs). Secondly, JSR 277: JavaTM Module System, to solve on a broader scale the same problem: how to package? How to version? How to mark dependencies? Among the expert group, we can find Jayasoft, a company now defunct, who created the dependency manager Ivy (now an Apache Ant subproject). Also, Brett Porter, from the Maven management committe. We can find as well Richard S. Hall, the architect behind Oscar, the OSGi r4 implementation from ObjectWeb (no release since almost 3 years ago, one commit 6 weeks ago after two years of inactivity), and in the management committe of the Felix project (the successor of Oscar, now under the Apache umbrella-ella-ella). That JSR was started 3 years ago, in June 2005. Status? An early draft, which seems after a quick reading well advanced, published in October 2006, nothing since then.

So? Only OSGi remains. The main problem is that OSGi, touted as "the dynamic module system for Java™", is in fact "a service-oriented, component-based environment": a runtime environment for executing component-based services. Here enters JSR 291, with the same Richard S. Hall on board; that JSR aims at putting OSGi under the JCP roof, and that one has achieved a final release status on August 2007. So we have a component based environment, but without the component packaging defined in JSR 277... They explain :

JSR 277 has been filed to examine changes to the static module definition to be used within the Java SE platform for Java 7 (Dolphin) and beyond. JSR 277 is targeted for specification delivery in 2H/2007 with RI/TCK delivery as an integral part of Dolphin in 2008.

This JSR aims to address the current needs for dynamic components based on existing Java SE platforms. When Dolphin becomes available, the specification lead of this JSR will either perform a maintenance release of this JSR or raise a follow on JSR to add Dolphin to the list of compatible supported platforms and to exploit Dolphin technology for static modules, as appropriate.

So for them, it's better to change the packaging format for a complex platform, than establishing the format first, which is a must simpler task and has a much bigger usefulness. But it's true that the timeline established for JSR 277 is indeed targeted at Java 1.7. The difference is that JSR 277 works on a 3 years calendar, whereas JSR 291 achieved the full cycle in less than a year and a half, with basically the same people in the expert group. It has to be noted that the final release of the JSR 291 specification makes no mention at all of the JSR 291, or its expert group, for one simple reason: it's the OSGi R4 specification, untouched. This is what is called "The JSR-291 Dynamic Component Support for Java SE, Version: 1.0 Specification (the ``Specification'') references the OSGi Service Platform Release 4 Core Specification". You knew Ctrl+P for Pasting, there is now an alias, Ctrl+R for Referencing.

7 months ago, Ryan Slobojan on InfoQ summarized the situation in relation to JSR 316 (Java EE 6), with the next level of dependency: 316 depends on 277 but not 291, whereas Java EE is a "service-oriented, component-based environment", and should be logically based on 291 (which would be an extremely major shift). In that article, Glen Normington, ex-Core Platform Expert Group at OSGi Alliance and ex-IBM, and now Spring Source (a company which not so long ago has based its strategy on OSGi), is deemed to have tried "to present a more measured opinion on the debate", let's look at it:

The dream solution is clear: JSR 277 should adopt JSR 291, underpinned by language and VM support in JSR 294, and add the JSR 277 repository architecture.

JSR 294 is JSR 277 little brother, which aims at adding a fifth notion of visibility in Java (the 4 existing are public, protected, package and private), and this indeed needs a modification in the JLS. As of now, JSR 294 has lost his initial initiator and spec lead almost two years ago, and the JSR page has not been updated. But suggesting that JSR 277 should just adopt directly the OSGi bundle format is just pure malice. Recently, Glyn Normington opened a bug to do just that, and excite the OSGi fanboyz base to vote for it. And it's working! Instead of voting for the original RFE #4648386 (which is a real Request For Enhancement), they vote for that 6650394, "look ma, OSGi rulezzz you suX0rzzz", and now it's only 23 votes behind. But all considered, 138 votes against 115, it's only shows that a very small number of Java developers are voting for bugs and RFE on Sun's site.

To conclude... nothing. It's just sad to have nothing usable out of the J2SE box with relation to RFE #4648386. Further reading (don't forget the comments):