Evolution in Data Integration From EII to Big Data
Approaches to integrating data are changing with emergence of cloud computing.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
JSRs for Java 7 and Java 8 Approved
Posted by Alex Blewitt on Dec 07, 2010
The results of the recent Java JSRs are in, and all have passed with all but Apache voting consistently against them. Google and Tim Peierls voted against the Java SE 7 and Java SE 8 JSRs, supporting the ongoing licensing issues and field-of-use restrictions for the TCK.
- Project Coin, JSR 334, passed with 13 votes to 1 (and 1 abstention)
- Project Lambda, JSR 335, passed with 13 votes to 1 (and 1 abstention)
- Java SE 7, JSR 336, passed with 12 votes to 3
- Java SE 8, JSR 337, passed with 12 votes to 3
The comments make interesting reading; Steven Colebourne summarises them on one page. Even though the majority voted for the TCK, the comments continue to criticise the licensing issues:
- Google: is voting no because of its licensing terms
- SAP AG: While we believe it is important for Java 7 to proceed now, we want to express our disagreement about Oracle's decision regarding the TCK for Apache.
- Eclipse: is disappointed with the continuing issues around Java licensing
- RedHat: is extremely disappointed with the license terms and that a more open license has not been adopted by the Specification Lead
- Credit Suisse: The current battle around licensing term, however, reveals that Java never actually was an open standard.
Many of the comments also show that they are begrudgingly voting for the JSR if only to move the Java platform forwards from the stagnant location it is today. In addition, modularity raises its voice in both the Java SE 7 and Java SE 8 discussions, with OSGi interoperability being mentioned specifically for the Java SE 8 JSR.
This is also the first time an umbrella Java SE JSR has been put to the vote before it's actually ready. Whilst the work on Project Coin and Project Lambda have made significant progress recently, and the other inclusions (such as JDBC 4.1) in Java SE 7 will be welcomed, the contents of the Java SE 8 JSR include a number of not-even-started JSRs. Perhaps when Java SE 8 is ready, Oracle can point back to the votes and claim that it was agreed by most, even if the Java SE 8 content differs markedly from its original version.
However, with the licensing issue left unresolved, some are calling the JCP “Just Customers, Please” – Oracle does not appear to take the JCP seriously any more. The last stage in this saga will be Apache's resignation from the JCP which will follow up on their earlier threat. Here is what may be the Apache Foundation's last vote on a JSR:
The Apache Software Foundation must vote no on this JSR. While we support the technical contents of the JSR, and earnestly support the need for the Java platform to move forward, we cannot in good conscience vote for this JSR because:
- This JSR's TCK license includes a "Field of Use" restriction that restricts commonplace and mundane use of independent implementations, a licensing element that not only is prohibited by the JSPA but also has been unanimously rejected by the majority of the members of the JCP EC - including Oracle - on several occasions. We can only speculate why Oracle included such an element, but we believe that an open specification ecosystem must be independent of - and protected from - any entity's commercial interests.
- On process grounds, this JSR is in conflict with it's own TCK license. The JSR explicitly states that Java SE is targeted for, among others, embedded deployments. Yet the TCK license specifically prohibits such usages (for example, netbooks) of tested independent implementations. We find this to be a misleading legal trap for potential implementers, and believe that any independent implementation that passes the TCK should be able to be used and distributed under whatever terms deemed fit by the implementer.
- The spec lead has ignored repeated requests from multiple EC members for and explanation of both a. and b.
- The spec lead - Oracle - is in breach of their obligations under the JSPA by continuing to provide a TCK license for Apache Harmony under terms that allow Apache to distribute its independent implementation under terms of its choice. We do not believe that anyone that willfully fails to meet their contractual obligations under the JSPA should be allowed to participate as a member in good stating in the JCP. The rules apply to everyone.
While we understand that it's Oracle's stated intent to move forward irrespective of the EC's decision, we urge Oracle to fix the above-mentioned issues, and continue to work with the members of the JCP within the structure of the JCP to keep Java a vital and viable platform.
Since Oracle looks unlikely to honor the agreement, a statement by the Apache Foundation is expected in the next week.
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Monitor your Production Java App - includes JMX! Low Overhead - Free download
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Tim Peierls has now resigned from the JCP EC
by
Ryan Slobojan
Posted
So developers should do what then?
by
Brian Edwards
Posted
Re: So developers should do what then?
by
Brian Edwards
Posted
Re: So developers should do what then?
by
Ryan Slobojan
Posted
Re: So developers should do what then?
by
Dave Nicolette
Posted
Interesting...
by
Dave Nicolette
Posted
-
As a further update to this, Tim Peierls has now resigned from the JCP EC:
The last straw for me was Oracle's failure to address the ambiguous licensing terms in JSRs 336 and 337 (the Java SE7/8 umbrella JSRs) before the EC had to vote on them. At first I abstained, but I was so dismayed by Oracle's silence that I changed my vote to No, joining the Apache Software Foundation and Google. -
I'm pretty comfortable with some other languages but the Java platform is where I feel at home. If Oracle makes it annoying for businesses to use JVM technologies because of licensing contracts then are they not killing off Java jobs?
This seems to contradict Oracle's, I presume, long term goal of having more people use Java.
All the legalities confuse me so any insight people have to share is appreicated. -
This comment is what I was thinking:
tembrel.blogspot.com/2010/12/resigned-from-ec.h...
Maybe I should step up my Python skills... -
I'm pretty comfortable with some other languages but the Java platform is where I feel at home. If Oracle makes it annoying for businesses to use JVM technologies because of licensing contracts then are they not killing off Java jobs?
This seems to contradict Oracle's, I presume, long term goal of having more people use Java.
All the legalities confuse me so any insight people have to share is appreicated.
I think there may be a general misconception around this - from where I sit, Oracle's fundamental motivation has always been profit (which in theory is the motivation for all companies - they are there to make money), however Oracle's perspective seems to be more focused upon profit in the shorter term rather than in the longer term (whereas those who tend to foster and grow open source communities are more focused on the longer term).
I don't know if having more people use Java by keeping things open and free is the best way to maximize Oracle's profit from this Java thing which they acquired from Sun - there may be much more profit to be had by raising prices and slowly choking off the Java ecosystem. It may mean that there will only be 5 years of life left in Java, but if Oracle turned around tomorrow and started charging everyone $5k per 2 CPU cores/1 server to deploy the JVM in production environments (and removed the classpath exception on OpenJDK's GPL license, which as I understand it would force anyone writing code to the OpenJDK to GPL their own code unless they bought an Oracle license), what reasonable options would people have? Can you simply dump all of your Java code tomorrow and go somewhere else?
It's entirely possible that the widespread perception that Oracle wants to foster and grow the Java community is simply wrong, and isn't the path of greatest profit for Oracle. I admit that that's a very cynical view, and I don't know if it's correct, but it seems like it may be possible - I really hope I'm wrong.
Thanks,
Ryan Slobojan -
Ryan, I don't think your comment is cynical at all. It's just one way of trying to understand what's going on with Java and Oracle. I think it is a valid assessment.
IMHO Oracle's main competitors in the corporate market are Microsoft and IBM. I don't think they would consider the Open Source community a competitor. Market penetration of application platforms other than the JVM and the CLR is low.
By locking down Java, Oracle can create challenges for one of its key competitors, IBM. But the same move would strengthen the other key competitor, Microsoft. Managers who are choosing between the two might find the uncertainty surrounding Java to be a decision point in favor of Microsoft. Of course, most large organizations have both platforms in house, but they could emphasize one or the other in their future in-house development and choices of COTS packages.
I suspect these competitors are foremost in the minds of business planners at Oracle. The Open Source community will be affected by their decisions, but it is not the target of those decisions. -
...that several entities voted "Yes" while claiming in their comments that they support (in one case, "demand") open licensing standards. The way to express support (or a "demand") for open licensing standards is to vote "No." No other statement or action means "We support/demand open licensing standards." Period.
6 comments
Watch Thread Reply