Slashdot Mirror
Java SE 7 Finally Approved By JCP, 13 To 1
medv4380 writes with news from InfoWorld about the near-term future of Java: "Java Platform, SE (Standard Edition) 7 has been passed this week by the JCP Executive Committee for SE/EE (Enterprise Edition), by a vote of 13 in favor and 1 — Google — against. Oracle, IBM, VMware, Red Hat, and Fujitsu are among the affirmative votes, and two committee members — Credit Suisse and Java architect Werner Keil — did not vote. Specifically, committee members voted on Java Specification Request 336, which pertains to the Java upgrade. Voting on the public review ballot for Java SE 7 finished up earlier this week after beginning on May 31. Java SE 7 still faces another vote on a final approval ballot."
I don't like this summary. Who cares? Tell me why the vote was important. Why "finally"? Was it delayed? Why did Google vote against? What are the new features? Why is this on the front page?!?
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
"While Google supports the technical content of this JSR, we are voting no because of its licensing terms"
Typical
Interesting that they view the licensing and transparency as deal-breakers, and doubly interesting that a majority of the committee members feel somewhat supportive of that position (but not enough to vote against).
"Little does he know, but there is no 'I' in 'Idiot'!"
Interesting that they view the licensing and transparency as deal-breakers, and doubly interesting that a majority of the committee members feel somewhat supportive of that position (but not enough to vote against).
How I understand it is this: The licensing terms restrict Google from making their own platform specific version using the spec. It basically stops Google from rebranding Java to "Gava" and using it as the language of choice on Android.
Google's complete comment from the vote log: "On 2011-06-02 Google Inc. voted No with the following comment: While Google supports the technical content of this JSR, we are voting no because of its licensing terms. As per the JCP resolutions of 9/25/2007 and 4/7/2009, "TCK licenses must not be used to discriminate against or restrict compatible implementations of Java specifications by including field-of-use restrictions on the tested implementations. Licenses containing such limitations do not meet the requirements of the JSPA, and violate the expectations of the Java community that JCP specs can be openly implemented." The proposed license clearly violates this requirement (see Exhibit A, Section II). Oracle was duly reminded of this when JSR-336 was first proposed, but has done nothing to address the issue. It would be wrong to condone the inclusion of field-of-use restrictions in a TCK license, as this clearly violates the JSPA, by Oracle's own admission. Google does not want to slow the progress of this release, but we do believe it is critical that this issued be addressed, in order to comply with the JSPA and to preserve the openness of the Java platform." Possibly the licensing terms cause trouble for the dalvik platform.
On 2011-06-02 Google Inc. voted No with the following comment:
While Google supports the technical content of this JSR, we are voting no because of its licensing terms. As per the JCP resolutions of 9/25/2007 and 4/7/2009, "TCK licenses must not be used to discriminate against or restrict compatible implementations of Java specifications by including field-of-use restrictions on the tested implementations. Licenses containing such limitations do not meet the requirements of the JSPA, and violate the expectations of the Java community that JCP specs can be openly implemented."
The proposed license clearly violates this requirement (see Exhibit A, Section II). Oracle was duly reminded of this when JSR-336 was first proposed, but has done nothing to address the issue. It would be wrong to condone the inclusion of field-of-use restrictions in a TCK license, as this clearly violates the JSPA, by Oracle's own admission. Google does not want to slow the progress of this release, but we do believe it is critical that this issued be addressed, in order to comply with the JSPA and to preserve the openness of the Java platform.
The problem is that Java is not free at all. The platform is open source (GPL2), but Oracle does not allow any compatability testing between different implementations e.g. with a more permissive Apache license. Basically, because of patents, it is open source as long as you keep your frickin' hands off of it. Google has a strong invested interest because it uses Apache classes (which cannot be validated as being Java) within its Android operating system. And they are getting sued over it. Google certainly uses Java a lot, although it would go way to far to name it a "Java shop".
The problem is that Java 7 has been long, long overdue. It's not that 1.6 is bad; far from it. It's just that people are starting to lose interest. For Java to stay alive, we *need* 1.7 and quickly - and if possible with as much buzz as possible. Java still is by far the best maintainable language. That is something we don't want to loose, especially since there are few competitors regarding stability, security and maintainability.
In the end, they are essentially choosing between progress and halting because of licensing issues. As halting it now ay come to stopping Java altogether. Personally I think that Oracle should immediately stop with the licensing bulshit around android, but this is a technical issue, and I would have voted yes myself.
Typical
You expected Google to vote in favor of something that validates the Java-patent-troll-lawsuit against them?
No sig today...
Does "Java 7" mean we're in for another never-ending series of huge updates, none of which will bother to remove the previous update from my disk?
If so... no thanks.
No sig today...
No, the license terms prevent Google(actually Apache) from releasing a non GPL implementation of Java (Apache Harmony). The FOU restrictions are inherently incompatible with ASL.
And it is only a FOU restriction on the TCK. The Testing Compatability Kit. In order to be declared a conformant implementation of Java you must pass the TCK.
Until Harmony passes the TCK, (which would break the ASL) Harmony is not Java, and is therefore in violation of Java patents. And remember Harmony is "Java", it has to work like java and have the same bugs as java. In most of these cases it isn't possible to workaround the patents because it has to be the same as java.
If the TCK didn't have FOU restrictions Harmony would be labeled a version of Java, like OpenJDK, Jrockit, J9, IcedTea and probably a few others. Harmony would get the Patent grant, and anybody who used Harmony (Android) would be free from litigation of patents in Java (Oracle v. Google).
Oracle's versions of Java cannot be used in mobile (primarily, but I think there is something about ATM's and set top boxes as well) without paying oracle a bag of cash. Any other implementation can't be used in mobile either unless Oracle gets a bag of cash. Harmony having the patent grant, and being ASL would effectively give google a free (speech and beer) JVM to use wherever the hell they want regardless of Oracle wanting the bag of cash.
Ideally Google would just use Java on Android without paying Oracle. Rebranding Java to Dalvik was just to try and prevent Oracle from getting money. Rebranding Java to Gava is the least good situation for google, other than paying Oracle $5/handset for Java.
It is symptomatic of the JCP (Java *Community* Process -- in reality run by a committe of about a dozen international corporations)
Of course: those companies have a lot of people working on Java. They *are* a large part of the community.
that is filled with bureaucracy and childish infighting.
They are having serious issues regarding licensing. To call that bureaucracy and infighting? I presume that is rather subjective. Personally, I think it is rather a defining issue.
IMHO the writing is on the wall for Java because stuff moves way to slowly. Java has JPA which would have been a really nice ORM... about five years ago but technology moves faster than that. Compare that to C# whose development process is entirely controlled by a single company and you have Linq2Sql and the Entity Framework.
Java as a language is mainly build on being easy to maintain. A lot of people don't believe in Linq2Sql as it merges two languages together. It's rather questionable if that is the right road to take. It's certainly not the Java road, and never was. You can argue about that during language design, but that's how it is.
There is more api churn, but at least stuff is moving forward.
It was especially apparent with J2ME which went from market leader to an also ran player. All the companies invested in Java tried to stab each other in the back and abused the JCP to gain advantages on each other. The way several of the mobile JSR:s were specified, weren't so much dependent on what would be the best technical decisions but on compromises intended to make everyone happy and not give the market leader (who already had a working reference implementation) an edge.
Many Java API's, especially those in the Java standard edition are very well defined. Take a look at the collections API, the SmartCard I/O API, the way cryptographic providers work etc. etc. This is much less the case with the embedded Java forms, I give you that. Personally, I don't think that the fastest mover should always get the support. The best technical solution should be choosen, and I think this is one of the strengths of the JCP. Note that that might not always translate into the best marketing, that's true. But at least it is more or less fair, and it stops horrors like jPCSC from becoming an API standard instead of smartcardio.
That's why some of the JSR:s are so bizarre such as the Mobile Sensor api.To bad, I say. The Java platform had so much potential that will go to waste. It would have been hard enough for Java to complete if the CLR wasn't superior technology, but it is. The future looks fairly bleak for Linux on the server side without a competitive virtual machine.
IMHO the Java VM is pretty much compatitative, and it's getting better too. If linux fails, I would be very surprised if it is because of the performance of the Java VM (personally, I think they have much more urgent problems than that, and I'm typing this from an Ubuntu desktop...).
Thanks, I'm pretty well versed in English, but it's not my native tongue. And with slashdot you can only spend so much time reviewing your article, It's approx. one hour before people start to loose interest.