InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

IcedTea: The First 100% Compliant Open-Source Java

Posted by R.J. Lorimer on Jun 21, 2008

Sections
Enterprise Architecture,
Operations & Infrastructure,
Process & Practices,
Architecture & Design,
Development
Topics
Governance ,
Licensing ,
Open Source ,
Java ,
Community
Tags
Java SE ,
GNU
This week it was announced that the RedHat-initiated IcedTea project, along with OpenJDK, has reached 100% compliance with the Java Test Compatibility Kit (TCK), officially becoming the first completely open-source (GPL-licensed) Java implementation to pass the TCK.
This week the IcedTea Project reached an important milestone - The latest OpenJDK binary included in Fedora 9 (x86 and x86_64) passes the rigorous Java Test Compatibility Kit (TCK). This means that it provides all the required Java APIs and behaves like any other Java SE 6 implementation - in keeping with the portability goal of the Java platform.
Passing the TCK is generally considered a significant effort:
The Java TCK is a complex suite of tools and documentation that verifies that Java implementations conform to the Java specification. It consists of more than 80,000 tests and over 1 million lines of code.
As discussed previously on InfoQ , the IcedTea project is able to be a 100% GPL-licensed Java implementation by utilizing OpenJDK release snapshots, and replacing the remaining 5% of propertiary components with replacements from the GNU Classpath project.
The IcedTea project was created by the GNU Classpath team along with a handful of RedHat developers due to the need to replace all of the proprietary code with open source implementations. GNU Classpath provides many GPL-licensed replacements of the proprietary-licensed binary plugs still found in OpenJDK, making an IcedTea build of OpenJDK more-readily available for distributions on platforms such as Redhat's Fedora Linux distribution. Fedora 9 contains functionally complete OpenJDK packages, in part due to the contributions from IcedTea.
Other open-source Java implementations, such as Apache Harmony, have been unable up to this point to pass the TCK, however not all of the difficulties have been related to technical issues. In April of 2007, the Apache Software Foundation sent an open letter to Sun Microsystems with the intent of solving key issues with licensing the TCK for testing against the Harmony platform; licensing issues that prevented the Harmony team from legally running the TCK in an open-source way. While Sun responded to the open letter, there has as-of-yet been no resolution of the licensing issues for the Harmony team, and they are still unable to run the TCK.

The IcedTea project is not subject to the same licensing issues as Apache Harmony, as Sun has provided a special version of the TCK license that is targeted to any Java implementation that is a derivative of OpenJDK; something that Apache Harmony cannot claim.

InfoQ will continue to report on the development of open-source Java implementations as new information becomes available.
Should we distribute Jython and/or JRuby with IcedTea? by Bill Burke Posted
Re: Should we distribute Jython and/or JRuby with IcedTea? by Jonas Bonér Posted
Re: Should we distribute Jython and/or JRuby with IcedTea? by Viktor Klang Posted
Re: Should we distribute Jython and/or JRuby with IcedTea? by Clinton Lee Posted
Re: Should we distribute Jython and/or JRuby with IcedTea? by Weiqi Gao Posted
Re: Should we distribute Jython and/or JRuby with IcedTea? by Dean Del Ponte Posted
Not for Profit Open Source Community TCK License Agreement by Niall P Posted
Re: Not for Profit Open Source Community TCK License Agreement by Bill Burke Posted
  1. Back to top

    Should we distribute Jython and/or JRuby with IcedTea?

    by Bill Burke

    The dev manager of Iced Tea asked me an interesting question: Should we bundle JRuby and Jython with the IcedTea download?


    Let me know...


    --

    Bill Burke

    JBoss, a division of Red Hat

    bill.burkecentral.com

  2. Back to top

    Re: Should we distribute Jython and/or JRuby with IcedTea?

    by Jonas Bonér

    None of them, bundle Scala :-)

  3. Back to top

    Re: Should we distribute Jython and/or JRuby with IcedTea?

    by Clinton Lee

    The dev manager of Iced Tea asked me an interesting question: Should we bundle JRuby and Jython with the IcedTea download?
    Let me know...
    --
    Bill Burke
    JBoss, a division of Red Hat
    bill.burkecentral.com

    Initially I thought that would be good, but then changed my mind to 'no' for two reasons:

    1) A developer a can't assume its there as standard (ie: the sun jdk doesn't have it),

    2) It should be very easy to install as a library anyway with just a 'yum install jruby/jython' command.

    But I suppose it does have advantages if you are using [j]ruby or [j/p]ython frameworks.

  4. Back to top

    Re: Should we distribute Jython and/or JRuby with IcedTea?

    by Viktor Klang

    Jonas, you crazy guy. ;D

  5. Back to top

    Re: Should we distribute Jython and/or JRuby with IcedTea?

    by Weiqi Gao

    What benefits would bundling JRuby and Jython with IcedTea bring?

    And when you talk about IcedTea, do you mean the build harness only, or a complete OpenJDK packages in Fedora 9.

    If it is the latter, then my question is "what do you mean by \"bundle\"?" If it means when an end user installs "openjdk" by invoking the "yum install openjdk" command the system will also install JRuby and Jython after which the user cannot remove just the JRuby or Jython part by invoking "yum remove jruby" or "yum remove jython", I'd say that's a bad thing.

    If it means that the IcedTea team, after tackling the OpenJDK build/packaging problems, culminating in the inclusion of "openjdk" in Fedora 9, would like to do the same for JRuby and Jython, essentially allowing the newest versions of JRuby and Jython to be easily installed and removed from an end users system, I'd say that's a good thing.

  6. Back to top

    Re: Should we distribute Jython and/or JRuby with IcedTea?

    by Dean Del Ponte

    Groovy please!

  7. Back to top

    Not for Profit Open Source Community TCK License Agreement

    by Niall P

  8. Back to top

    Re: Not for Profit Open Source Community TCK License Agreement

    by Bill Burke

    Red hat has licensed (paid for) the JDK.

Educational Content

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.

Polyglot Persistence for Java Developers - Moving Out of the Relational Comfort Zone

Chris Richardson shows how he ported a relational database to three NoSQL data stores: Redis, Cassandra and MongoDB.

The Golden Circle – Why How What

Jean Tabaka challenges the audience to reflect on what Agile practices they are employing, how they are using them, ending with the questions “Why have their organization chosen to go Agile?

The Web Platform as a Limitless Pool of Innovation, with Andreas Gal

Andreas talks about the benefits of the Open Web and how it compares to proprietary stacks. He also talks about various projects that push the envelope like Boot to Gecko, Broadway and pdf.js.

Hadoop and NoSQLin a Big Data Environment

Ron Bodkin discusses early adoption of Hadoop, NoSQL and describes MapReduce and related libraries and Frameworks. Other topics include Hive, Pig, multi tenancy, and security in a big data environment

Spring and Platform Interoperability

Stephen Bohlen explains how Spring helps with interoperability between Java and .NET, demoing it with the help of a sample application.

How to Stop Writing Next Year's Unsustainable Piece of Code

Guilherme Silveira mentions some of the turning points in project development that may affect the quality of the code offering advice on avoiding writing crappy code.