The OpenJDK Project

http://openjdk.java.net/

• Open Source implementation of Java SE
• Licensed under GPLv2 (with Classpath exception)
• Java 7 reference implementation
• Collaboration space for different implementers..
  • IBM, RedHat, Apple, Twitter, Azul, SAP
• ..and playground for Java SE related projects:
  • Coin, Multi-Language VM, Jigsaw, Lambda, Closures, Zero, Framebuffer Toolkit,...

Contributing - Legal Aspects

Need to sign the Oracle Contribution Agreement (OCA)

• Copyright and patent sharing agreement with regard to your contribution
  • Oracle requirement to enable them to ship commercial version of the OpenJDK
  • Simple dual licensing model
• Both, you and Oracle, can treat your contribution as if they were the sole owners
• Oracle guarantees to always publish any contribution under a suitable
  Free Software Foundation (FSF) or Open Source Initiative (OSI) approved license.
• Simple one pager

OpenJDK and the Java™

• You are not allowed to call it Java™ (or Java™ compatible) because:
  • "Java" is a registered trademark
  • You don't get access to the Technology Compatibility Kit (TCK)

• Accessing the TCK requires the signing of the
  OpenJDK Community TCK License Agreement (OCTLA)
  • For OpenJDK or "substantially derived" projects only
  • OCTLA forbids disclosing TCK information to non-OCTLA licensees
  • "Field of use" restriction has been removed from the OCTLA, but..
  • ..access to OCTLA is still decided under the "Oracle screening committees" full discretion
    • There have been problems in the past (e.g. Azul - now resolved)
  • OCTLA is no trademark license!
• "OpenJDK" can be used in accordance with the "OpenJDK Trademark Notice"

OpenJDK Bylaws

The OpenJDK Bylaws are the "constitution" of the OpenJDK project

• Define the OpenJDK Community
  • an association of developers who collaborate upon open-source implementations of the Java Platform, as defined by the Java Community Process
• Define OpenJDK Groups, Projects and Roles
• Define the Governing Board
  which manages the structure and operation of the OpenJDK community
  • Chair (appointed by Oracle): Adam Messinger
  • Vice-Chair (appointed by IBM): Jason Gartner
  • OpenJDK Lead (appointed by Oracle): Mark Reinhold
  • At-Large Member (elected by the OpenJDK Members): Prof. Doug Lea, SUNY Oswego
  • At-Large Member (elected by the OpenJDK Members): Mike Milinkovich, Eclipse

OpenJDK Structure

• Participants: individuals who subscribed to a OpenJDK mailing list
• Contributors: Participants who signed the OCA
• Groups (currently 20)
  • consist of Group Members and a Group Lead
    • Committers with significant contributions elected by other Group Members
  • sponsor Projects
• Projects (currently 30)
  • produce artifacts (code, documentation, whole JDK releases)
  • have code repositories, mailing lists and possibly web content
  • consist of Authors, Committers, Reviewers and a Project Lead
    • Project Leads appoint Authors from Contributors
    • Committers elect Committers from Authors

OpenJDK Infrastructure

• The OpenJDK Homepage
• A bunch of mailing lists (currently > 70)
• More than 700 Mercurial repositories (!!!)
  • Every JDK is in fact a "Mercurial forest" of 7 single repositories
  • Integration (i.e. gate) repositories (~300) and inactive repositories (~200) can be ignored
  • There remain about 30 active forests (with about 210 repositories)
• Community code review server http://cr.openjdk.java.net
  • Hosts review requests in Webrev format
  • Must be at least Author for write access
• The good old bugs.sun.com Bug Database
  • Should be replaced "real soon" by a OpenJDK JIRA bug database

OpenJDK Tools - Mercurial

Mercurial is a distributed source control system available for all major platforms

OpenJDK uses forest so we must either:

• clone the subrepositories (corba, hotspot, jaxp, jaxws, jdk, langtools) manually:

