Issue #239: Java 7 versus JDK 7 versus OpenJDK
20 views
Skip to first unread message
robogeek
Apr 4, 2009, 10:59:10 PM4/4/09
to The Java Posse
I hope to be able to clarify some of what was said in the episode.
FYI I'm no longer at Sun. In any case as a blogger in the SE team I
didn't have any official coaching on what could or could not be said
on my blog. However the reason for not using the phrase "Java 7" is
very simple -- until there is a platform JSR assigned for Java 7 there
is no such thing as Java 7. For all values of 'n' in Java n there
must be a matching platform JSR defining the spec for that release of
Java. There were times I used the phrase "oh-what-the-heck-lets-call-
it-java-7".
OpenJDK is open source under GPL and IIRC you can build it today
without requiring binary plugs. Further there is effort from the
IcedTea underway to integrate IcedTea patches upstream into OpenJDK.
And there are other efforts such as the BSD porting project (including
Mac OS X) etc.
Whether an implementation can be called 'Java' is a separate matter
from the open source nature of the OpenJDK. The name 'Java' is a
trademark and there regularly trademark issues around open source
projects. For example why does CentOS have to remove all of Red Hat's
trademarks? It's because those trademarks are owned by Red Hat. For
example remember the issue with iceweasel versus firefox? IIRC That's
partly about the Mozilla Foundation rules about the use of the Firefox
trademark. Ubuntu has gotten careful about the Ubuntu trademark, for
example. Likewise Sun as the trademark owner gets to choose how the
trademark Java is used, who can use it, etc.
One of the steps to getting permission to use the trademarks is to
pass the TCK for the Java platform. (a.k.a. the JCK) The JCK is most
clearly not under an open source license, and the JCK is a separate
project from the OpenJDK project. The issue with the Harmony project
is about whether/how/if/when they can get a license to the TCK so they
can certify Harmony.
One way I think the confusion came in is -- 3 yrs ago when Jonathan S
& Rich G were on stage with their "it's not a matter of if" dance,
Jonathan asked "when will we open source Java". The news coverage
afterward was "Sun will open source Java".
I'm sorry, Sun didn't open source Java. Sun open sourced an
implementation, OpenJDK, which can be used to create Java
implementations.
What would it mean to "open source Java"? Java is a specification, a
community of people collaboratively defining specifications and
reference implementations etc. Would it mean open sourcing the JCP?
What would it mean to open source a standards body?
FYI I'm no longer at Sun. In any case as a blogger in the SE team I
didn't have any official coaching on what could or could not be said
on my blog. However the reason for not using the phrase "Java 7" is
very simple -- until there is a platform JSR assigned for Java 7 there
is no such thing as Java 7. For all values of 'n' in Java n there
must be a matching platform JSR defining the spec for that release of
Java. There were times I used the phrase "oh-what-the-heck-lets-call-
it-java-7".
OpenJDK is open source under GPL and IIRC you can build it today
without requiring binary plugs. Further there is effort from the
IcedTea underway to integrate IcedTea patches upstream into OpenJDK.
And there are other efforts such as the BSD porting project (including
Mac OS X) etc.
Whether an implementation can be called 'Java' is a separate matter
from the open source nature of the OpenJDK. The name 'Java' is a
trademark and there regularly trademark issues around open source
projects. For example why does CentOS have to remove all of Red Hat's
trademarks? It's because those trademarks are owned by Red Hat. For
example remember the issue with iceweasel versus firefox? IIRC That's
partly about the Mozilla Foundation rules about the use of the Firefox
trademark. Ubuntu has gotten careful about the Ubuntu trademark, for
example. Likewise Sun as the trademark owner gets to choose how the
trademark Java is used, who can use it, etc.
One of the steps to getting permission to use the trademarks is to
pass the TCK for the Java platform. (a.k.a. the JCK) The JCK is most
clearly not under an open source license, and the JCK is a separate
project from the OpenJDK project. The issue with the Harmony project
is about whether/how/if/when they can get a license to the TCK so they
can certify Harmony.
One way I think the confusion came in is -- 3 yrs ago when Jonathan S
& Rich G were on stage with their "it's not a matter of if" dance,
Jonathan asked "when will we open source Java". The news coverage
afterward was "Sun will open source Java".
I'm sorry, Sun didn't open source Java. Sun open sourced an
implementation, OpenJDK, which can be used to create Java
implementations.
What would it mean to "open source Java"? Java is a specification, a
community of people collaboratively defining specifications and
reference implementations etc. Would it mean open sourcing the JCP?
What would it mean to open source a standards body?
JodaStephen
Apr 5, 2009, 9:02:21 AM4/5/09
to The Java Posse
For info of anyone reading - robogeek is http://weblogs.java.net/blog/robogeek/
- "David Herron has worked for 7 years in the J2SE Quality Engineering
team. He has developed test suites and GUI test automation tools".
- "David Herron has worked for 7 years in the J2SE Quality Engineering
team. He has developed test suites and GUI test automation tools".
JodaStephen
Apr 5, 2009, 9:08:50 AM4/5/09
to The Java Posse
To the Posse (replying to the episode),
This is about the difference between an open specification and and
open source implementation. The two things are different.
Sun has successfully created OpenJDK, an open source project under the
GPL license. This is being run in a pretty open manner and Sun should
be praised for that.
However, an open specification allows anyone else (other than Sun) to
create their own implementation, one that is completely independent of
Sun's code (and deals with IP transfer issues and compatibility
testing amongst other issues). The name of the specification is the
"Java SE platform" (Thus, the shorthand is "Java 7 is the spec, and
JDK 7 is the implementation").
At present, there is no Java SE 7 platform specification. My blogs
have been seeking to show that until the problems Apache Harmony have
faced are resolved, then there may well not be a Java SE 7
specification. Hence, no "Java 7, only JDK 7".
The question is whether the community is willing to allow Java to
become just an implementation, rather than a specification. Amusingly,
as an implementation without a specification, the Burton Group would
classify OpenJDK as a "rebel framework" -
http://apsblog.burtongroup.com/2009/03/open-source-is-not-as-open-as-standard-specifications.html
Finally, to Tor. These decisions were being taken at the highest level
in Sun. Its no great surprise that many Sun employees aren't aware of
just how strongly Sun has been playing their hand here.
I'm happy to be interviewed on this topic, as I'm sure would Geir (the
official Apache representative). Although I'm a member of Apache, I've
tried my absolute best to demonstrate the reality of the situation
through links, each of which is worth reading for this very important
story. In other words, I've tried to act closer to an investigative
journalist, rather than a member of Apache for the purposes of the
debate. I'll leave it to history to judge if I acted fairly or not.
Stephen Colebourne
Member, Apache Software Foundation (speaking personally - ie.
unapproved)
Sun Java Champion
This is about the difference between an open specification and and
open source implementation. The two things are different.
Sun has successfully created OpenJDK, an open source project under the
GPL license. This is being run in a pretty open manner and Sun should
be praised for that.
However, an open specification allows anyone else (other than Sun) to
create their own implementation, one that is completely independent of
Sun's code (and deals with IP transfer issues and compatibility
testing amongst other issues). The name of the specification is the
"Java SE platform" (Thus, the shorthand is "Java 7 is the spec, and
JDK 7 is the implementation").
At present, there is no Java SE 7 platform specification. My blogs
have been seeking to show that until the problems Apache Harmony have
faced are resolved, then there may well not be a Java SE 7
specification. Hence, no "Java 7, only JDK 7".
The question is whether the community is willing to allow Java to
become just an implementation, rather than a specification. Amusingly,
as an implementation without a specification, the Burton Group would
classify OpenJDK as a "rebel framework" -
http://apsblog.burtongroup.com/2009/03/open-source-is-not-as-open-as-standard-specifications.html
Finally, to Tor. These decisions were being taken at the highest level
in Sun. Its no great surprise that many Sun employees aren't aware of
just how strongly Sun has been playing their hand here.
I'm happy to be interviewed on this topic, as I'm sure would Geir (the
official Apache representative). Although I'm a member of Apache, I've
tried my absolute best to demonstrate the reality of the situation
through links, each of which is worth reading for this very important
story. In other words, I've tried to act closer to an investigative
journalist, rather than a member of Apache for the purposes of the
debate. I'll leave it to history to judge if I acted fairly or not.
Stephen Colebourne
Member, Apache Software Foundation (speaking personally - ie.
unapproved)
Sun Java Champion
Martin OConnor
Apr 6, 2009, 4:25:49 AM4/6/09
to The Java Posse
My one outstanding question is the following
Has any OpenJDK build yet passed the TCK(JCK) ?
Has any OpenJDK build yet passed the TCK(JCK) ?
BoD
Apr 6, 2009, 5:13:42 AM4/6/09
to java...@googlegroups.com
+1 to get Stephen and Geir interviewed on the show!
I find this topic very interesting.
I find this topic very interesting.
BoD
JodaStephen
Apr 6, 2009, 6:00:36 AM4/6/09
to The Java Posse
On Apr 6, 9:25 am, Martin OConnor <marti...@gmail.com> wrote:
> My one outstanding question is the following
> Has any OpenJDK build yet passed the TCK(JCK) ?
Yes. Open JDK 6 has passed the Java SE 6 specification:
> My one outstanding question is the following
> Has any OpenJDK build yet passed the TCK(JCK) ?
"JDK 6 Project
The primary goal of this project is to produce an open-source
implementation of the Java SE 6 Platform."
http://openjdk.java.net/projects/jdk6/
"The bottom line is that OpenJDK 6 works rather well, several Linux
distros are using it as their JDK, it can be built to pass the JCK6b
test suite, meaning OpenJDK 6 can be used to build a compliant JDK,
and unfortunately it is this evolutionary sidetrack which we hope will
be relatively short-lived. It serves a purpose, namely of having an
fully open OpenJDK compliant with Java6"
http://weblogs.java.net/blog/robogeek/archive/2009/01/it_will_be_open.html
"The JCK tests probe the conformance of a Java platform implementation
to a specification. For example, JCK 6b is the current test suite to
determine conformance to the Java SE 6 spec. Official claims of
conformance require not only passing the complete set of relevant
tests, but also meeting the other requirements spelled out in the JCK
user's guide."
http://blogs.sun.com/darcy/entry/openjdk_6_b13_and_jck
Open JDK 7 does NOT pass the Java SE 6 specification:
"Q: Does the OpenJDK code base pass the JCK?
A: Not at present. The OpenJDK 7 code base contains changes that are
early access implementations of features that may become a part of JDK
7"
http://www.sun.com/software/opensource/java/faq.jsp#k24
Open JDK 7 obviously CANNOT pass the Java SE 7 specification because
no such specification currently exists.
Stephen
Dave Patterson
Apr 6, 2009, 6:04:26 AM4/6/09
to The Java Posse
+1
Even better if you could get someone like Dalibor in the room at the
same time for an even-handed debate.
Dave Patterson
Even better if you could get someone like Dalibor in the room at the
same time for an even-handed debate.
Dave Patterson
Dick Wall
Apr 6, 2009, 9:51:08 PM4/6/09
to The Java Posse
Sounds like this would be something good to set up for JavaOne, since
that is just around the corner and I think a debate like this would go
much better face to face.
I agree that it needs to be even handed, with both sides represented.
In the meantime we can start to work on a rough agenda of the most
important questions to ask, for example, what exactly does the TCK
currently let you do, and in what ways does it need to be fixed, just
for starters.
Carl and I have both been working out, so we can break up any fights
that might break out :-)
Cheers
Dick
On Apr 6, 3:04 am, Dave Patterson
that is just around the corner and I think a debate like this would go
much better face to face.
I agree that it needs to be even handed, with both sides represented.
In the meantime we can start to work on a rough agenda of the most
important questions to ask, for example, what exactly does the TCK
currently let you do, and in what ways does it need to be fixed, just
for starters.
Carl and I have both been working out, so we can break up any fights
that might break out :-)
Cheers
Dick
On Apr 6, 3:04 am, Dave Patterson
Martin OConnor
Apr 7, 2009, 5:15:58 AM4/7/09
to The Java Posse
On Apr 6, 11:00 am, JodaStephen <jodastep...@googlemail.com> wrote:
> On Apr 6, 9:25 am, Martin OConnor <marti...@gmail.com> wrote:
>
> > My one outstanding question is the following
> > Has any OpenJDK build yet passed the TCK(JCK) ?
>
> Yes. Open JDK 6 has passed the Java SE 6 specification:
>
project without a FOU restriction, because the GPL explicitly forbids
such a restriction.
> "JDK 6 Project
> The primary goal of this project is to produce an open-source
> implementation of the Java SE 6 Platform."http://openjdk.java.net/projects/jdk6/
>
> "The bottom line is that OpenJDK 6 works rather well, several Linux
> distros are using it as their JDK, it can be built to pass the JCK6b
> test suite, meaning OpenJDK 6 can be used to build a compliant JDK,
> and unfortunately it is this evolutionary sidetrack which we hope will
> be relatively short-lived. It serves a purpose, namely of having an
> fully open OpenJDK compliant with Java6"http://weblogs.java.net/blog/robogeek/archive/2009/01/it_will_be_open...
> The primary goal of this project is to produce an open-source
> implementation of the Java SE 6 Platform."http://openjdk.java.net/projects/jdk6/
>
> "The bottom line is that OpenJDK 6 works rather well, several Linux
> distros are using it as their JDK, it can be built to pass the JCK6b
> test suite, meaning OpenJDK 6 can be used to build a compliant JDK,
> and unfortunately it is this evolutionary sidetrack which we hope will
> be relatively short-lived. It serves a purpose, namely of having an
JodaStephen
Apr 7, 2009, 7:19:33 AM4/7/09
to The Java Posse
On Apr 7, 10:15 am, Martin OConnor <marti...@gmail.com> wrote:
> Therefore, it follows that Sun has licensed the JCK to the OpenJDK
> project without a FOU restriction, because the GPL explicitly forbids
> such a restriction.
Yes. Sun has a dedicated license programme for code that is solely for
> Therefore, it follows that Sun has licensed the JCK to the OpenJDK
> project without a FOU restriction, because the GPL explicitly forbids
> such a restriction.
GPL code "substantially derived from OpenJDK" - http://www.infoq.com/news/2007/08/openjdk-jck
- http://robilad.livejournal.com/17156.html
"WHEREAS Licensee participates in Sun's OpenJDK Community and either:
(i) has developed
and seeks to distribute under the GPL License a compatibility-tested
implementation of the Java
SE 6 Specification that is derived from code made available to the
OpenJDK Community; or (ii)
wishes to verify that changes made by Licensee to the OpenJDK code
base would not break
compatibility;"
http://openjdk.java.net/legal/openjdk-tck-license.pdf
So, there are three choices to get the testing kit:
- pay Sun money
- derive from Open JDK and release as GPL
- apply for the standard JSPA sponsorship and release under any open
source license
The third option is the one Apache wants to use, but can't as the
testing kit there has been restricted by FOU.
JodaStephen
Apr 7, 2009, 7:21:49 AM4/7/09
to The Java Posse
On Apr 7, 2:51 am, Dick Wall <dickw...@gmail.com> wrote:
> Sounds like this would be something good to set up for JavaOne, since
> that is just around the corner and I think a debate like this would go
> much better face to face.
I won't be at JavaOne, but I suspect Geir will be.
> Sounds like this would be something good to set up for JavaOne, since
> that is just around the corner and I think a debate like this would go
> much better face to face.
Stephen
Jess Holle
Apr 7, 2009, 7:59:13 AM4/7/09
to java...@googlegroups.com
This makes perfect sense to me.
Harmony's only compelling differentiation and thus reason for existence at this point is that it is licensed under the Apache license. The primary benefit of this license is that you can produce commercial, closed source variations/extensions with almost no restrictions -- and when that's what you need, it is truly wonderful. When that's not what you need, it is still a fine thing in many cases.
In Sun's case with the JDK, however, the Apache license is not a fine thing.
They put untold amounts of engineering work into the JDK and TCK -- and continue to do so. How can anyone expect them to make the TCK freely available to open source communities who clearly directly support proprietary, closed-source, and commercial derivations which will
I'm normally a huge fan of the Apache license and Apache projects. Originally I was of the mind that Sun should release Java under this license. In retrospect, though, I think that GPL was the only sensible option for them financially -- and presents a nice barrier to private/proprietary forks as well.
Perhaps Sun led the Apache Harmony team to believe the TCK restrictions would be different or change -- and then changed their mind. If so, that's unfortunate, but I can understand how Sun would change their mind if they made this mistake.
--
Jess Holle
P.S. I've encountered incompatibilities in J9 code adopted from Harmony that were less than pleasant. The only reason I can see for IBM going this route (i.e. using Harmony classes in J9 at this point) is to eliminate the need for them to license the JDK or TCK from Sun.
JodaStephen wrote:
Harmony's only compelling differentiation and thus reason for existence at this point is that it is licensed under the Apache license. The primary benefit of this license is that you can produce commercial, closed source variations/extensions with almost no restrictions -- and when that's what you need, it is truly wonderful. When that's not what you need, it is still a fine thing in many cases.
In Sun's case with the JDK, however, the Apache license is not a fine thing.
They put untold amounts of engineering work into the JDK and TCK -- and continue to do so. How can anyone expect them to make the TCK freely available to open source communities who clearly directly support proprietary, closed-source, and commercial derivations which will
- Compete with Sun (e.g. J9) and
- Do so without paying JDK, TCK, etc, licensing fees that the parties involved (e.g. IBM) would otherwise have to pay to produce such derivative works?
I'm normally a huge fan of the Apache license and Apache projects. Originally I was of the mind that Sun should release Java under this license. In retrospect, though, I think that GPL was the only sensible option for them financially -- and presents a nice barrier to private/proprietary forks as well.
Perhaps Sun led the Apache Harmony team to believe the TCK restrictions would be different or change -- and then changed their mind. If so, that's unfortunate, but I can understand how Sun would change their mind if they made this mistake.
--
Jess Holle
P.S. I've encountered incompatibilities in J9 code adopted from Harmony that were less than pleasant. The only reason I can see for IBM going this route (i.e. using Harmony classes in J9 at this point) is to eliminate the need for them to license the JDK or TCK from Sun.
JodaStephen wrote:
On Apr 7, 10:15 am, Martin OConnor <marti...@gmail.com> wrote:Therefore, it follows that Sun has licensed the JCK to the OpenJDK project without a FOU restriction, because the GPL explicitly forbids such a restriction.
Yes. Sun has a dedicated license programme for code that is solely for GPL code "substantially derived from OpenJDK" - http://www.infoq.com/news/2007/08/openjdk-jck - http://robilad.livejournal.com/17156.html
"WHEREAS Licensee participates in Sun's OpenJDK Community and either: (i) has developed and seeks to distribute under the GPL License a compatibility-tested implementation of the Java SE 6 Specification that is derived from code made available to the OpenJDK Community; or (ii) wishes to verify that changes made by Licensee to the OpenJDK code base would not break compatibility;<a class="moz-txt-link-rfc2396E" href="http://openjdk.java.net/legal/openjdk-tck-license.pdfSo,therearethreechoicestogetthetestingkit:-paySunmoney-derivefromOpenJDKandreleaseasGPL-applyforthestandardJSPAsponsorshipandreleaseunderanyopensourcelicenseThethirdoptionistheoneApachewantstouse,butcan'tasthetestingkittherehasbeenrestrictedbyFOU. </pre> </blockquote> <br> </body> </html>
markmac
Apr 7, 2009, 8:24:31 AM4/7/09
to The Java Posse
This is an incredibly interesting discussion, and Im trying my best to
follow it along, I just have a few questions though...
According to what you just said,
"The name of the specification is the "Java SE platform" (Thus, the
shorthand is "Java 7 is the spec, and
JDK 7 is the implementation"). "
"At present, there is no Java SE 7 platform specification. My blogs
have been seeking to show that until the problems Apache Harmony have
faced are resolved, then there may well not be a Java SE 7
specification. Hence, no "Java 7, only JDK 7".
here... If JDK 7 is an implementation of a specification, what
specification is it implementing? Is it just the "Java SE platform"
specification? If so, why is it called "JDK 7"??
Also, how does project COIN fit into this?
The project website states:
Project Coin
"The goal of Project Coin is to determine what set of small language
changes should be added to JDK 7"
(I guess the explanation of JDK 7 will really answer this question for
me)
Thanks for any help you can give me in clarifying this...
Cheers,
Mark
On Apr 5, 11:08 pm, JodaStephen <jodastep...@googlemail.com> wrote:
> To the Posse (replying to the episode),
> This is about the difference between an open specification and and
> open source implementation. The two things are different.
>
> Sun has successfully created OpenJDK, an open source project under the
> GPL license. This is being run in a pretty open manner and Sun should
> be praised for that.
>
> However, an open specification allows anyone else (other than Sun) to
> create their own implementation, one that is completely independent of
> Sun's code (and deals with IP transfer issues and compatibility
> testing amongst other issues). The name of the specification is the
> "Java SE platform" (Thus, the shorthand is "Java 7 is the spec, and
> JDK 7 is the implementation").
>
> At present, there is no Java SE 7 platform specification. My blogs
> have been seeking to show that until the problems Apache Harmony have
> faced are resolved, then there may well not be a Java SE 7
> specification. Hence, no "Java 7, only JDK 7".
>
> The question is whether the community is willing to allow Java to
> become just an implementation, rather than a specification. Amusingly,
> as an implementation without a specification, the Burton Group would
JodaStephen
Apr 7, 2009, 11:26:05 AM4/7/09
to The Java Posse
On Apr 7, 1:24 pm, markmac <mark.macum...@gmail.com> wrote:
> You saying that "no Java 7, only JDK 7" is what I'm not clear on
> here... If JDK 7 is an implementation of a specification, what
> specification is it implementing? Is it just the "Java SE platform"
> specification? If so, why is it called "JDK 7"??
> Also, how does project COIN fit into this?
Open JDK 6 (the GPL version) and Sun JDK 6 (the non-GPL version) are
> You saying that "no Java 7, only JDK 7" is what I'm not clear on
> here... If JDK 7 is an implementation of a specification, what
> specification is it implementing? Is it just the "Java SE platform"
> specification? If so, why is it called "JDK 7"??
> Also, how does project COIN fit into this?
implementations of the Java SE 6 platform specification (JSR-270).
Open JDK 7 (the GPL version) is at this point what is best described
as 'just another open source project'. Sure, its an important one, but
it is not an implementation of any specification.
Sun would probably like Open JDK 7 to become the reference
implementation of the Java SE 7 platform specification. However there
is currently no such specification, hence it has a status no more and
no less than any other open source project.
Sun are continuing to use the 'JDK' terminology for JDK 7 even though
it is not an implementation of a specification. This is probably a
practical matter, as it is the best name for the codebase (given that
it can't be called Java SE 7, as that name specifically means the
specification, as David indicated at the start of the thread).
Project Coin is simply an effort to add language changes to Open JDK
7. Again, Sun would probably like there to be a JSR for Coin, and for
that to feed into the Java SE 7 platform specification, however it is
unclear if that will actually happen.
JodaStephen
Apr 7, 2009, 11:50:00 AM4/7/09
to The Java Posse
On Apr 7, 12:59 pm, Jess Holle <je...@ptc.com> wrote:
> In Sun's case with the JDK, however, the Apache license is not a fine thing.
> They put untold amounts of engineering work into the JDK and TCK -- and
> continue to do so. How can anyone expect them to make the TCK freely
> available to open source communities who clearly directly support
> proprietary, closed-source, and commercial derivations...
> In Sun's case with the JDK, however, the Apache license is not a fine thing.
> They put untold amounts of engineering work into the JDK and TCK -- and
> continue to do so. How can anyone expect them to make the TCK freely
> available to open source communities who clearly directly support
The answer is incredibly simple.
*Because they made public commitments and signed a legal agreements
(the JSPA v2) in 2002 that allows anyone (not just Apache) to produce
an independent, standalone implementation of the Java SE platform
under any open source license.*
Sun understood the costs involved at the time, hence the scholarship
program in the JCP.
Sun also reiterated this promise in the Java SE 6 platform
specification business terms as approved by JCP vote:
"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 (October 2006)
So, the question is whether you, and the Java community in general,
are willing to allow Sun to renege on their public commitments and
break signed legal agreements without consequences.
Simply because Sun is in a parlous financial state isn't an excuse
here. Much as it is appealing to conflate the two issues, it is
important not to do so.
On the broader question, I believe that having competition in the Java
SE platform space is good for everyone. Or are we arguing that JBoss
and Geronimo have no place as Java EE implementations given that
Glassfish exists? I also note that Sun has taken code from Harmony
that was performing faster than their own JDK code and reused it -
http://blogs.sun.com/dagastine/entry/apache_harmony_thanks_for_the
proving that competition benefits all.
Finally, on the proprietary point, here is a quote with the official
Apache position on why they believe that someone like IBM cannot use
Harmony to sidestep paying Sun:
"Q : Does Apache think that Harmony could be used by commercial
entities to avoid paying JCK licensing fees to Sun?
A : No. The only way that could happen is if a commercial entity
stopped shipping their own software and started shipping the
tested binaries that were created by the Harmony project.
Even then, they would still need to license the Java branding
rights from Sun, as Apache does not pass those rights
downstream to users or redistributors of our software. Note
that if an entity made a derivative work, or used only part of
Harmony's source code in building their implementation, they
would still be obligated to obtain their own JCK license for,
and test the software themselves. Apache does not make its
TCKs available for use outside of our projects.
"
http://www.apache.org/jcp/sunopenletterfaq.html
As described above, it is in reality pretty impossible for IBM to use
Harmony to 'steal' Java, as IBM could only use the binaries packaged
and tested by Apache completely unaltered.
Jess Holle
Apr 7, 2009, 12:12:02 PM4/7/09
to java...@googlegroups.com
JodaStephen wrote:
> So, the question is whether you, and the Java community in general,
> are willing to allow Sun to renege on their public commitments and
> break signed legal agreements without consequences.
>
> Simply because Sun is in a parlous financial state isn't an excuse
> here. Much as it is appealing to conflate the two issues, it is
> important not to do so.
>
Ah... So Sun can seemingly rightly be called a liar and run through the > So, the question is whether you, and the Java community in general,
> are willing to allow Sun to renege on their public commitments and
> break signed legal agreements without consequences.
>
> Simply because Sun is in a parlous financial state isn't an excuse
> here. Much as it is appealing to conflate the two issues, it is
> important not to do so.
>
mud for reneging on their commitments to the ASF.
While that is a separate matter from their financial state, it is also a
separate matter from the openness of Java in my opinion. Sun can still
foster a rich open Java implementation community based on GPL despite a
black eye from reneging on commitments to one sub-community, ASF.
> On the broader question, I believe that having competition in the Java
> SE platform space is good for everyone. Or are we arguing that JBoss
> and Geronimo have no place as Java EE implementations given that
> Glassfish exists? I also note that Sun has taken code from Harmony
> that was performing faster than their own JDK code and reused it -
> http://blogs.sun.com/dagastine/entry/apache_harmony_thanks_for_the
> proving that competition benefits all.
>
I'd generally agree, though I'd generally see more benefit as a consumer
of the various JDKs if everything started from the OpenJDK and then
deviated from it as necessary to better meet particular requirements.
[An exception would be something truly radically different like the
Maxine project, which seems like the way a JDK really ought to be
implemented rather than the C/C++ mess that exists today. Even there,
however, I'd think the Java code behind the implementation should
deviate only as necessary/compelling.] By starting from scratch Harmony
is pervasively inconsistent with Sun's implementation, which has been a
painful thing in our experience even in IBM's J9 which does pass the
TCK. IBM's Java 6 J9 is much less compatible with Sun's implementation
than in the past and many of the incompatibilities have traced directly
to them replacing Sun implementation classes with Harmony ones.
> Finally, on the proprietary point, here is a quote with the official
> Apache position on why they believe that someone like IBM cannot use
> Harmony to sidestep paying Sun:
>
> "Q : Does Apache think that Harmony could be used by commercial
> entities to avoid paying JCK licensing fees to Sun?
> A : No. The only way that could happen is if a commercial entity
> stopped shipping their own software and started shipping the
> tested binaries that were created by the Harmony project.
> Even then, they would still need to license the Java branding
> rights from Sun, as Apache does not pass those rights
> downstream to users or redistributors of our software. Note
> that if an entity made a derivative work, or used only part of
> Harmony's source code in building their implementation, they
> would still be obligated to obtain their own JCK license for,
> and test the software themselves. Apache does not make its
> TCKs available for use outside of our projects.
> "
> http://www.apache.org/jcp/sunopenletterfaq.html
>
> As described above, it is in reality pretty impossible for IBM to use
> Harmony to 'steal' Java, as IBM could only use the binaries packaged
> and tested by Apache completely unaltered.
>
Ah. That clarifies things.
I wonder if the real issue here is that Sun's TCK is really too weak to
ensure adequate compatibility of a completely disparate implementations
and that Sun has only recently discovered that allowing implementations
that didn't start with their code and then deviate (and thus have many
of the same undocumented behaviors) to certify with it would allow an
unacceptable level of incompatibility. If so, my experience with J9
would tend to suggest that the TCK is indeed too weak. Here Sun's
finances do again become relevant -- they can't afford massive
investment in the TCK or Java specification to add sufficient teeth to
ensure compatibility if sufficient teeth are not already present.
--
Jess Holle
Martin OConnor
Apr 7, 2009, 1:04:00 PM4/7/09
to The Java Posse
Could it be possible that Sun's line of thinking might be release an
unencumbered TCK to Apache for
Java SE 7, when it finally becomes specified. This TCK would likely be
built from the ground up to address the weaknesses in the TCK for Java
SE 6. I would imagine from a cost perspective that Sun could say to
ASF "Ok skip Java SE 6 and work on implementing Java SE 7 instead"
A likely scenario, no?
unencumbered TCK to Apache for
Java SE 7, when it finally becomes specified. This TCK would likely be
built from the ground up to address the weaknesses in the TCK for Java
SE 6. I would imagine from a cost perspective that Sun could say to
ASF "Ok skip Java SE 6 and work on implementing Java SE 7 instead"
A likely scenario, no?
JodaStephen
Apr 7, 2009, 3:02:42 PM4/7/09
to The Java Posse
On Apr 7, 5:12 pm, Jess Holle <je...@ptc.com> wrote:
> I wonder if the real issue here is that Sun's TCK is really too weak to
> ensure adequate compatibility of a completely disparate implementations
> and that Sun has only recently discovered that allowing implementations
> that didn't start with their code and then deviate (and thus have many
> of the same undocumented behaviors) to certify with it would allow an
> unacceptable level of incompatibility.
I can't really speculate on Sun's motivations beyond what is public
> I wonder if the real issue here is that Sun's TCK is really too weak to
> ensure adequate compatibility of a completely disparate implementations
> and that Sun has only recently discovered that allowing implementations
> that didn't start with their code and then deviate (and thus have many
> of the same undocumented behaviors) to certify with it would allow an
> unacceptable level of incompatibility.
record. I don't think it is in dispute that the TCK doesn't cover
every last detail of the Java SE platform - you can read the user
guide freely - http://openjdk.java.net/groups/conformance/docs/JCK6bUsersGuide/index.html
Personally, I am sceptical that is the only reason for preventing
Harmony from obtaining the testing kit - others have speculated/
indicated financial motives:
"Some off-the-record sources chatted with me about it and I now feel
like I have a bit more of a sense of what it's all about. Here's the
punchline: The dispute between Sun and the ASF over a Java SE
implementation, which resulted in a no vote on Java EE? At its heart,
it's about making an end run around Java ME."
http://www.javaworld.com/community/node/2601
Stephen
JodaStephen
Apr 7, 2009, 3:11:09 PM4/7/09
to The Java Posse
On Apr 7, 6:04 pm, Martin OConnor <marti...@gmail.com> wrote:
> Could it be possible that Sun's line of thinking might be release an
> unencumbered TCK to Apache for
> Java SE 7, when it finally becomes specified. This TCK would likely be
> built from the ground up to address the weaknesses in the TCK for Java
> SE 6. I would imagine from a cost perspective that Sun could say to
> ASF "Ok skip Java SE 6 and work on implementing Java SE 7 instead"
> A likely scenario, no?
First point - Sun is perfectly able to provide the TCK to Harmony for
> Could it be possible that Sun's line of thinking might be release an
> unencumbered TCK to Apache for
> Java SE 7, when it finally becomes specified. This TCK would likely be
> built from the ground up to address the weaknesses in the TCK for Java
> SE 6. I would imagine from a cost perspective that Sun could say to
> ASF "Ok skip Java SE 6 and work on implementing Java SE 7 instead"
> A likely scenario, no?
Java SE 5 and 6 today. They are choosing not to do so (or rather, only
with the FOU).
Your second point suggests that Sun might offer this for Java SE 7,
but not SE 5 or SE 6. However, you should consider how that looks to
Apache. They had a commitment made in 2002 (after two years of
effort), repeated again and again up to 2006. Yet when the time came
to make good on the commitment, Sun didn't keep the bargain. Why would
Apache choose to accept another commitment from Sun now? Why would Sun
not break any new promise in two years time when Harmony requests the
Java SE 7 TCK?
Jess Holle
Apr 7, 2009, 3:25:33 PM4/7/09
to java...@googlegroups.com
JodaStephen wrote:
Personally, I am sceptical that is the only reason for preventing Harmony from obtaining the testing kit - others have speculated/ indicated financial motives: "Some off-the-record sources chatted with me about it and I now feel like I have a bit more of a sense of what it's all about. Here's the punchline: The dispute between Sun and the ASF over a Java SE implementation, which resulted in a no vote on Java EE? At its heart, it's about making an end run around Java ME." http://www.javaworld.com/community/node/2601
If this is the reason for Sun's reticence then I have much less
sympathy.
Why?
Because I consider Java ME as it stands today as a rather harmful thing to the Java community.
Why?
Because it is stuck in pre-Java-5 days and has no clearly stated roadmap to start supporting more recent versions of Java. This splinters the Java community, libraries, techniques, training, etc, into a pre-Java-5 ghetto for those using Java ME (as well as those using old versions of WebSphere) and the "modern" camp. This is thus a drag on the overall Java community and its move to embrace and standardize on new Java technologies and work together on their deficiencies.
I understand that for existing hardware you can't plop a new JVM (KVM) in place overnight, but my point is that phones being produced now should have a Java 6 JVM/KVM in place -- not a stone age Java ME. Java ME seems like a dead-end cash cow.
I have no issue with Sun restricting free TCK access to GPL'ed projects or some such. As a JDK consumer for non-mobile usages, I also largely have no issues with Sun restricting free TCK access to forks from OpenJDK -- as I don't think the TCK suffices to ensure adequate compatibility and I see most value in this area in derivative/iterative, as opposed, to original works. For Java ME, though, I can see the need to start from a substantially different implementation base than OpenJDK. In that vein, e.g. as Google is using it, I can really see Harmony's point -- unless/until Sun opens their ME implementation (and bases it on something newer than 1.4!).
--
Jess Holle
Why?
Because I consider Java ME as it stands today as a rather harmful thing to the Java community.
Why?
Because it is stuck in pre-Java-5 days and has no clearly stated roadmap to start supporting more recent versions of Java. This splinters the Java community, libraries, techniques, training, etc, into a pre-Java-5 ghetto for those using Java ME (as well as those using old versions of WebSphere) and the "modern" camp. This is thus a drag on the overall Java community and its move to embrace and standardize on new Java technologies and work together on their deficiencies.
I understand that for existing hardware you can't plop a new JVM (KVM) in place overnight, but my point is that phones being produced now should have a Java 6 JVM/KVM in place -- not a stone age Java ME. Java ME seems like a dead-end cash cow.
I have no issue with Sun restricting free TCK access to GPL'ed projects or some such. As a JDK consumer for non-mobile usages, I also largely have no issues with Sun restricting free TCK access to forks from OpenJDK -- as I don't think the TCK suffices to ensure adequate compatibility and I see most value in this area in derivative/iterative, as opposed, to original works. For Java ME, though, I can see the need to start from a substantially different implementation base than OpenJDK. In that vein, e.g. as Google is using it, I can really see Harmony's point -- unless/until Sun opens their ME implementation (and bases it on something newer than 1.4!).
--
Jess Holle
markmac
Apr 7, 2009, 6:36:35 PM4/7/09
to The Java Posse
Thanks a lot Joda, that clarifies it a lot more for me, but once again
I just want to make sure of something.
Is there a 'JDK 7' or only an 'Open JDK 7'? Are they one in the same
at this point in time? If there is currently only an 'Open JDK 7',
thats fine, I understand completely, but if the 'JDK 7' exists, what
the heck is it?
Sorry if this is a bit trivial, but I just want to make sure I
understand this, its very interesting!
Cheers,
Mark
I just want to make sure of something.
Is there a 'JDK 7' or only an 'Open JDK 7'? Are they one in the same
at this point in time? If there is currently only an 'Open JDK 7',
thats fine, I understand completely, but if the 'JDK 7' exists, what
the heck is it?
Sorry if this is a bit trivial, but I just want to make sure I
understand this, its very interesting!
Cheers,
Mark
Michael Neale
Apr 7, 2009, 8:51:10 PM4/7/09
to The Java Posse
Thanks for the explanations - I think I finally get it now.
> To the Posse (replying to the episode),
> This is about the difference between an open specification and and
> open source implementation. The two things are different.
>
> Sun has successfully created OpenJDK, an open source project under the
> GPL license. This is being run in a pretty open manner and Sun should
> be praised for that.
>
> However, an open specification allows anyone else (other than Sun) to
> create their own implementation, one that is completely independent of
> Sun's code (and deals with IP transfer issues and compatibility
> testing amongst other issues). The name of the specification is the
> "Java SE platform" (Thus, the shorthand is "Java 7 is the spec, and
> JDK 7 is the implementation").
>
> At present, there is no Java SE 7 platform specification. My blogs
> have been seeking to show that until the problems Apache Harmony have
> faced are resolved, then there may well not be a Java SE 7
> specification. Hence, no "Java 7, only JDK 7".
>
> The question is whether the community is willing to allow Java to
> become just an implementation, rather than a specification. Amusingly,
> as an implementation without a specification, the Burton Group would
> classify OpenJDK as a "rebel framework" -http://apsblog.burtongroup.com/2009/03/open-source-is-not-as-open-as-...
> This is about the difference between an open specification and and
> open source implementation. The two things are different.
>
> Sun has successfully created OpenJDK, an open source project under the
> GPL license. This is being run in a pretty open manner and Sun should
> be praised for that.
>
> However, an open specification allows anyone else (other than Sun) to
> create their own implementation, one that is completely independent of
> Sun's code (and deals with IP transfer issues and compatibility
> testing amongst other issues). The name of the specification is the
> "Java SE platform" (Thus, the shorthand is "Java 7 is the spec, and
> JDK 7 is the implementation").
>
> At present, there is no Java SE 7 platform specification. My blogs
> have been seeking to show that until the problems Apache Harmony have
> faced are resolved, then there may well not be a Java SE 7
> specification. Hence, no "Java 7, only JDK 7".
>
> The question is whether the community is willing to allow Java to
> become just an implementation, rather than a specification. Amusingly,
> as an implementation without a specification, the Burton Group would
JodaStephen
Apr 8, 2009, 6:54:57 AM4/8/09
to The Java Posse
On Apr 7, 11:36 pm, markmac <mark.macum...@gmail.com> wrote:
> Is there a 'JDK 7' or only an 'Open JDK 7'? Are they one in the same
> at this point in time? If there is currently only an 'Open JDK 7',
> thats fine, I understand completely, but if the 'JDK 7' exists, what
> the heck is it?
"Open JDK 7" is a GPL licensed set of code
> Is there a 'JDK 7' or only an 'Open JDK 7'? Are they one in the same
> at this point in time? If there is currently only an 'Open JDK 7',
> thats fine, I understand completely, but if the 'JDK 7' exists, what
> the heck is it?
"Sun JDK 7" is the Sun private implementation of the same set of code
To the best of my knowledge, the two are now very close (and the
OpenJDK is the master). I believe that the Sun JDK 7 still makes use
of non-GPL code in certain key areas where that code performs better
than the GPL alternative.
"JDK 7" would therefore be the name shared between "Open JDK 7" and
"Sun JDK 7", and theoretically at some point an "IBM JDK 7". Of
course, without a specification and testing kit (ie. "Java SE 7") its
going to be impossible to know if these sets of code are compatible
with one another.
Dave Patterson
Apr 8, 2009, 10:47:08 AM4/8/09
to The Java Posse
Has Sun ever gone on the record as to why they insist on the field-of-
use clause in the JCK?
There has been some suggestion that it's to do with protecting the
revenue stream from ME licenses. If that's the case I don't see why
they wouldn't just say so.
Dave Patterson
On Apr 5, 2:08 pm, JodaStephen <jodastep...@googlemail.com> wrote:
> To the Posse (replying to the episode),
> This is about the difference between an open specification and and
> open source implementation. The two things are different.
>
> Sun has successfully created OpenJDK, an open source project under the
> GPL license. This is being run in a pretty open manner and Sun should
> be praised for that.
>
> However, an open specification allows anyone else (other than Sun) to
> create their own implementation, one that is completely independent of
> Sun's code (and deals with IP transfer issues and compatibility
> testing amongst other issues). The name of the specification is the
> "Java SE platform" (Thus, the shorthand is "Java 7 is the spec, and
> JDK 7 is the implementation").
>
> At present, there is no Java SE 7 platform specification. My blogs
> have been seeking to show that until the problems Apache Harmony have
> faced are resolved, then there may well not be a Java SE 7
> specification. Hence, no "Java 7, only JDK 7".
>
> The question is whether the community is willing to allow Java to
> become just an implementation, rather than a specification. Amusingly,
> as an implementation without a specification, the Burton Group would
> classify OpenJDK as a "rebel framework" -http://apsblog.burtongroup.com/2009/03/open-source-is-not-as-open-as-...
use clause in the JCK?
There has been some suggestion that it's to do with protecting the
revenue stream from ME licenses. If that's the case I don't see why
they wouldn't just say so.
Dave Patterson
On Apr 5, 2:08 pm, JodaStephen <jodastep...@googlemail.com> wrote:
> To the Posse (replying to the episode),
> This is about the difference between an open specification and and
> open source implementation. The two things are different.
>
> Sun has successfully created OpenJDK, an open source project under the
> GPL license. This is being run in a pretty open manner and Sun should
> be praised for that.
>
> However, an open specification allows anyone else (other than Sun) to
> create their own implementation, one that is completely independent of
> Sun's code (and deals with IP transfer issues and compatibility
> testing amongst other issues). The name of the specification is the
> "Java SE platform" (Thus, the shorthand is "Java 7 is the spec, and
> JDK 7 is the implementation").
>
> At present, there is no Java SE 7 platform specification. My blogs
> have been seeking to show that until the problems Apache Harmony have
> faced are resolved, then there may well not be a Java SE 7
> specification. Hence, no "Java 7, only JDK 7".
>
> The question is whether the community is willing to allow Java to
> become just an implementation, rather than a specification. Amusingly,
> as an implementation without a specification, the Burton Group would
Glyn
Apr 8, 2009, 3:37:38 PM4/8/09
to The Java Posse
Note that the title of the JDK 7 (https://jdk7.dev.java.net/) page is
"jdk7: Java SE 7"!
Glyn
On Apr 8, 6:54 am, JodaStephen <jodastep...@googlemail.com> wrote:
> <snip/>
"jdk7: Java SE 7"!
Glyn
On Apr 8, 6:54 am, JodaStephen <jodastep...@googlemail.com> wrote:
> <snip/>
Alex Buckley
Apr 8, 2009, 10:25:44 PM4/8/09
to The Java Posse, xiomara....@sun.com
Hi Glyn,
You may also notice the link "Latest JDK 7 binary snapshots" goes to a
page titled "Java™ Platform, Standard Edition 7 Binary Snapshot
Releases".
The JDK7 at java.net is Sun's Reference Implementation of the putative
Java SE 7 Platform Specification. It's not the OpenJDK "JDK7" project.
Let's not be uncharitable to the build engineers who are just
following precedent in assuming the eventual existence of a Java SE
Platform Specification.
Alex
You may also notice the link "Latest JDK 7 binary snapshots" goes to a
page titled "Java™ Platform, Standard Edition 7 Binary Snapshot
Releases".
The JDK7 at java.net is Sun's Reference Implementation of the putative
Java SE 7 Platform Specification. It's not the OpenJDK "JDK7" project.
Let's not be uncharitable to the build engineers who are just
following precedent in assuming the eventual existence of a Java SE
Platform Specification.
Alex
Alex Buckley
Apr 9, 2009, 1:54:41 PM4/9/09
to The Java Posse, xiomara....@sun.com
On Apr 8, 7:25 pm, Alex Buckley <Alex.Buck...@Sun.COM> wrote:
> The JDK7 at java.net is Sun's Reference Implementation of the putative
> Java SE 7 Platform Specification. It's not the OpenJDK "JDK7" project.
> Let's not be uncharitable to the build engineers who are just
> following precedent in assuming the eventual existence of a Java SE
> Platform Specification.
Further, there are separate pages for build bits:
> The JDK7 at java.net is Sun's Reference Implementation of the putative
> Java SE 7 Platform Specification. It's not the OpenJDK "JDK7" project.
> Let's not be uncharitable to the build engineers who are just
> following precedent in assuming the eventual existence of a Java SE
> Platform Specification.
JDK7-the-Reference-Implementation:
http://download.java.net/jdk7/
and
JDK7-the-OpenJDK-project:
http://download.java.net/openjdk/jdk7/
Alex
Reply all
Reply to author
Forward
0 new messages