I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Apache and Sun Still Not in Harmony

03.06.2009
| 13556 views |
  • submit to reddit

The JCR public review of Java Enterprise Edition 6 completed recently , but in doing so, it showed up more evidence of the long running dispute between the Apache Software Foundation and Sun over the Java Compatibility Kit (JCK), specifically it's licencing. If you take a look at the results, you'll see the big red X next to Apache.

"Apache must regretfully vote "No" for JSR-316, as we contend that the spec lead - Sun Microsystems - is not complying with the JSPA with respect to  Java SE TCK licensing.  We believe that members of the JCP that do not comply with the letter and spirit of the governing rules should not be allowed to lead JSRs"

Of course, the root of the problem goes back to that open letter that Apache wrote to Sun back in April 2007. In that letter, Apache complain that the JCK licence is too restrictive in the "fields of use" specified. Harmony, the Apache Java implementation, uses the Apache Licence rather than the GPL, and as such would need the JCK terms to change. As such, Apache complain that Sun is violating the Java Specification Participation Agreement.

In other news on the voting, SpringSource chose to abstain. While they approve of the introduction of profiles, they are "disappointed not to see a minimal web profile, especially as this has become the choice of most enterprise Java users... Finally, we are not convinced that the end result matches the goals of Java EE 6 as defined in the original specification request, which we strongly supported.".


If you had been given the choice, how would you have voted? And is it right for Apache to keep this dispute going. With the OpenJDK available anyway, does Harmony still have a place in the community?

References
Reference: http://www.h-online.com/open/Apache-votes-no-on-Java-EE-6--/news/112776

Comments

Hantsy Bai replied on Fri, 2009/03/06 - 10:22pm

Apache is so childish through the whole process.

As a developer, I also dislike an API incompatible java implementation, such as Harmony. Sun JDK is open source under GPL. I think it is good for developers, communities, companies.

 

Chandra Sekar.S replied on Sat, 2009/03/07 - 12:24am

What purpose does this minimal web profile serve? 

Every single web app uses a web and ORM framework.  So having JPA and JSF as the standardsfor this is indeed helpful.  Do these form part of the minimal web profile which Springsource wants or not?

Joshua Suereth replied on Sat, 2009/03/07 - 8:49am

I believe the whole "Web Beans was introduced too late, and is a risk" argument from SpringSource was missed.  Along with the "Dependency injection belong in J2SE not just J2EE".  I think these are interesting critiques of the whole JEE proposal.

