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.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?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.
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.4. Bloggers have slammed 277 as a severe case of "Not Invented Here Syndrome" compared to OSGi.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.
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.
/filters:no_upscale()/sponsorship/topic/2c0d72d2-1768-47c2-8f5b-24f3ef0ae0e0/QconNYrsb-1679560094156.png)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/articles/gdpr-with-spring-and-aop/en/smallimage/easy-implementation-of-GDPR-with-aspect-oriented-programming-small-1684505109873.jpg)
/articles/open-source-java-profilers/en/smallimage/unleash-power-of-open-source-java-profilers-small-1681206807197.jpg)
/articles/rmi-to-websocket/en/smallimage/migrate-a-RMI-based-legacy-application-to-WebSocket-small-1680106723513.jpg)
/articles/rapid-startup-of-your-cloud-native-java/en/smallimage/logo-1680293937095.jpg){kind=logo}
/articles/billions-messages-minute/en/smallimage/LOGO-1679471830613.jpg){kind=logo}
/presentations/java-compiler-intermediate-representation/en/smallimage/chris_seaton-s-1679038354209.jpg)
/minibooks/jhipster-mini-book-7/en/smallimage/logo-1677849630224.jpg){kind=logo}
/articles/series-apache-kafka-streams/en/smallimage/apache-kafka-article-series-logo-small-1673455781546.jpg){kind=logo}
/presentations/jfr-observability/en/smallimage/Ben Evans-s-1675024642432.jpg)
/articles/secure-kafka-cluster-strimzi/en/smallimage/securing-a-kafka-cluster-in-kubernetes-using-strimzi-small-1671647644310.jpg)
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/articles/graalvm-java-compilers-openjdk/en/smallimage/small-image-jdk-2023-1671096273181.jpg)
/articles/java-jvm-trends-2022/en/smallimage/InfoQ-Trends-Report-small-1670863712433.jpeg)
/articles/api-design-review/en/smallimage/API-design-reviews-are-dead-long-live-API-design-reviews-small-1684310900854.jpg)
/articles/delivering-fast-testing-strategies/en/smallimage/deliver-fast-tests-have-to-last-small-1685548178496.jpg)
/articles/eda-mediator/en/smallimage/event-driven-architecture-with-mediator-topology-small-1685547200315.jpg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
Community comments
OpenJCP?
by Stuart McCulloch,
Re: OpenJCP?
by Scott Delap,
Re: OpenJCP?
by Stuart McCulloch,
Re: OpenJCP?
by Stuart McCulloch,
WTF?
by Cameron Purdy,
Re: WTF?
by John O'Shea,
Re: WTF?
by Cameron Purdy,
Re: WTF?
by Stephen McConnell,
Re: WTF?
by Stephen McConnell,
Disconnect
by Peter Kriens,
Re: Disconnect
by Stephen McConnell,
OpenJCP?
by Stuart McCulloch,
Your message is awaiting moderation. Thank you for participating in the discussion.
In the interests of openness, Stanley Ho and Andreas Sterbenz (misspelt in the original article) are both Sun employees. Can we look forward to an interview with the spec lead of JSR 291, to get a view from the other side of the fence?
(Disclaimer: I'm an ex-IBM employee, and my comments aren't necessarily the views of my current or former employers)
Re: OpenJCP?
by Scott Delap,
Your message is awaiting moderation. Thank you for participating in the discussion.
We are always striving to be fair. The questions in the JSR 277/294 piece do not to directly transition as JSR 291 questions. Is there anything in particular you would like answered by the JSR 291 spec lead? the misspelling on Andreas' last name has been corrected as well =).
Re: OpenJCP?
by Stuart McCulloch,
Your message is awaiting moderation. Thank you for participating in the discussion.
Quick thoughts:
Do they see a way forward to reconcile JSR 291 with the early draft of JSR 277, especially in the areas of module metadata, version numbers and dependencies?
Will it be easier to export modules as OSGi bundles, or will OSGi build on modules?
How have they perceived the openness of JSR 277 as fellow members of the JCP?
... but I'm sure other InfoQ readers have questions they'd like to ask
Re: OpenJCP?
by Stuart McCulloch,
Your message is awaiting moderation. Thank you for participating in the discussion.
Sorry, that second question should read:
Will it be easier to export OSGi bundles as modules, or import modules into OSGi?
WTF?
by Cameron Purdy,
Your message is awaiting moderation. Thank you for participating in the discussion.
Sorry to point out the obvious, but none of the questions were answered, and none of the concerns were addressed.
I could re-write the entire interview in two sentences: "Thank you for taking the time to ask us inconvenient questions highlighting the reality on the ground. We are nonetheless continuing on the course that we already decided upon, and excluding those who disagree with our course."
Is there anyone home at Sun who has the guts to answer why OSGi is not just adopted as-is? Does it suck? Is it a licensing problem? Does it kill kittens?
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid
Re: WTF?
by John O'Shea,
Your message is awaiting moderation. Thank you for participating in the discussion.
Completely agree, nothing to seen here, move along.
That said, I am glad InfoQ published this as by inference it confirms (again) that JSR-277/294 have absolutely no interest in producing something that will fit with JSR-291 (a.k.a the Real World). The fact that Stanley Ho can/will not respond to the questions raised in the comments on his own blog entry(1) backs this up.
These JSRs hightlights almost everything that is bad about the JCP - closed expert groups, specifications appearing out of thin air. Imagine, these guys are talking about making "deep changes in the Java Runtime and JDK tools" - yikes!
(1)weblogs.java.net/blog/stanleyh/archive/2006/10/...
Re: WTF?
by Cameron Purdy,
Your message is awaiting moderation. Thank you for participating in the discussion.
It is terribly disturbing. This is a blemish on Sun's generally-excellent stewardship of the Java standards process.
For the record, I do not have a horse in this race. I read the JSR-277 page, and downloaded the OSGi "R4" specs today to try to understand why Sun would purposefully start their own competing project from scratch.
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid
Disconnect
by Peter Kriens,
Your message is awaiting moderation. Thank you for participating in the discussion.
A: We're glad to see such vigorous debate in the community ...
A debate is usually an interaction of ideas to find the best solution, I must have missed something?
I think the real question was why SUN did not react to the legitimate questions that were being raised? Despite promises early on, the EDR was the first communication from 277. Anybody that has been in this business knows how hard it is to make fundamental changes once the first document is written.
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.
True, one member EGs are really efficient. Maybe not so effective, but they are efficient.
When I was rejected membership of 277 the EG had 14 members. After my rejection it grew to over 20 members. Anyway, why reject one of the most recognized people in the domain?
A: JSR-277 requires deep changes in the Java Runtime and JDK tools
Huh? I read 277 but I have not seen any "deep changes". Whatever will come out of 294 might require changes in the VM but 277 can mostly be implemented by class loading technology.
One of the first things you should do when you design a system that is supposed to replace an existing solution is to analyze what is good and what is bad about the existing solution. It is so easy to think a solution is "overly complex" when you do not understand the underlying problem domain. For example, ignoring class space consistency makes the spec smaller but it makes the problems in the field larger. I would call that "simplistic" and not simple.
JSR 277 had the unique opportunity to improve on OSGi because they could have made changes to the VM. However, without requirements and proper analysis (and I have seen none) of the existing solutions, it is likely that you end up making the same mistakes (as the EDR shows), especially if you shield yourself from the people that did it before you.
JSR 277 is an unfortunate example of what is wrong about a model where the shepherd is also one of the sheep.
Peter Kriens
Re: WTF?
by Stephen McConnell,
Your message is awaiting moderation. Thank you for participating in the discussion.
John:
Just for reference - Stanley Ho has answered all of the emails I've sent to him (and yes, they were all in relation to 277).
Cheers, Steve.
Re: WTF?
by Stephen McConnell,
Your message is awaiting moderation. Thank you for participating in the discussion.
Cameron:
Have you reviewed the draft 277 spec? I have reviewed both the 277 draft spec (in detail) and I have reviewed the 291 spec (a.k.a OSGI R4). 291 deals with a much bigger picture but if you focus on the subjects of modularization and classloader management - the 277 spec in my opinion is much better choice. One thing you need to keep in mind here is that OSGI is just one of many platforms dealing with the modularization and classloading issues in the java platform.
I have both development and runtime requirements in these areas and OSGI is not a preferred solution. Whereas the 294/277 proposal does establish a viable platform that I can build upon.
Cheers, Steve.
Re: Disconnect
by Stephen McConnell,
Your message is awaiting moderation. Thank you for participating in the discussion.
Peter:
According to earlier comments from yourself the JSR 294/277 processes are dealing with a much smaller subject than OSGI (and on this I agree with you). However, while it is admirable to leverage the OSGI brand I think your pushing things way beyond what I would call 'reasonable'. If one considers the modularization and classloading aspects of OSGI (a small part of the overall OSGI offer as details in the 291 draft) and compares this with the complete 294/277 draft specification, the later presented itself as a seriously better specification. Clearly there is a tangential relationship - no more or less than the relationship to the DPML products.
What is more relevant to the community is the technical integrity of the specifications proposed by 294/277. Are there any substantive technical issues (and I'm specifically excluding noise related to inclusion or exclusion of your favourite named expert).
I went though the 277 draft several times and developed a basic understanding of the impact on a series of products I'm working on. I'm also discussing 294 and 277 topics with people on the OpenJDK project and talking about potential added value tools. My take on 277 in relation to the DPML platform is available here.
www.dpml.net/about/notepad/277
It would be interesting if you did a similar analysis on OSGI.
Cheers, Steve.