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?

Public Review Ballet ? I'm guessing this is supposed to be Ballot. :-)

Go ahead! With some effort we will have a 4 pages spec.

That includes someone helping the police for an investigation and being eliminated from the list of suspects. i think thats one of liberal labours new additions to the constitution.

Limousine Toronto

Also, Suliman? I'm sure someone will say something bile about this article pretty soon now...

Around the neighbourhoods where houses are at and also be ready to pass along wattle tree farm golf course. good luck, wouldnt you ask people around your area, like from school, work, uni. whatever you do.

Prom Limo Toronto

If you want to link straight to YouTube's website, ethically you should keep the brand, because they're letting you use their bandwidth for free. If you want to remove the brand, you should upload it to your own server space.

Brampton Limousine

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.

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.

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

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

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

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.

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!

this is really an intriguing outcome. I want to learn more about this thread so I am happy I found it! Still have to read the rest of the comments though. Also I am looking for the best student credit cards if anyone out there is a student?

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

...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.

...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.

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

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

Is it proper for this JSR to just point to an external specification without any further discussion? This might need further discussion. IMO ------ air force ones, air jordan

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

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)

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

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?

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...

Seriously, do you really think California can elect anyone any better? For god's sakes they put Nancy Pelosi in Washington. With this kind of record, sad to say, but California gets just what it asks for.

hermes handbags

You really make it seem so easy with your presentation but I find this topic to be really something which I think I would never understand. It seems too complicated and very broad for me. I am looking forward for your next post, I will try to get the hang of it!

Search Engine Optimization

Get out and vote. Get your friends out and vote. Find as many people as possible and get the out and vote. That way you won't have to try and throw out any votes.

cheap air jordans

You really make it seem so easy with your presentation but I find this topic to be really something which I think I would never understand. It seems too complicated and very broad for me. I am looking forward for your next post, I will try to get the hang of it! internet marketing

 

You should consider getting your own home inspection in advance, so that you don't have any surprises that a buyer might raise during negotiations. You can disclose a copy of the inspector's report to those qualified & serious buyers who intend to make an offer, and if the report is thorough and well-written, they may accept the report without going out to pay for another one of their own.

Flyer Design

Yes the recession has hurt Thailand tourism is way down, and as jonny said some hotels are raising prices to make up for the loss as crazy as it sounds. Also export are down, soon you will see more and more Thais returning to the country side and back to farming.

nfl jerseys

In Pattaya there are many condo blocks part built and now abandoned due to the failure of the devolper selling units off plan. This is most probably linked to the present global recession.

louis vuitton

Although good project managers use KLOCs only in joking terms these days, no better metric has gained universal acceptance. The 'ton' is a strong contender as it refers to the mass of software, rather than its volume. 'kiloton' and 'megaton' are useful for larger software projects, especially in the defence sector. how can you make your hair grow faster

Ballot design can aid or inhibit clarity in an election. Poor designs lead to confusion and potentially chaos if large numbers of voters spoil or mismark a ballot. Thanks.

Regards,

personal statement for graduate school