|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 21
Messages: 21
Messages: 21
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
JSR 291 Passes Public Review Ballot with 2 No Votes
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?
|
|
|
Message #226008
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSR 291 Passes Public Review Ballet with 2 No Votes
Public Review Ballet ? I'm guessing this is supposed to be Ballot. :-)
|
|
|
Message #226010
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSR 291 Passes Public Review Ballet with 2 No Votes
Go ahead! With some effort we will have a 4 pages spec.
|
|
|
Message #226014
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSR 291 Passes Public Review Ballet with 2 No Votes
Also, Suliman?
I'm sure someone will say something bile about this article pretty soon now...
|
|
|
Message #226017
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSR 291 Passes Public Review Ballet [sic] with 2 No Votes
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.
|
|
|
Message #226024
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ohdear
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
|
|
|
Message #226032
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Oh dear
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
|
|
|
Message #226044
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ohdear
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
|
|
|
Message #226054
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
professionalism
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.
|
|
|
Message #226056
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: professionalism
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!
|
|
|
Message #226060
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Companies Tired Of Waiting?
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?
|
|
|
Message #226098
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ohdear
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
|
|
|
Message #226100
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ohdear
...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.
|
|
|
Message #226134
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ohdear
...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.
|
|
|
Message #226135
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSR 291 Passes Public Review Ballot with 2 No Votes
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...
|
|
|
Message #226138
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ohdear
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
|
|
|
Message #226169
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Digging
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
|
|
|
Message #226172
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSR 291 Passes Public Review Ballet [sic] with 2 No Votes
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.
|
|
|
Message #226173
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ohdear
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)
|
|
|
Message #226363
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ohdear
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
|
|
|
Message #226366
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Red Hat
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
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
