JSR 277 & 294 leads respond to concerns over OSGi overlap and transparency

After the early draft release of JSR 277 a number of questions were raised by the Java community at large about JSR 277, JSR 294 and OSGi.  Concerns included overlap with the functionality provided by OSGi, lack of inclusion of important community members on the expert group, and JSR 277 reinventing existing technology.  InfoQ sat down with Stanley Ho's (Spec Lead of JSR 277) and Andreas Sterbenz ' (co-Spec Lead of JSR 294)  to discuss these items.  Ho and Sterbenz's answers are provided below:

1. What are your thoughts on increasing the transparency of the evolution of this very important JSR in response to comments like these?

"The vibes that I am getting from JSR 277 are not very good. I have tried to contact Stanley Ho (the specification lead) several times over the last weeks but he plays deaf, awfully deaf. Maybe SUN should switch to other mail-servers? The Expert Group started end of June and was supposed to finish before September. It is now February and the information is deafening me. When I desperately tried to get into the JSR 277 Expert Group, Stanley Ho promised regular information updates. I still have to see the first"
http://www.aqute.biz/Blog/2006-02-02

"In fact, the first public announcement of the Early Draft came from a blog by Ivy developer Xavier Hannin, who is, oddly enough, not the spec lead for JSR 277. To add to the confusion, the spec lead's own blog has remained silent over the past 5 (in words: five) months."
http://robilad.livejournal.com/1672.html

A: We're glad to see such vigorous debate in the community generated by the early draft, and again it shows how important this JSR is to the Java community. To increase the transparency of the evolution, we'll collect each and every issue raised through the formal JCP feedback channels and out there in the community, summarize them in public, and then put it before the expert group and reach a conclusion on each issue. We'll make sure the result is evident in the public draft.

2. JSR 277 covers a space that overlaps with technologies such as OSGi, Maven, and Ivy. Yet many have argued that these technologies are not adequately represented by the expert group. Since the JCP is about creating standards and moving the industry toward common solutions, would there be any consideration in altering the expert group to be more inclusive?

A: Our experience at Sun has sometimes been that larger expert groups in other JSRs have not been as productive as if they had been smaller.

JSR-277 has a fairly large (20 members) and very diverse EG to accommodate a variety of viewpoints to learn from the existing systems (e.g. a few members are .NET experts, two are OSGi experts who co-authored the R4 modularity spec, one is Maven's creator and one is Maven's expert, one is Ivy's creator, etc.). Thus, we think these technologies are already adequately represented by the expert group.

Since the size of the expert group is already large, unfortunately, we could not accommodate all requests to join the EG. However, we are very interested in feedback from the entire community, especially in response to the recently published early-draft specification.

3. JSR 277 is targeted for Java 7. I think that technologies such as the ones mentioned above demonstrate that many of the issues JSR 277 is attempting to solve can be done in a JRE indepent backward compatibile manner. Therefore why the hard requirement of Java 7? Furthermore won't this hurt adoption? Corporate organizations are notoriously slow moving to new JRE versions. Has it been consider that they will use alternative technologies which support the version of Java they are on instead of the result of JSR 277?

A: JSR-277 requires deep changes in the Java Runtime and JDK tools, e.g. classloading changes, API changes in class libraries, and tool changes to recognize modules and repositories, etc. However, the APIs for Java SE 6 was set some time ago, so it's already too late to make changes in the shipping JREs to properly support JSR-277. Also, this is a non-trivial technology that takes time, in terms of the specification and the implementation.

Corporate organizations can already use existing solutions if they fulfill their needs. What we're focusing on is to put our best efforts on producing a module system for the next generation Java SE platform that addresses all the issues in the best way, and it takes time. Like other major features introduced into a new release, we believe JSR-277 will bring significant benefits to the table, and developers would migrate to Java SE 7 if they find these benefits appealing.

4. Bloggers have slammed 277 as a severe case of "Not Invented Here Syndrome" compared to OSGi.

http://www.jroller.com/page/murphee?entry=jsr_277_vs_osgi_here
http://www.eclipsezone.com/eclipse/forums/t83134.html

How you respond to this either in terms of why JSR 277 and JSR 294 are different enough to OSGi (JSR 291) or in terms of modifying the scope of both JSR's to be more inclusive to existing technology. Many bloggers see another Hibernate, EJB, JDO situation brewing. A technology standard is created (EJB), the community moves elsewhere (Hibernate), then the standards trying to come back towards developers needs (JDO & EJB), and finally something else is defined in the dust that settles (JPA)?

A: There are many existing and competing systems, such as those represented in the expert group. The whole point of JSR-277 is to learn from the experience of these systems to produce a module system for the next generation Java SE platform that would benefit everyone in the Java community. Synthesizing the best attributes of competing or overlapping technologies is the bread and butter of what the Java Community Process is about.

Many existing systems offer reasonable solutions in their problem space, but it doesn't mean they are trying to solve the same set of problems as JSR-294 and JSR-277 (e.g. information hiding, classpath hell, jar hell, extension hell, etc. - these are not comprehensively addressed by any existing system; in fact, they all suffer from these problems in some degrees).

JSR-277 and JSR-294 are attempts to produce a module system to address these problems directly in the next generation Java SE platform, with versioning support, new distribution format, repositories, and built-in language and JVM support.

Besides, JSR-277 is as much an extensible framework for module systems as it is a module system. Its inclusive architecture allows 3rd parties to plug in alternate implementations for the repository mechanism and for the actual module system implementation. In other words, it can serve as an umbrella under which various existing systems can sit and add values. We are still working out many of the details and would appreciate feedback on this topic.