"No more Java 7". Yes, I know its a strong statement, but I don't mean it in the way you probably think.
Update: I've followed up this blog with a whole series of articles:
* a description of how IP works in the JCP (pretty picture!)
* a deep dive into the behind-the-scenes world of the JCP to provide a clearer explanation of the lack of a Java SE 7 specification and how this affects the whole Java industry, not just Apache and Sun
* more info from the ASF board meeting minutes
* an exploration of how the JCP doesn't really exist
* a take on the Oracle-Sun deal
What is Java?
Well, the term 'Java' is a complex and overloaded one, including:
- the stock symbol of Sun Microsystems
- the trademark of Sun Microsystems
- the term for a raft of technologies based around the JVM
- a platform (Java SE) based around the Java programming language (
a programming language) - the specification for the Java SE platform (
the specification for the programming language)
This blog post is about the last of these - the Java SE platform specification.
Back in 1997 Sun talked about making the Java programming language into a formal open standard. At that time, the ECMA was the standards body approached. However, Sun withdrew from the standards process and created the Java Community Process instead. Everyone breathed a little easier, as Java now appeared to be an effectively open standard.
The job of the JCP is to "... develop and revise the Java technology specifications, reference implementations, and test suites, the Java Community Process (JCP) program has fostered the evolution of the Java platform in cooperation with the international Java developer community."
Over the years, and with a few hiccups, the process hasn't gone too badly. There are multiple implementations of many of the JSRs, creating a healthy eco-system of competition and improvement. That is after all a key goal of any standard - to define what is necessary to produce a conforming implementation.
The JCP is, in fact, an unusual standards body in that it goes further than most to ensure that every specification must be tested before it is officially allowed to be released as an implementation of the specification. Each JSR (the individual standard) must provide an appropriate specification document, reference implementation and, crucially, a testing kit.
One group that has implemented many JSR specification is Apache. From Tomcat to Geronimo to JMS to the whole of Java EE. (And back in 2002, Apache had to fight to allow any Open Source implementations of JSR specifications.)
So, what has this to do with the end of Java SE 7? Well, as I said, I'm specifically referring to Java the specification. Now many people don't realise this, but as well as the JSRs for Servlets, EJBs and JMS, there are also JSRs for the whole of Java EE and for the whole of Java SE.
The relevant specifications are JSR-176 for Java SE 5 and JSR-270 for Java SE 6. These specifications are no different to any other JSR. The specification documents exist (mostly Javadoc). The testing kit exists. As does the reference implementation (the Sun JDK).
So, is it an open specification and open standard, as promised back in 1998?
Well, the Java SE specification has been implemented by other companies - IBM has a JDK amongst others. However, IBM pay money to Sun for the rights to do this. The question is whether Apache can implement it, just like they implement 25 other JSRs.
Apache's implementation of the Java SE 5 JSR specification is Apache Harmony. However, when Apache came to obtain the testing kit for the specification a whole political game started. Instead of Sun offering the testing kit as normal for each of the other 25 JSRs, they offered a testing kit where the results of the tested code would not be Open Source
Obviously, Apache couldn't accept this limitation, which is against the legal agreement signed between Sun and Apache. Apache complained 2 years ago, but has yet to receive an acceptable response. And no, there is no way a charity not-for-profit like Apache is going to sue a multi-national corporation - who do you think would get the better lawyers?
The key point is that Sun's tactics here were quite deliberate. They knew exactly what they were doing by offering a testing kit with a restrictive license. They wanted to ensure that Apache Harmony couldn't be certified as complete. Sun was going out of its way to ensure that there was no competition to its own JDK.
In the meantime, Sun played the OpenJDK card. It announced the release of the JDK under the GPL license.
Lots in the community (notably those from a GPL background) suddenly became best friends with Sun. Some joined Sun, some now work closely with Sun. Many of these people now believe that there is no danger around Java, and that Richard Stallman's Java trap is over. I think this shows a gross lack of perspective - the code may now be GPL open source, but the specification is now no longer open. Which is more important?
If you can't freely implement a specification*, then I'd argue its not worth the paper its written on
* There are two ways you can implement the Java specification - (1) pay Sun money, or (2) ensure your code is "mostly derived from the OpenJDK".
What about Java SE 7? Everyone isn't noticing the obvious
I started with a contentious statement - that there may not be a Java SE 7 (open specification). So, lets look at the evidence.
Blogs, blogs and more blogs - Every blog from a key Sun employee in recent times has referred to JDK 7, not Java 7. Read them carefully!!! Still think there is guaranteed to be a Java 7?
To emphasise the point - JDK 7 is the implementation, Java SE 7 is the specification. But everyone at Sun is talking about the JDK (Open JDK), not the specification (Java) and this isn't an accident.
Project Jigsaw - Modularisation of the core of Java - No JSR planned. Funny, how such a major piece of infrastructure has managed to slide by without becoming an open specification...
To be fair, Mark Reinhold's recent blog is more positive - "The JDK 7 Project is creating a prototype of what might-or might not-wind up in the Java SE 7 Platform Specification. When the SE 7 Platform JSR is submitted then the features under development in JDK 7 will be proposed for inclusion therein, except for those that are VM-level or implementation-specific." (He uses the 'when the JSR is submitted phrase', but note the 'implementation-specific' phrase which conveniently covers Jigsaw at a minimum).
However, unless anyone is being particularly naive, it should be clear that if there is to be a Java SE 7 specification then it would be fully defined by what is in Open JDK, not by the JSR process. Do you think that Sun would remove things already in OpenJDK were the JCP to so decide? Er, no.
And look at the timeline. The full JDK contents are defined by September, yet there is no JSR for Java SE 7 yet. The first two milestones have already happened for goodness sake!!!
If the JSR happens it will be a rubber stamp. So why bother?
Next release - JDK 7, not Java 7
Yes, this is what I mean by the title of this blog. The evidence I see, and have shown here, is that the next release will be JDK 7, not Java 7. ie. there won't be an open specification.
Of course, since Sun own the Java trademark, Sun puts in all the investment and Sun has all the mindshare, the vast majority of developers won't notice this. In fact, since its now Open Source as the OpenJDK they might even think all is well. Sun's strategy to quosh all competition is working well isn't it?
What won't be realised is how 10 years of open standards have been lost. What won't be realised is how everyone is now locked into a new Java trap - a single vendor of anything that can truly be certified as Java. Its just a trap that Richard Stallman isn't interested in arguing against.
Personally, I would have thought that given all our experiences with the benefits of open Standards on the internet we would be demanding it of Java too - especially since it was promised back in 1997. We need to fight to retain Java as an open standard.
Summary
All the evidence I see is that Java SE is no longer an open standard and the next release will be JDK 7, not Java 7. That is something that should matter to all of us who care about the Java eco-system.
After all, if Sun can get away with making Java SE not an open standard, then why not Java EE, or Servlets or JMS? Its time to stand up and be counted and demand our open standard back!
Feel free to tell me why you think my analysis is wrong... I suspect you won't hold back...
For the record, I'm a member of the Apache Software Foundation, speaking personally here to point out something someone else really should have noticed...
Update 1: Please tag any follow up blogs or tweets with 'nojava7' so the feedback can be seen!
Update 2: For info, I've never contributed to either Apache Harmony or the Open JDK, although I have used the OpenJDK in Kijaro and work on JSR-310. As such, I'm pretty dispassionate about the quality or usefulness of Harmony/OpenJDK. I care more about the lack of an open specification for Java 7, which is what this blog is primarily about.
Update 3: I haven't seen any evidence that the engineering team at Sun don't want a Java SE specification. The evidence I see is that this is driven from a higher business/management level.
Update 4: I've clarified the initial 'meanings of Java' section to place the emphasis on the Java Platform, as explained here. (The licensing terms are well worth a read - particularly number 7)
Update 5: I've updated Java 7 to Java SE 7 in a few places to aid clarity. Most people probably understand that Java EE and Java ME are different, but it helped in a couple of places to be extra sure.
Update 6: Fixed "offering Sun the testing kit" to "Sun offering the testing kit"
Your post is very informative and observations are striking. Java has been the golden goose for Sun Microsystems and they would do anything to protect it.
ReplyDeleteThe reason they made the VM/JDK free initially was to capture a market that was mostly dominated by C/C++ (Borland) and to counter Microsoft. Breaking into such a domination was not an easy task and the only way seemed was to offer something that no one else offered. Platform independence by making use of a VM was something the development community was eagerly waiting for. Using these two to their every possible advantage, they grew to dominating the market now.
But, being a capitalistic mind their inherent desire to dig gold always remained. They started the process via the 'paid service' concept. The demonstration by Java users (read products running on Java - from IDEs to servers to applications) to make money out of free Java, all the more aggravated their desire. They could see that the kind of growth Java can provide to them would be phenomenal. Yet, they were not returning back to the investors what they might have promised say 10 years back (They are currently at the point of being acquired).
Hence, they started playing with the Java. First, they made it a brand and bought copyright ownerships. Second, they started the whole certification thing - where in you pay damn just to be acknowledged that you know Java. Third, they publicized this certification concept to an extent that private industry (at least in developing countries) started seeing it as the prerequisite to offer jobs, bringing in millions of paying users. Fourth, they acquired major products that are either in Java or help in building a robust application with Java (read NetBeans, MySQL, etc) to enlarge the pool of paid service. Lastly as you said, they have tried putting a barrier at every place they can, so as to prevent their authority to cease. Be it the start of Java Community Process, the start of OpenJDK project (which was a way to crush the community anger, in case), withholding of the testing kits, or being too lazy in issuing JSRs, its just a way of monetizing and not letting Java slipping of their hands.
Thus, it becomes but obvious to see the birth of JDK 7 and not Java 7. Its simple, Sun Microsystems main objective is to earn money for its owners by in and all means. The only way to liberate the Java community of this monopolistic Goliath, would be to repeat the history itself. Break the barriers. One way I can think of is for the community to contribute and build the testing kits ourselves. May be a few years later, we would be totally away from Sun JDK concept and may just use the word Java freely.
Thanks for a wonderful post.
If Sun releases a JDK 7 without a specification, then Apache can do the same without having to worry about conformance testing. It sounds like a good solution, no?
ReplyDeleteI doubt they are doing this consciously. What is the easiest way for them to fix it so the JSR isn't just a rubber stamp? What should we be asking them to do?
ReplyDeleteOpen source the testing kit and the problem is solved?
BTW: Don't stop your work on the date time API, as a developer I care a lot about that JSR.
@Sandeep, Thanks for your interesting response. I think its fair to say that the evidence suggests it it is only relatively recently that Sun have tried to put a business model around Java. Too late of course, which is one reason why they will probably be bought.
ReplyDelete@Neal, Apache can't release Harmony without conformance testing as that would violate the legal agreement between Apache and Sun. Basically, the agreement states that anyone who implements a JSR only gets the rights to the IP once the implementation is tested. Since Apache can't test the Harmony implementation, it doesn't have the rights to the IP to be able to release.
I should also note that Apache Harmony is (currently) an implementation of Java SE 5, not Java SE 7.
@Geoffrey, The approach wrt to blocking Apache Harmony is deliberate, that is pretty much uncontended now. On Java 7, I believe that the engineers probably want a Java 7 specification, however these decisions are being taken at a business management level.
The way for Sun to enable a Java 7 JSR is to come to an agreemeent with Apache. This will unblock the JCP which is currently not going anywhere fast (look at the rate of new JSRs submitted).
And yes, an open source testing kit would be nice for lots of reasons, but its not what is at the heart of this debate, which is restrictive licensing of the testing kit.
"Apache can't release Harmony without conformance testing as that would violate the legal agreement between Apache and Sun. Basically, the agreement states that anyone who implements a JSR only gets the rights to the IP once the implementation is tested. Since Apache can't test the Harmony implementation, it doesn't have the rights to the IP to be able to release.
ReplyDeleteI should also note that Apache Harmony is (currently) an implementation of Java SE 5, not Java SE 7."
Exactly, that was a Java 5 issue. If they move to a 7 port, I think that they could just release a Harmony 7 and claim it's compatible with OpenJDK 7 (note, I'm saying JDK, not Java). It's different than saying "Java 7", but it is really a problem for people adopting it?
@Fabrizio, Harmony can't release anything without gaining the IP from Sun, and the only way to do that in the JCP is via a testing kit, in this case the Java SE testing kit.
ReplyDeleteWithout the IP, Sun could sue Apache, which Apache obviously can't allow to happen. Thus there is no way for Harmony to currently be released - version 5, 6 or 7, Java (spec) or JDK (impl). Hence, it looks like for Java 7, Sun will sidestep the whole question and just not have a Java specification.
Very interesting post, I think many have been more or less concerned about this recently. Open source without an open standard makes little sense, even the Mono guys gets better odds through ECMA.
ReplyDeleteAFAIK, Linus Torvalds owns the trademark of "Linux", yet he has not sued anyone so far for calling their Distribution a "Linux".
ReplyDeleteWhat's the worst thing that could happen? Some vendor who wants to release a "Java" would not be allowed to call it Java, but it'd probably be hard to deny him the right to claim that he provides "an OpenJDK-compatible". Ditto for libraries: "This library is JSR-xxx-compatible. Fineprint: Did not undergo JCP testing. Use at your own risk."
But Stephen, aren't umbrella JSRs usually, rubber stamp JSRs anyway, since the real design/spec work takes place inside and every JSR under that umbrella? Whereas an umbrella JSR is relegated to bookkeeping, and making sure all the various included JSRs are on track. So I'm not sure what are you trying to prove here.
ReplyDeleteI wouldn't read too much into the absence of the umbrella JSR. In the past these have usually appeared rather late in the development cycle and without much visible prior discussion. I would see the current OpenJDK process as an opening up of that development.
ReplyDeleteI wonder if this is influenced by, or will be influenced by, either for good or bad, by a purchase by IBM.
ReplyDelete@Bob, It would be great if Apache Harmony could just release as "OpenJDK compatible", unfortunately it isn't possible. The problem is with the IP (Intellectual Property), which Sun owns until you pass the testing kit.
ReplyDelete@Mike, Yes a typical Java SE JSR is an umbrella, and leaves the work to other JSRs. However, there is recent evidence of another JSR (JSR-200) that can only be tested as part of the umbrella - http://mail-archives.apache.org/mod_mbox/www-jcp-open/200903.mbox/%3C49C11309.7070702@gmail.com%3E . Furthermore, the IP for the whole Java SE platform release is only granted when you pass the testing kit.
No JSR => no testing kit => no way to get the IP => no release.
@Mark, When should we be worried about the absence of the umbrella Java SE 7 JSR? Now? At JavaOne? At release?
@MeBigFatGuy, AFAIK, this has nothing to do with any purchase of Sun by IBM. The history is much older than those rumours.
@Stephen: "The problem is with the IP"
ReplyDeleteWhat IP are you referring to? The trademark on "Java"? Copyright? What is being copyrighted, if there's no JSR? The behavior of the JDK? I don't think that's copyrightable.
Or does Apache have a contract with Sun that forbids them from even copying the JDK's behavior? If so, then could a non-Apache entity create Harmony?
Based on previous releases, the umbrella JSR probably is due about now, but it can't yet be described as significantly late.
ReplyDeleteIf it hasn't appeared by JavaOne then I would then call it 'late'.
Stephen,
ReplyDeleteThank you for this very informative post. What is this IP right that you are referring to?
I think you referring to the IP associated with the Java spec. If that is the case, then how could Sun construct the testing kit so as the results were not open source?
ReplyDeleteCan't Apache just release it without calling it "Java"?
ReplyDeleteAs its a common question, I've written up about the IP - http://www.jroller.com/scolebourne/entry/a_question_of_ip. Put simply, there is no way that Apache can release anything the claims to be a JSR implementations without passing the relevant testing kit.
ReplyDelete@Ceki, see the Apache FAQ for how the testing kit license was constructed so as the results were not open source? http://www.apache.org/jcp/sunopenletterfaq.html
Thanks for your detailed observation.
ReplyDeleteI love Java, but not the jailed one. I am just wondering if Apache Foundation will put more focus on other languages which run on JVM.
I think Apache might have brought this onto themselves with their political agenda.
ReplyDeleteBecause from the way I look at it, the problem isn't with JCP, it's with the JCK (the compatibility kit) which Apache not only wants to get for free but also under a license of their choosing.
I assume JCK is a lot older then the JCP and that it did take some man-hours to create and maintain. So Sun is investing money into that for quite some time. Apache wants it under their license, but also in perpetuity (I assume every future JCK should be available to Apache or just owned by Apache to make it simple).
What I don't understand is why doesn't Apache create their own JCK ? They surely must have something like this already ? I think the answer is a bit simple: passing the JCK gives you a lot more visibility then passing the "ApacheCK".
What people fail to realize is the UNIX itself is trademarked by The Open Group. Yet I don't see people railing on the streets that Linux isn't a true UNIX -- Linux is becoming the de-facto UNIX !
So why does Apache try so hard about this and tries to boycott the JCP for Java 7 in order to get the JCK under their terms ? Is having no JCP better in their political agenda since they can cry wolf ? Why don't they just ignore the JCK and make their own: in the long run it's going to become the de-facto one.
I understand that Sun might be trying to make some money from JCK usage (I bet IBM pays a lot for that) but why is Apache bothered so much by this ? Sun open sourced the JDK itself, now aren't we going to stop until they open-source the JCK ? What's next: personal emails within Sun must be 'open-source' ?
So, long story short: don't try to be in both places at once. You can't behave like a non-profit *and* big corporation. Let Sun keep some of their toys: you got what you wanted (OpenJDK). Now go and create competition in the compatibility kit market.
Yes, yes, we know, SUN is a BAD, BAD company. Not like IBM, which is a GOOD Company. So what SUN is giving ALL its software products available on open source licence, including high end solutions like Directory Server, so what SUN gave to the community OpenOffice - the only reason why anybody considers seriously using Linux.
ReplyDeleteThe only thing that SUN lacks is good PR. IBM, on the other hand, is a PR master of the World.
I am always surprised why open source advocates are bashing SUN, their only true corporate supporter. IBM is talking, talking about open source, but the fact is that their contribution is rather insignificant and always MUST be profitable for IBM.
SUN must earn money somehow, right now other companies were able to monetize their efforts, in the best interest of open source communit is to have SUN sound and kicking.
Very interesting perspective, thank you.
ReplyDeleteI have to say: it's within Sun's rights to do this. It's their baby after all.
Given that we now have an OpenJDK, isn't that really what we want? The specification is (also) as you put it in the context of JSRs, a "rubber stamp".
Perhaps this is as you implied, entirely about competition. Sun close the specs, and anyone who wants their own JDK would branch off Sun's HotSpot. I don't believe that there's a huge amount of competition within the context of JVMs/JDKs - and I'd prefer to use Sun's version (SE wise at least) any day.
Is it really that much of an issue?
@Piotr:
ReplyDeletePlease look at the names and associations of contributors to many of your favourite Open Source software. You'll often see the word "IBM" next to them. It is no accident.
So to claim that IBM's open source contribution is, as you say, "rather insignificant", is quite laughable, and shows that you have not researched the issue before speaking up.
Note: I am not an IBM employee. My only association with IBM is as a customer of theirs.
@Piotr, I agree that taken on balance, Sun has contributed a lot of good to the Open Source world (as has IBM). Given a choice, I would prefer Sun to remain an independent company. But that doesn't stop me from holding them to account when they don't uphold their prior public statements and legal agreements.
ReplyDelete@atc, Is it within Sun's rights to break prior public statements and legal agreements? Thats all that is being requested by Apache.
And if there effectively no way to actually implement the Java SE specification, should we allow Sun to claim that it is open?
And incidentally, Google has chosen to use Harmony class libraries in Android mobile phones, so at least someone is interested in an alternative to Sun.
"And incidentally, Google has chosen to use Harmony class libraries in Android mobile phones, so at least someone is interested in an alternative to Sun."
ReplyDeleteLOL!!!
You're really stretching and quite frankly laughably stretching ... I doubt Google's choice to use Harmony class libraries has anything to do with what you got yourself all in a bundle about ... a blanket Java SE 7 specification. I'd speculate Google's choice had more to do with licenses (GPL versus Apache). I'd speculate Google didn't like GPL for Android.
Don't know one wastes their time (including me) with trying to reason with a fanetic.
Managers at Sun have always been overly paranoid about competing Java implementations. For years they wouldn't open source Java because they were afraid of forking, so sure enough, they got lots of forks and clones -- Transvirtual Kaffe, GNU Classpath, Microsoft VM. Finally realizing that the GPL can actually help prevent forking, they release it under GPL version 2, and now they're worried about BSD- and Apache-style licensed competition.
ReplyDeleteThey should have simply trusted the GPL years ago, and they should simply trust it now. The GPL, more than any other license, has been quite good at preventing forks and unifying potential competing implementations:
Make Your Open Source Software GPL-Compatible.
Or Else.
http://www.dwheeler.com/essays/gpl-compatible.html
There's a place for licenses such as Apache or BSD, but if your objective is to prevent forking and to unify competing solutions around one implementation -- well, that's the GPL's best trick! There's no need to resort to any nasty underhanded tactics as mentioned in this post.
"to ensure that every specification must be tested before it is officially allowed to be released as an implementation of the specification"
ReplyDeleteCould you provide a link for this?
"when Apache came to obtain the testing kit for the specification a whole political game started."
Could you also provide a link here that indicates that something "started" here? I thought the TCK licensing was always that way.
"Sun was going out of its way to ensure that there was no competition to its own JDK."
Just a minor point...if Sun was "going out of its way", it was only to stop Harmony, not Classpath. So it would be more like "no non-GPL-compatible" JDK.
"...but the specification is now no longer open"
You made a big jump there, from the Sun/Apache test kit dispute to the spec being "now no longer open". You'll need a lot of words to connect those two dots.
"* There are two ways you can implement the Java specification - (1) pay Sun money, or (2) ensure your code is "mostly derived from the OpenJDK".
That's just wrong. Anyone is allowed to implement anything spec that they want. The only restriction is whether Sun is willing to let them use the "Java" trademark. Do you really think that I can't implement "String.toString()" just because Sun specifies that it returns the String as a String in its spec?
"Java SE is no longer an open standard"
Please don't say "Java SE" when you mean the spec - it's confusing. So you skipped your main argument: how is it that when one company chooses not to license the test kit (and so can't call their implementation "Java") means that the spec isn't "open"?
"Sun puts in all the investment and Sun has all the mindshare,"
How can you say this after you've just acknowledged that people outside Sun are involved and contributing (and always have)?
"If the JSR happens it will be a rubber stamp. So why bother?"
Great point, I'm wondering that, too. I'm mainly wondering whether it's really worked like this all along. I think it has - Sun's always developed first, and added/approved the spec either in parallel or afterwards. Nothing really wrong with that - most software's done that way - but it does mean that the JCP is a bit of a sham.
You say: "to ensure that every specification must be tested before it is officially allowed to be released as an implementation of the specification"
ReplyDeleteCould you provide a link for this? Are you speculating that a Sun/Apache contract says that Apache can't release their own software if it implements Sun's spec?
@John, This isn't a GPL vs Apache license battle. Its about open standards.
ReplyDeleteLook what Sun said in the official business terms for the Java SE 6 specification:
"
7. Nothing in the licensing terms will prevent open source projects from creating and distributing their own compatible open source implementations of Java SE 6, using standard open source licenses. (Yes, you can create your own open source implementation of Java SE 6 if you really want to. But we're also doing everything we can to make it easy for you to use the original RI sources! See http://jdk6.dev.java.net.)
"
http://jcp.org/en/jsr/detail?id=270
Sun was (2006) and still publicly claims to be fully willing to see an implementation of Java SE 6 under any standard open source license. This is exactly what you'd expect for an open standard.
Since Sun are clearly reneging on this public agreement, and associated JSPA based legal agreement. They should either fix the issue, or be honest and publicly admit that Java SE is no longer an open standard.
@Andy, "Are you speculating that a Sun/Apache contract says that Apache can't release their own software if it implements Sun's spec?"
Yes. Apache can't release without an IP grant from Sun. They don't get the IP grant until the tests are passed. But Sun aren't providing the tests. See http://www.jroller.com/scolebourne/entry/a_question_of_ip
@Stephen regarding @John, right. I was trying to say that *Sun* doesn't need any "nasty underhanded tactics" of reneging on its statements, and should just let the GPL do its work of preventing forks -- regardless of license -- if that's what it fears.
ReplyDeleteBut what's the reason behind Sun's behavior? If it's the fear of IBM stealing Java through an Apache fork, then it just might be about the license, as IBM (and others) can take the Apache code proprietary. Anyway, if the rumor of IBM's purchase of Sun is true, it may be resolved very soon.
@John, As I can't speak for Sun (just as I'm not speaking for Apache), I can't say what their motives are. However, here is one link that provides one (probable) explanation http://www.javaworld.com/community/node/2601 .
ReplyDeleteif Java is such a golden goose to Sun, can someone explain how they make money from it? IBM pays licensing fees. what else?
ReplyDeleteVery interesting points.
ReplyDeleteIMHO if everybody can just treat the OPENJDK as the SUN implementation of the up coming Java 7 JSR and use only the features included in the "java 7 specification", then everything will be go as usual.
But sun really have to let Apache to make its own Java to show people the heart that they will to open java. If sun's implementation is good enough, I think the other implementation will stay long. On the other hand, if the Apache's implementation is good enough, sun can save the money on making reference implementation.
Sometime, I think may we a well recognized leader as "top java features manager" is essential to the Java community. Nowadays, every java user is trying to push the favorites into the java specification. These users keep on yelling Java sucks if their favorites don't get into the specification. For example, the debate between 'have' and 'not have' a closure is a very typically example to this situation. We need someone who has same power on Java as Mr. Linus on Linux. Otherwise, the java's specification will become a endless debate like Perl 6's specification or a all-in specification in order to satisfy everyone.
@Emilian, Apache has a signed legal agreement with Sun, the JSPA, that states that Apache Harmony HAS to be tested using the TCK supplied by the spec lead - Sun. And Sun, legally, HAS to supply the testing kit. Nor are Sun aren't blocking this on grounds of $cost, they're blocking this because they want their JDK to be the only open source JDK.
ReplyDelete@Andy, When I said "a whole political game started" I was referring to Sun choosing to not provide Apache with the testing kit as it had done for 25 other JSRs.
Where you said "it would be more like 'no non-GPL-compatible' JDK", I disagree. The restrictions placed on the testing kit by Sun would be just as unacceptable to any other open source group irrespective of license. The additional terms are against the OSI open source definition.
You said "Do you really think that I can't implement 'String.toString()' just because Sun specifies that it returns the String as a String in its spec? ". My answer is yes, exactly that. You are not permitted to implement the Java SE spec unless you also implement the whole of the rest of the spec and pass all the tests. Read the JSPA.
Many other points in these comments are addressed in my follow up posts.
Are u angry about ur date time jsr will not be included into the jdk 7.???
ReplyDelete@Dave, Sun sell a combination of Java licenses (ME/SE/EE) and support. The Java business of Sun is in profit.
ReplyDelete@FU, LOL, JSR-310 isn't ready for inclusion right now, and I won't compromise on quality.
"Please look at the names and associations of contributors to many of your favourite Open Source software. You'll often see the word "IBM" next to them. It is no accident.
ReplyDeleteSo to claim that IBM's open source contribution is, as you say, "rather insignificant", is quite laughable, and shows that you have not researched the issue before speaking up. "
But if you critizize Piotr because he doesn't give the numbers, why aren't yourself giving some numbers? Ok, I'll do: here they are:
http://www.businessreviewonline.com/os/archives/2007/01/where_does_open.html
Sun provides more than 3x the open source provided by IBM. In fact, I must say I see just a few things provided by IBM in my usual work. If one consider that IBM is much larger than Sun (let's say 10x?), the normalized ratio gets to 30:1. Pretty strong number, right?
This is the reason why I have always absolutely refused to recommend Java for use in enterprise projects! For one thing, the platform was so vast and evolving so fast that it was difficult for developers to catch up with changes in each new version. For another, I always had a feeling that Sun would pull a fast one (like the restrictive licensing fiasco discussed above) someday. I strongly feel corporates (read Sun, Oracle et al.) should stay out of technology. Their greed and ruthlessness result in actions that cause a lot of pain for everyone involved.
ReplyDelete"For one thing, the platform was so vast and evolving so fast that it was difficult for developers to catch up with changes in each new version."
ReplyDeleteI read: it's so good I can't keep up. Great reasoning...
"I strongly feel corporates (read Sun, Oracle et al.) should stay out of technology." Hum. And who else would pay the developers? RMS? The mighty US Government?
Laughable...
I wouldn't be surprised if you are right.
ReplyDeleteHowever, you might argue that a GPLed implementation is a pretty damn good replacement for any formal specification (especially since until recently all reasonably complete implementations were closed source). One huge problem with standardization driven development is that it is slow and bureaucratic.
It's a shame of course that the test suite is not released under the same license though and this will definitely pose problems for Apache Harmony.
On the other hand, they are free to provide their own test suite, look at the GPL source code of the reference implementation, and not call it Java. Technically they could even create a test that calls method foo in Harmony and then in OpenJDK and compares the result. The license allows that. What better way to prove you are compatible then by showing it is doing the exact same things? I don't know if it is practical but it sure is a legal.
There are many successful opensource projects with only one implementation. I don't think that is necessarily a problem, provided the community is open enough. In cases where this isn't so, forking can be an effective tool (e.g. x.org). We've already seen external pressure from e.g. Red Hat leading to real change in the OpenJDK.
As for Harmony, this was always IBMs little pet project. It exists because of SUN and IBM not being to friendly. IBM can afford to license the toolkit if needed, after all they make billions of Java (unlike Sun). I don't buy the argument of Apache being poor volunteers who can't afford the licensing cost: most of their projects (including Harmony) have serious industrial backing (in many cases IBM). The main argument for Harmony (control aside) is the Apache 2.0 license which allows bundling with closed source components (unlike the GPL). In other words, Harmonies biggest fans are amongst those companies actually interested in specifically this feature. Such as for example Google who are depending on Harmony in Android.
So I think you are only telling half the story and if I were Stallman I might be leaning towards a full GPLed (GPL 3, no less) version of Java rather than a Apache 2.0 licensed one favoured by closed source proponents.
In any case, the same political bickering that is frustrating progress here has also crippled the JCP especially JEE5 has been somewhat of a disappointment and quite many are looking to Spring rather than to Sun for new goodies. Same with IBM and OSGI. It remains to be seen how much owning the Java trademark will mean in the long run (especially if IBM buys them). Fundamentally, if IBM and Sun don't get along, they won't agree on much inside the JCP either.
@Jiles, If Sun now believe that GPL'd Open JDK replaces the need for an open specification and an open standard, then they should say so. Publicly. They currently claim that Java SE is an open specification via the JCP, yet clearly they are actively preventing it from so being.
ReplyDeleteIts also worth pointing out that if Sun get away with this for Java SE, what stops them getting away with this for Java EE, or any other JSR. Do you want to see a world where Apache cannot implement any JSR? Where there is only one open source implementation of each JSR - the Sun sponsored one?
I'd also note that there is no evidence that Java SE 5 or 6 were unduly slowed down by having a JSR.
I'm not going to comment on your characterisation of Apache, as you are entitled to your opinion - suffice it to say I disagree. I would note that the FAQ accompanying the Apache open letter explains how companies bundling Harmony as their own JVM would almost certainly need to buy the testing kit themselves anyway, removing one of your arguments.
On GPLv3, it might be worth enquiring why Sun have not chosen to change to GPLv3?
Please read the other blogs in the series to see more of the picture about how the JCP works.
If Apache (/IBM) just could get a decent "Java 6"-like version of Harmony out the door, I wouldn't care a single cent what it was called or certified against, only whether it performed. I know that many others can't do that, because they have moronic pointy-haired bosses, but see - I don't give a flying fsck about that. I'll release my software with what runs it fastest and/or leanest. Hell, I'll even compromise on that to get the word out.
ReplyDeleteApache could call it Harmony v."This is the version that we'd try to certify against the TCK for Java 6 had we had the possibility of getting it".0.0. I guess you wouldn't violate any agreements by just calling it Harmony 6.0 either, which, by judging from current Harmony 5.0, is the plan already.
I'd be happy.
I think the problem here is more that there are NOT ONE single release from Harmony yet. And that what they currently are aiming at is 5.0, while what will be available RSN is 7.0.
The lack of a JSR seems more linked to the slowless of the JCP process than the chance of no open Java spec . A spec will come, they just need to know what going to be in it before they write it.
ReplyDeleteWe have:
Java the Language (like C#) defined by a given spec
Java the Platform (like .NET) defined by a given spec
Java the TM of Sun (like .NET)
Java the Reference Implementation provided by Sun
JTK the Test of said Java RI
Each of these has their own IP in some fashion or another.
Regarding IP:
We have IP that is part of a given JSR / Spec (an algorithem; I seem to recall Nokia had such as part one of the JavaME JSR which would not give IP rights without $$)
We have IP that is part of an implementation (Java Source was not opened until all IP encumerance were resolved or replaced like some of the font libraries; once this occurred it became OpenJDK; this does not immediately remove/replace encumerances from older versions only forward implementations).
We have IP that is part of a test suite (I don't have an example here other than to say there could be similar IP encumerance in this "implementation" as their were for the RI itself).
We have Trade mark concerns...
Java (TM) = TM Concern
Open JDK => No TM Concerns
In the end, I think Sun's motives are partly to protect them selves (to avoid a SCO vs Linux scenario) and to a degree to monitorize their Java investiment.
From another perspective, if someone uses an unofficial version of Java (Harmony) and something goes wrong, then there is a risk the unofficial version could hurt the reputation of Java (and Sun) as a whole and could result in legal actions against Sun as the proxy collected IP guardian.
There are probably benefits on both sides...but in the end since like it or not Sun is still closer to the RI and still has the TradeMark for Java (I guess you could say Sun is acting as the the defactor equivalent benevolant dictator -ala Linus for Linux).
If we have Harmony and OpenJDK...It seems to me rather than uniting behind a single project, we now have competing project with competing licenses, with different IP/Legal concerns. This ultimately splits the developers between two projects instead of one.