> hg clone http://hg.openjdk.java.net/jdk8/jdk8
> cd jdk8
> hg clone http://hg.openjdk.java.net/jdk8/jdk8/corba
...
> hg clone http://hg.openjdk.java.net/jdk8/jdk8/langtools

• use the get_source.sh script which does the same in parallel:

> hg clone http://hg.openjdk.java.net/jdk8/jdk8
> cd jdk8
> sh ./get_source.sh

• make/scripts/hgforest.sh executes hg commands in all repositories

OpenJDK Tools - Webrev

Webrev is a "poor man's" code review system (e.g. webrev for Bug 6865265).

• A collection of diffs and patches in different formats
• Ability to graphically display diffs in HTML-frames
• May include additional HTML-formatted documentation
• Ability to automatically link back to Java bugs at bugs.sun.com
• Automatically generated by make/scripts/webrev.ksh

> cd jdk8/hotspot
> ksh webrev.ksh -o /tmp -O -c 6865265 -i 6865265.html
> unzip -l /tmp/webrev.zip
...
     5643  2011-09-28 17:36   webrev/raw_files/old/src/share/vm/opto/runtime.cpp
     8643  2011-09-28 17:36   webrev/index.html
---------                     -------
   320695                     75 files

OpenJDK Tools- JTreg

JTreg is a Regression Test Harness for the OpenJDK platform

• The same harness which is used to run the TCK/JCK test suite
• Quite powerful test harness for unit, functional, and even simple product tests
• Within OpenJDK currently only used for regression tests
• Test can consist of single or multiple Java/C/C++/ShellScript files
  • Tests are automatically discovered by the harness trough embedded tags
  • Check the JTreg FAQ for examples or just have a look at the tests under hotspot/test/

Building the OpenJDK

• Was very hard at the beginning
  • Required so called "binary plugins" for closed source components
• Should be straightforward now on recent Linux distributions
• Should not be to hard on Windows as well:
  • See my recent blog "How to build OpenJDK on Windows with free tools only"
• There's work underway to adapt the OpenJDK build to configure
• It is often possible to build only a part of the JDK
  • The HotSpot VM is known to build easier and much faster than the complete JDK
  • Parts of the class library can be build by calling make from the corresponding sub-directory
    (See for example the AWT Group page)

Fixing a Bug - Part 1

Bugs must be fixed in a development code line first!

• Try to reproduce the bug in the latest build (http://jdk8.java.net)
• Try with a debug build - this may give you more insights!

Search for the bug in the bug database bugs.sun.com

• Not all bugs are visible (security bugs, customer bugs, ..)
• If you open a new bug, it will become publicly visible in a few days/weeks only!

Fix the bug in the repository of the team that's responsible for the code

• E.g. jdk8/awt/jdk for AWT problems or hsx/hotspot-gc/hotspot for a GC bug

Discuss your bug and the fix on the corresponding mailing list if you're not sure

Fixing a Bug - Part 2

Once you have a fix, try to create a small regression test

• Test your fix an all relevant (and available) platforms

Create a Webrev from your fix (and test) and upload it to your web-space

• Remember that only Authors can upload to http://cr.openjdk.java.net
• If you have no possibility to host your webrev you can also submit the patch
  or the webrev as zip-file as mail attachment, but that's not recommended
• Document your fix in the Webrev, not in the email

Submit your fix to the appropriate mailing list

• E.g. "Request for review (S): 6865265 JVM crashes with missing ex. handler"

Be ready to discuss, defend and improve your fix several rounds

General Considerations

• Oracle is very conservative about changing shipped releases (i.e. JDK6, JDK7)
  • Fixes have to go trough the development versions before they are downported
• It may take a considerable amount of time to get your fix submitted because:
  • it's sometimes hard to find a sponsor who submits a change on your behalf.
  • until now, the vast majority of Committers are Oracle employees.
  • some commits have to pass quality gates which are accessible only from within Oracle
• Requests for Enhancements (RFEs) are usually only accepted for future releases
  • Consider using the JDK Enhancement-Proposal process for RFEs

Q&A