JSR 291 Passes Public Review Ballot with 2 No Votes

Discussions

News: JSR 291 Passes Public Review Ballot with 2 No Votes

  1. The Java Community Process (JCP) Executive Committee has voted on the final public review of Java Specification Request (JSR) 291; The Specification for Dynamic Component Support. What makes the JSR different, aside from the technical details, is the core of the proposal is contained in a document that is not controlled by the JCP. Of the 16 member committee, 9 voted yes, 2 voted no, and 1 abstained. Voting no was Sun Microsystems and Hani Suleiman. Though both parties had no specific complaints about the technology, they both complained that this JSR was nothing more than a pass through to the OSGi specification. From Sun we have the comment;
    Sun is still unclear as to the purpose of this JSR and the role of its expert group in the JCP. There appears to be no need for this JSR as the OSGi specification and its working group already exist
    The comment continues with; Sun is interested in "cleanly accommodating current custom classloading based solutions such as OSGi in JSR 277". Hani Suliman agreed with this position and added the following point
    The expert group seems to have done no work here, and the 'specification' as it stands seems to be one paragraph pointing to an external OSGi document
    He goes on to state that the JCP should foster discussions and explore different avenues. In his opinion, this JSR has not done this. Even Though the Apache Foundation voted yes, that vote did not pass without comment. Though they pointed out that there is precedent for accepting technology from external sources (as reflected in the package structures of org.w3c etc) there was a potential for license compatibility that needed to be worked out.
    we'd like a clear statement in the JCP spec license for this JSR that the necessary IP from all OSGi members is licensed on a RAND and royalty-free basis to any compatible independent implementation of this JSR. We also want to be sure that the spec license and TCK license are provided in conventional JCP manner
    While it is true that Java does incorporate technologies that have specifications controlled by groups other than the JCP, this case seems a bit different in its nature. First point is that JSR 277, the Java Module System, has been created to cover many of the same issues that the OSGi addresses. However, the OSGi offers technology that is in use today while JSR 277 is still trying to resolve many basic issues that will keep it off the shelves until Java 7 at least. This vote raises many questions. Among them are; is it proper for this JSR to just point to an external specification without any further discussion? Should the JSR be responsible to draft its own documents even if they are a carbon copy of existing specifications?

    Threaded Messages (20)

  2. Public Review Ballet ? I'm guessing this is supposed to be Ballot. :-)
  3. Go ahead! With some effort we will have a 4 pages spec.
  4. Also, Suliman? I'm sure someone will say something bile about this article pretty soon now...
  5. I see two significant things here. First, an existing standard was pushed through the JCP for the sake of giving it a JSR number. Honestly, I think this dilutes the value of the JCP. The EC did little more than point to the existing spec. I'm surprised that so many members of the JCP went along with this. Second, Sun voted no but the standard still went through. I'm constantly being told by the ignorant that Sun controls Java and has the final say as to what goes into all JCP specifications. I've been told by a number of different people "in the know" that the JCP is just a Sun puppet organization. This shows the contrary. Java truly is an open platform. Kudos to Sun for letting the community govern itself. The JSR itself is pointless but the fact that it's apposed by Sun and still a standard is rather significant.
  6. Mike Heath:
    Second, Sun voted no but the standard still went through. I'm constantly being told by the ignorant that Sun controls Java and has the final say as to what goes into all JCP specifications.
    The EC voting rules give Sun a veto in specific cases : "EC ballots to approve UJSRs for new Platform Edition Specifications or JSRs that propose changes to the Java language, are approved if (a) at least a two-thirds majority of the votes cast are "yes" votes, (b) a minimum of 5 "yes" votes are cast, and (c) Sun casts one of the "yes" votes. Ballots are otherwise rejected." You can read about it here : http://www.jcp.org/en/procedures/jcp2 To my knowledge, Sun has never exercised this power. Sun also controls the evolution of the process via control of the PMO.
  7. Ohdear[ Go to top ]

    While the article is certainly newsworthy, it's dissapointing to see a potentially interesting topic diluted by extremely poor editorial control. How hard is it to look up my name and ensure it's spelt correctly? How hard can it be to at least nod in the general direction of professionalism? This isn't an email to a friend, it's (allegedly) a professional news article. Secondly, it's interesting that the editor yet again managed to slip in personal bias via a dig at JSR-277. The loudest JSR-291 people are in fact members of JSR-277, and that EG has gone to some lengths to ensure that 291 can implement 277. The article is also incorrect in claiming that 'basic issues' is what's pushing off the release until Java 7. JSR-277 was always intended to target Java 7, the idea being that module stuff should be baked into the JVM, and not just an addon. This is good for *everyone* as it allows anyone to ship modular code and to explicitly declare exposed APIs. Editorial ignorance, sloppiness, and idiocy aside, I personally found the vote results dissapointing. Many of those who objected when the JSR was initially filed did not bother to vote, and many EC members routinely vote yes to pretty much everything. Apache for example can always be relied on to agree to everything, as long as it's not openly hostile to OSS. You could file a JSR for 'javax.X [edited] integration with javax.[edited]' and promise to conduct the EG in an open manner, and thus buy the Apache vote, since they don't really care about the health of the JCP or Java, and are more concerned with the hippiness of JSRs instead. Message was edited by: kirk@javaperformancetuning.com
  8. Re: Oh dear[ Go to top ]

    How hard is it to look up my name and ensure it's spelt correctly?.
    I'm sure Craig McFlanablanatugathing thinks the same thing :-) Hello pot, kettle here
  9. Re: Ohdear[ Go to top ]

    it's interesting that the editor yet again managed to slip in personal bias via a dig at JSR-277.
    Where is the personal bias? Is it not a fact that OSGi is being used where as JSR-277 work is still in the labs?
    I personally found the vote results dissapointing. Many of those who objected when the JSR was initially filed did not bother to vote, and many EC members routinely vote yes to pretty much everything.

    Apache for example can always be relied on to agree to everything, as long as it's not openly hostile to OSS.
    Thanks for the update. FYI, 'dissapointing' is spelled disappointing. Kind regards, Kirk Pepperdine
  10. professionalism[ Go to top ]

    Every so often I go into a retail establishment and find two or more of the employees engaged in some kind of dispute among themselves, or perhaps a gripefest about how terribly their employer treats them. If I cannot get their attention when I need it I have been known to break into their bubble by loudly saying "Please! Not in front of the customers!" Mostly they just goggle at me and have no idea why I intervened.
  11. Re: professionalism[ Go to top ]

    Every so often I go into a retail establishment and find two or more of the employees engaged in some kind of dispute among themselves, or perhaps a gripefest about how terribly their employer treats them. If I cannot get their attention when I need it I have been known to break into their bubble by loudly saying "Please! Not in front of the customers!"

    Mostly they just goggle at me and have no idea why I intervened.
    Izzuh gogglin at yuh too! You waskal you!
  12. Re: Ohdear[ Go to top ]

    Kirk, honestly your article was written unprofessionally and your response to Hani's correction was childish to say the least. Keep in mind that his 'comment' wasn't a professional news posting. As for the rest of the TSS staff, keep up the good work. Best Regards, Richard L. Burton III
  13. Re: Ohdear[ Go to top ]

    ...and thus buy the Apache vote, since they don't really care about the health of the JCP or Java, and are more concerned with the hippiness of JSRs instead.
    Then why are they(Apache) a member. If they don't represent the community or the best interests of the JCP or Java(which I think is a little harsh given their contribution and stewardship to Java projects), Apache should be removed from all committees. Otherwise, this just lends more credence to the irrelevance and amateurism of the JCP. In the final analysis, if JSR hippieness is all that the JCP brings to the table, they may be doing more harm than good with all the inertia,apathy and ineptness that seems to be associated with every activity.
  14. Re: Ohdear[ Go to top ]

    ...Many of those who objected when the JSR was initially filed did not bother to vote...
    RHT did vote but a technical issue on jcp.org led to our vote not being taken in account.
  15. Re: Ohdear[ Go to top ]

    RHT did vote but a technical issue on jcp.org led to our vote not being taken in account.
    Must be a Florida voting system they use there at the JCP ... only count the votes you want to see
  16. Red Hat[ Go to top ]

    Sacha, Can I ask what your vote would have been, if the technical issue hadn't preventing it from being counted? I assume that, since Red Hat is now an OSGi user and a member of the JSR 291 expert group, you have changed your vote to Yes. Regards, Neil
  17. Digging[ Go to top ]

    Hani and fans, I found the editorial professionally written and unbiased. If you do not like the content, make a constructive criticism, don't attack the editor. I have long quit reading the material you produce because of the destructionism present in the content. I would not have read your post had it not been for the fact that this was posted on TSS, a forum that I do respect. Mica Cooper
  18. Re: Ohdear[ Go to top ]

    Hani :
    Apache for example can always be relied on to agree to everything, as long as it's not openly hostile to OSS. You could file a JSR for 'javax.X [edited] integration with javax.[edited]' and promise to conduct the EG in an open manner, and thus buy the Apache vote, since they don't really care about the health of the JCP or Java, and are more concerned with the hippiness of JSRs instead.
    (I know I'm going to regret this, but he is my friend, and I can spell his last name correctly...) The only reason JSRs can be implemented in open source is because of the changes to the JCP process that were forced^H^H^H^H^H led by Apache about 4 years ago. You may not care about that, but it does help create a healthier JCP and Java, and a healthier software ecosystem (in my opinion, anyway). We care very much about the JCP and Java - we want to ensure that it's a safe place to participate and contribute, and that the specifications are safe to implement and use. Apache has participated in the JCP since the dawn of the "modern age" of the JCP, we host both RI's and TCK's for specs as well communities doing implementations of the major platform specs, Apache Harmony and Apache Geronimo. WRT the issue at hand, our position right now is that, like it or not, OSGi is a significant technology in the Java ecosystem (they already are on version 4...), and that doing a JSR is more than (or should be) assigning a JSR number to it and giving it the 'cachet' of the JCP (whatever that is...) It means that the specification will have to be made available to users and implementors under terms consistent with the JSPA, the IP necessary to create, distribute and use compatible implementations will be provided under RAND and royalty-free terms by those that created the specification, and TCKs to demonstrate compatibility will be made available under clear terms governed by the JCP. This isn't in any way a comment/criticism of the terms currently offered by the OSGi Alliance, but simply recognizing that the JCP provides a consistent IP framework that we are all familiar with, and it's a general benefit if those that choose to use or implement OSGi can do it under the terms that govern other specifications in the Java ecosystem. On the other hand, there are risks associated with endorsing externally-controlled specifications, and we have some work to do to identify and provide a framework in which to deal with them. Hani, I'm hoping you'll help. If we're successful, the Java ecosystem gets richer and stronger, and ensures a consistency and predictability on how we participate, create, commercialize and innovate. geir (Apache's JCP EC rep)
  19. Re: Ohdear[ Go to top ]

    Hani, It's a shame that Kirk misspelled your name once. He also got it right once, so perhaps this was a simple typo. I hope that's not enough to qualify him as a moron in your book, but I know that you think an awful lot of people in the Java world are morons. However, I certainly didn't detect any "dig" at JSR 277 in the editorial. There were some facts stated about 277, such as it won't be available until Java 7, and that it still has many issues to resolve, and that most of these issues have already been resolved elsewhere. As for your response about JSR 277, I'm very glad that it will allow me to "ship modular code" and "explicitly declare exposed APIs". Has it slipped your attention that I can do these things today with OSGi? Why exactly should "module stuff" be "baked into the JVM"? This is something we keep hearing from yourself and Stanley, but it's never actually backed up with any justification. After all, OSGi's classloaders are not broken; we are not waiting for some fundamental change in the JVM architecture to make OSGi function properly. It works now, and it works brilliantly, with JVMs all the way back to v1.2. I won't bother to address your attacks on the Apache Group, they can defend themselves adequately, as Geir has already. However in your JCP vote comment you also accused the JSR 291 Expert Group of doing "no work". That was frankly ridiculous and evidence that you have not done your homework, which surely is just as bad as those dastardly EC members who routinely vote yes to everything. JSR 291 was run in the full light of day. The EG mailing list was open to anybody who wished to subscribe (and you can read the archives at http://www2.osgi.org/pipermail/jsr-291-eg/). It should be clear to anybody reviewing the EG activity that they had a significant input to the development of OSGi R4.1 specification. Your complaint (and Sun's) is therefore unfathomable to me, unless it comes from ignorance or bias. Java desperately needs OSGi/JSR 291. We are suffering from "JAR hell" right now and we simply can't wait until late 2008 for Java 7 and JSR 277.. and you know it'll be 2010 before all the big slow corporate Java customers actually allow Java 7 to be installed, right? As the Apache Group noted in their JCP vote comments, there are still some licensing issues around OSGi, and the JSR process is helping to resolve these. JSR 291 is bringing benefits both to OSGi and to the JCP. So Hani, why do you want to kill it? Neil
  20. Companies Tired Of Waiting?[ Go to top ]

    Why so many yesses from large corporations? Are they tired of waiting on the JCP for 277? Are they worried that Java is going to die if Java doesn't copy OSGi right now?
  21. You people should make up your minds: either complain JCPs take too long reinventing something, which everyone will say its too little too late and/or academic, or complain they deliver something fast based on existing solutions but they're not doing their job...