On the Apache side of things:

  • if you look at Apache Harmony, it's *already modularized* (for the most part).   
  • Project Jigsaw appears to be a similar attempt.  However, as they won't let Apache TCK their JVM, they have the obvious advantage in the long run.  I do believe that Apache Harmony had the potential to pick up enough momentum (and with its modular system) begin to compete with OpenJDK for features/speed.
  • How many libraries do you use that are GPL vs. LGPL vs. Apache vs. BSD vs. EPL?  Requiring any java implementation to be GPL for testing purposes seems a bit much to me (but perhaps is good business sense).
  • Having several JVM implementations can help the ecosystem (especially if they're inter-operable) as the competition will drive each implementation to better and better optimzations/libraries.  this of course, assumes the ecosystem stays large enoguh to support more than one JVM.

Stephen Colebourne replied on Sat, 2009/03/07 - 9:46am

This story is factually misleading.

The story implies that the root of the disagreemnet between Sun and Apache is due to the different licenses - Apache license vs GPL. This is NOT the reason for the disagreement.

The license that is at issue is the special testing kit license offered by Sun to allow the testing of Harmony. The license offered was designed by Sun in such a way to make the tested code not open source. As such Apache could not accept the license. Even if Harmony were GPL licensed, the special testing kit license would still result in the tested product being not Open Source.

(Sun does offer a completely separate testing kit for code derived from OpenJDK - Harmony cannot use that either, as it is a clean-room implementation of Java)

The evidence for this issue being specific to Harmony is that Apache has successfully implemented many other JSRs, receiving licenses for the appropriate tests that are valid, including Geronimo, Tomcat, and many others.

To be clear, the special testing kit license offered for Harmony is uniquely different to every other testing kit license ever offered to Apache. The Apache Software Foundation strongly asserts that the offered testing license is in violation of the legal agreements signed with Sun within the JCP.

Also note that the other comments in the vote thread - http://jcp.org/en/jsr/results?id=4821 - indicate other JCP particpants agreeing with Apache's position.

More details than this are not in the public domain - as a member of the Apache Software Foundation, I am aware of some additional information which still remains private. It is my personal opinion that the ASF is very right to feel aggrieved and that the whole episode has caused Java huge damage.

Stephen Colebourne

Member, Apache Software Foundation, speaking personally

 

Pete Cox replied on Sat, 2009/03/07 - 9:25pm

Is voting the most appropriate place for Apache to voice objections? Until this issue is resolved, Apache will veto every vote presented to it. Might the community be better represented by an organisation that will constructively debate the technical merits of each proposal? Apache would imply that all JCP activity should be suspended until Sun caves in.


I personally think Harmony is a massive waste of time and resources that could have been be better spent growing the Java platform by contributing to GNU Classpath and now openjdk as Red Hat have done. But each to their own. See below...

That said, it's better for anyone attempting to release a competing JRE to be certified Java compatible than almost-compatible 'write once debug everywhere'. For this reason, access to the JCK should be available to anyone who asks for it. 

 

 

 

[--- aside: begin anti-harmony rant ---]

I have serious misgivings about the relevance and motivations for Harmony. Apache announced the project with some fanfare that they would work with GNU Classpath folks to present a united front against Sun's, then proprietary, JVM but with the backing of Apache and all its umbrella supporters. Then it was decided that code would not be used from Classpath because of the GPL. So instead we have a 2nd incomplete cleanroom implementation of the class libraries and for little tangible benefit than could be provided in finishing and JCKifying GNU Classpath.

We've seen in the example of Apple's discontinuation of JRE 1.6 support for PPC and IA-32 Macs how damaging proprietary implementations without the protections of copylefting can be for the platform and Java brand. Hardware perfectly capable of running the latest version of Java is sacrificed to the 'planned obsolence' of Apple's marketing department - not much consolation for someone who would want to use/deploy Java 6 applications with said hardware and OS. I just hope a similar situation doesn't arise with Harmony whereby the liberties of the Apache license could lead to closed forks that are then abandoned when the initial developers lose interest.

The fragmentation of development efforts doesn't consolidate innovations such as XRender, shark, caciocavallo and ports for freebsd, haiku and 'soylatte' that have appeared under openjdk/icedtea. Due to licensing, such efforts are unlikely to ever run on a Harmony stack, nor those of Harmony on openjdk.

[--- end anti-harmony rant ---]

Having questioned the utility of Harmony, I'd rather it were tested as JCK compatible if I were ever forced to deploy to it.

David Gilbert replied on Sun, 2009/03/08 - 3:25am

Stephen Colebourne wrote:
The Apache Software Foundation strongly asserts that the offered testing license is in violation of the legal agreements signed with Sun within the JCP.


Given the existence of this legal agreement why didn't Apache take those strong assertions to court and get a judgement. Problem solved and it's not even the end of 2007 yet.

Instead, Apache has pursued a useless publicity campaign starting with that ill-judged open letter, and continuing with voting down JSRs that have *nothing* to do with J2SE and the TCK. It's achieving nothing, and making Apache look like a bunch of primary school kids trying to resolve a playground dispute.

By the way, I'm all for free and unencumbered access to the TCK...I just don't like the approach that Apache is taking in trying to get it.

Stephen Colebourne replied on Sun, 2009/03/08 - 5:59am

Until this issue is resolved, Apache will veto every vote presented to it.

Apache will only vote against JSRs where the licensing conditions are unclear or where Sun is the submitting party. This is rational and reasonable behaviour.

 Instead, Apache has pursued a useless publicity campaign starting with that ill-judged open letter, and continuing with voting down JSRs that have *nothing* to do with J2SE and the TCK. It's achieving nothing...

This exercise has been extremely beneficial to other JCP members in that they now realise just how big some of the issues with the JCP are. Witness the comments by other major players on vote threads. Ultimately, a resolution will be of great benefit to the whole Java community.

So instead we have a 2nd incomplete cleanroom implementation of the class libraries and for little tangible benefit than could be provided in finishing and JCKifying GNU Classpath.

GNU classpath cannot be tested either. Sun only provides a testing kit license to projects "derived from OpenJDK". GNU classpath is not derived from OpenJDK, so would not be eligible. Without the ability to create new implementations, the 'Java trap' effectively still exists.

As noted above, whether Harmony (or GNU classpath) is a good idea or not is completely separate to the issue of whether it is entitled to exist. The evidence would seem to suggest that Sun has a special reason for not wanting this JSR to be tested whereas it is happy with all other JSRs.

 

Jeroen Wenting replied on Sun, 2009/03/08 - 11:07am

Until Apache grows up and behaves like a group of mature human beings rather than a mob of teenage babboons, the JCP should just ignore them, if not throw them out.

David Gilbert replied on Sun, 2009/03/08 - 3:37pm in response to: Stephen Colebourne

Stephen Colebourne wrote:

Apache will only vote against JSRs where the licensing conditions are unclear or where Sun is the submitting party. This is rational and reasonable behaviour.

That's arguable.  If it is such rational and reasonable behaviour, why aren't the other participants voting NO also?

Stephen Colebourne wrote:

Without the ability to create new implementations, the 'Java trap' effectively still exists. 

That's not true.  The "Java Trap" is the Free Software Foundation's reference to a situation where a Java program is free software, but has a dependency on a non-free Java runtime.  But now that IcedTea has passed the TCK, there *is* a free Java runtime. You only need *one* free Java runtime to break the Java Trap, and we have that now.

Michael Manske replied on Mon, 2009/03/09 - 4:37am in response to: Jeroen Wenting

Such a comment is disrespectful and has nothing to do with the topic discussed here! It's rather "bashing" than "discussing". The fact that the JCP is far from perfect is nothing new. Ignoring the problem or bashing the one who points out that problem does not solve anything.

Tim O'farrell replied on Mon, 2009/03/09 - 5:46am in response to: Chandra Sekar.S

Most web apps have a web and ORM framework, but these are not nescessarily JPA and JSF - What about pure hibernate and GWT? A large  proportion of companies and developers have not embraced either of these technologies, and are interested in the minimal approach on top of which they can pick and choose their own framework. (Just look at the success of Tomcat...)

Dalibor Topic replied on Mon, 2009/03/09 - 8:36am in response to: Stephen Colebourne

Actually, the OpenJDK Community TCK License Agreement says 'substantially derived', in order to allow for hybrid runtimes consisting of, say, the HotSpot VM and a different class library or a different VM and the OpenJDK class library to apply and get the tools necessary to verify compatibility with the Java SE 6 platform.

Among the list of OpenJDK Community TCK licensees, two are for hybrid projects combining a free software VM (Cacao) with the OpenJDK class library. While they haven't passed the tests yet, it would be cool to see them do that. More on what it takes to pass the tests below.

 There are three implementations based on the OpenJDK 6 code base that have passed the Java SE 6 compatibility testing: IcedTea 6 on Fedora 9 & 10 for x86-64 and x86 architectures, IcedTea 6 with the Zero interpreter engine for HotSpot on Fedora 10 for powerpc and powerpc64 architectures, and pristine OpenJDK 6 on Fedora 8 on the x86 architecture. So there are at least three ways the old 'Java trap' was successfully smashed in the past year, with many more to come.

You couldn't certify GNU Classpath by itself, as that's 'just' the class library part of the runtime, so you'd be missing the other half, the VM, to be able to actually run code, but you could certainly combine GNU Classpath with HotSpot and work on that combination, if that's what you really want do. Accordingly, it would certainly be possible to create an implementation based on GNU Classpath and the HotSpot VM and to apply for the OpenJDK Community TCK for that combination - no one has done that yet, though.

So why does Sun restrict the OpenJDK Community TCK to 'substantially derived' implementations? I wasn't at Sun when the license was conceived, but I think the obvious answer is that TCK testing is a lot of (manual) work, even when one is starting from a feature-complete implementation, like OpenJDK 6, and just needs to focus on setup, testing and bug fixing. Yeah, as the Kaffe maintainer, I thought 'how much work could it possibly be?', too - so let me give you some very rough numbers:

It took Red Hat about 9 months to go from getting the TCK to passing it for IcedTea 6, similarly, it took Joe Darcy around 9 months from creation of OpenJDK 6 to a passing build - and those were feature complete implementations, where just 3% of the components were rewritten (graphics rasterizer, font rasterizer, sound engine, etc.) - and they were building on each others work. For a class library implementation fully done from scratch, the time required for the bug fixing part in order to make it comply with the specifications would likely be a large multiple of the 9 months (30 sounds good), not to mention that no class library implementation beside the reference implementation in OpenJDK is feature complete.

So, in a world in which any compatible free software Java SE 6 implementation in the foreseeable future is likely going to be substantially derived from OpenJDK 6 for very simple, rational economic reasons (it works well, it can be done on a rational schedule, etc.) - do you just toss the TCK binaries over the wall, or do you nurture the community of free software, fully compatible Java SE 6 implementations and work on gradually having a sequence of doable success stories, while expanding the clout of the platform? The latter approach works actually much better in practice, as experience shows, and has already delivered several fully compatible, fully free software Java SE 6 implementations.

So far, we have:

* pristine OpenJDK 6 (replaced 3% of encumbered code)

* IcedTea 6 (OpenJDK 6 + various nice and useful patches)

* IcedTea 6 + Zero (IcedTea 6 + replaced interpreter engine in HotSpot)

In the future, we may have

* new OpenJDK 6/7 ports (OpenJDK + rewrites of some of the class library code)

* IcedTea 6 + Shark (IcedTea 6 + replaced jit engine in HotSpot)

* Cacao + OpenJDK 6 (Cacao VM with OpenJDK class library)

* HotSpot + GNU Classpath (hypothetical, but still possible)

 

Once you're at a point where you have an independent VM that passes the compatibility testing with OpenJDK and you have an independent class library that passes the compatibility testing with OpenJDK, then you are at a point where a combination of the two independent pieces has a fair chance, with a lot of integration, testing and bug fixing work, to pass the compatibility testing on its own as well.

At that point in time, it would make sense, in my opinion, to remove the 'training wheels' clause of 'substantially derived' - but before that's the case, as a project looking for build a fully compatible free software Java SE 6 implementation, you really want to leverage the work already done in OpenJDK, otherwise you're just shooting yourself in the foot.

Alex(JAlexoid) ... replied on Tue, 2009/03/10 - 4:07pm

On the Sun vs Apache.

Isn't passing TCK give you a right to name you implementation "Java"? As in a trademark. (Then the following statements are valid.)
Then I see no reason why Sun should be giving anyone the ability to compete with them using their own trademark. Even if the competition is OSS. Noone should forget that Sun is a for profit corporation and has other products that they sell, with the trademark Java in the title. So, the bottom line is, that ASF is trying to force Sun to give up their trademark.

 

Geir Magnusson replied on Tue, 2009/03/10 - 7:50pm in response to: Alex(JAlexoid) Panzin

Alex... no.  Passing the TCK doesn't give you the right to call it "Java".  That's Sun's trademark, and the ASF has no interest in getting Sun to give up a trademark.  Passing the TCK simply lets you claim to users that your software passes the compatibility tests for the specification. The ASF isn't trying to interfere with Sun's business - it's just trying to license the TCK for Java SE 5 (that the ASF is ironically required to get according to the spec license) so that it can determine that it's implementation of the Java SE 5 specification is complete and correct. Sun is clearly afraid of Apache Harmony passing the TCK.  You might ask them why.
  

Geir Magnusson replied on Tue, 2009/03/10 - 8:20pm in response to: Pete Cox

Pete,

 Voting is the only vehicle that the ASF has at it's disposal short of suing Sun for breach of contract.  Putting aside the fact that the ASF doesn't want to instigate a lawsuit since we believe that this should be a community-resolveable issue, given that Sun is a multi-billion dollar company and the ASF is a charitable organization dependent upon donations, paying for such a move would put the ASF in serious financial peril.  They'd bury us.

Community governance is one of the responsibilities of the EC of the JCP - we believe that if a member of the JCP isn't complying with the JSPA, they shouldn't be allowed to participate, and given the screwed-up structure of the JCP, which is really a set of two-party contracts between Sun and each member, we have few tools besides voting. And because of this screwed up hub-and-spoke structure, no other EC member has any legal standing to get involved.

We contend not that all JCP activity stop until Sun caves, but rather Sun's participation stops until Sun meets it's obligations. We're not demanding something that is out of the ordinary or extreme - it's a test kit, one of the underpinnings of the compatibility promise of the entire ecosystem. We would demand this of any JCP member who behaved this way, and I'm constantly amazed that the community gives Sun a pass on this.

I believe that what we have going on here is *very* dangerous to Java. Sun's internal business troubles are dictating who can and who cannot create an independent implementation of a Java specification, and this shouldn't be tolerated by a community that stands for openness and freedom, no matter who the spec lead is, which spec it is, or who the implementer is. They beauty and strength of the Java ecosystem is the spec/RI/TCK approach that allows the community to collaborate on specification and then go produce multiple independent implementations, all with a promise to users that those implementations behave as the spec says they will. Sun's continued refusal to abide by the fundamentals puts the entire foundation of the Java ecosystem at risk.

What happens when Sun finds Red Hat threatening to some aspect of their business? Or some other spec lead decides to protect a market by limiting or burdening independent implementations? How could we object to that behavior when we are letting Sun get away with it?

Put aside any anti-Harmony bias you may have, and try to think about the situation independent of the specific actors : Should a spec lead have the ability to control the distribution of independent implementations of a spec, beyond the JCP requirement that the implementation pass the TCK to demonstrate compatibility?

Ask Sun why they are so afraid of Apache Harmony passing the TCK.

 

Werner Keil replied on Fri, 2009/03/13 - 1:24pm in response to: Stephen Colebourne

Stephen, I believe, you may have referred to either Red Hat's comments or mine? I agree with most of their opinion, which where it correlates with that of Apache may also subsequently follow their ideas. However, would we fully agree with Apache's position, then I guess we both had voted "No" ?;-) Werner Keil Member, Executive Committee (SE/EE)

jiji530 (not verified) replied on Mon, 2009/06/29 - 9:50pm

thanks for your post.perhaps you will like abercrombie ed hardy mortgage rates tiffanys ed hardy Is not it?

Ella Chen replied on Thu, 2009/07/30 - 12:28am

This is quite a controversial question.

 

But I do appreciate the comment style of  Stephen Coldbourne. Very obejective.

 

<a href="http://www.airjordampremium.com">Jordan</a> 

Lenn Lenin replied on Fri, 2012/10/19 - 1:14am in response to: Hantsy Bai

Hey all ive started messing around with jdk im only new to this and ive run the hello world app. I would like to know if anyone knows if there is anywere i can get access to the language it's all very well copying programs directly from tutorials but i would love to learn the language myself and be able write my own programs some day. Am i being nieve to think i can teach myself this from the internet. Do all programs begin with the same basic imput (Class Definition, Source Code Comments, and The main Method. I probably havn't put no were near enough info in this to get a clear answer but as i say im only new to this and just fancy giving it a try. THANKYOU.

Jackinson

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.