Thursday Feb 21, 2013

Functional Interfaces

As part of Project Lambda, after discussion with the JSR 335 expert group, we decided to add a FunctionalInterface annotation type to the platform. To a first approximation, functional interfaces are those interface types which define only a single method and are therefore usable in lambda expressions. (There are some tricky details in the definition of a functional interface relating to generics and also some details about excluding from consideration methods defined on java.lang.Object.) The new annotation type allows a library designer to clearly indicate the property of intending an interface type to be used with lambda expressions along with an implied commitment to keep that property true in the future. However, the compiler will allow any interface type meeting the structural properties of a functional interface to be used for a lambda expression regardless of whether or not the interface has a @FunctionalInterface annotation.

They types being added in the java.util.function package are by design functional interfaces and can be annotated with @FunctionalInterface from early days. However, many existing Java SE types are also functional interfaces and we want to identify and annotate those appropriately too. To find those candidate interfaces to be annotated, I ran an annotation processor over the code, using the same methodology as used to find Closeable candidates during JDK 7.

A significant number of candidates were found throughout the JDK. After suitable discussion and review, the first batch of core libraries changes have been pushed. Analogous discussions have been started in the 2D, awt, and swing areas.

For guidance in retrofitting @FunctionalInterface to an existing candidate type, if the type is routinely instantiated using an anonymous class, it is a good candidate for being annotated with @FunctionalInterface.

Monday Oct 29, 2012

JDK bug migration: components and subcomponents

One subtask of the JDK migration from the legacy bug tracking system to JIRA was reclassifying bugs from a three-level taxonomy in the legacy system, (product, category, subcategory), to a fundamentally two-level scheme in our customized JIRA instance, (component, subcomponent). In the JDK JIRA system, there is technically a third project-level classification, but by design a large majority of JDK-related bugs were migrated into a single "JDK" project. In the end, over 450 legacy subcategories were simplified into about 120 subcomponents in JIRA. The 120 subcomponents are distributed among 17 components. A rule of thumb used was that a subcategory had to have at least 50 bugs in it for it to be retained.

Below is a listing the component / subcomponent classification of the JDK JIRA project along with some notes and guidance on which OpenJDK email addresses cover different areas. Eventually, a separate incidents project to host new issues filed at bugs.sun.com will use a slightly simplified version of this scheme.


The preponderance of bugs and subcomponents for the JDK are in library-related areas, with components named foo-libs and subcomponents primarily named after packages. While there was an overall condensation of subcomponents in the migration, in some cases long-standing informal divisions in core libraries based on naming conventions in the description were promoted to formal subcomponents. For example, hundreds of bugs in the java.util subcomponent whose descriptions started with "(coll)" were moved into java.util:collections. Likewise, java.lang bugs starting with "(reflect)" and "(proxy)" were moved into java.lang:reflect.

  • client-libs (Predominantly discussed on 2d-dev and awt-dev and swing-dev.)
    • 2d
    • demo
    • java.awt
    • java.awt:i18n
    • java.beans (See beans-dev.)
    • javax.accessibility
    • javax.imageio
    • javax.sound (See sound-dev.)
    • javax.swing
  • core-libs (See core-libs-dev.)
    • java.io
    • java.io:serialization
    • java.lang
    • java.lang.invoke
    • java.lang:class_loading
    • java.lang:reflect
    • java.math
    • java.net
    • java.nio (Discussed on nio-dev.)
    • java.nio.charsets
    • java.rmi
    • java.sql
    • java.sql:bridge
    • java.text
    • java.util
    • java.util.concurrent
    • java.util.jar
    • java.util.logging
    • java.util.regex
    • java.util:collections
    • java.util:i18n
    • javax.annotation.processing
    • javax.lang.model
    • javax.naming (JNDI)
    • javax.script
    • javax.script:javascript
    • javax.sql
    • org.openjdk.jigsaw (See jigsaw-dev.)
  • security-libs (See security-dev.)
    • java.security
    • javax.crypto (JCE: includes SunJCE/MSCAPI/UCRYPTO/ECC)
    • javax.crypto:pkcs11 (JCE: PKCS11 only)
    • javax.net.ssl (JSSE, includes javax.security.cert)
    • javax.security
    • javax.smartcardio
    • javax.xml.crypto
    • org.ietf.jgss
    • org.ietf.jgss:krb5
  • other-libs
    • corba
    • corba:idl
    • corba:orb
    • corba:rmi-iiop
    • javadb
    • other (When no other subcomponent is more appropriate; use judiciously.)

Most of the subcomponents in the xml component are related to jaxp.

  • xml
    • jax-ws
    • jaxb
    • javax.xml.parsers (JAXP)
    • javax.xml.stream (JAXP)
    • javax.xml.transform (JAXP)
    • javax.xml.validation (JAXP)
    • javax.xml.xpath (JAXP)
    • jaxp (JAXP)
    • org.w3c.dom (JAXP)
    • org.xml.sax (JAXP)

For OpenJDK, most JVM-related bugs are connected to the HotSpot Java virtual machine.

The full JDK bug database contains entries related to legacy virtual machines that predate HotSpot as well as retired APIs.

  • vm-legacy
    • jit (Sun Exact VM)
    • jit_symantec (Symantec VM, before Exact VM)
    • jvmdi (JVM Debug Interface )
    • jvmpi (JVM Profiler Interface )
    • runtime (Exact VM Runtime)

Notable command line tools in the $JDK/bin directory have corresponding subcomponents.

Some aspects of JDK infrastructure directly affect JDK Hg repositories, but other do not.

  • infrastructure
    • build (See build-dev and build-infra-dev.)
    • licensing (Covers updates to the third party readme, licenses, and similar files.)
    • release_eng (Release engineering)
    • staging (Staging of web pages related to JDK releases.)

The specification subcomponent encompasses the formal language and virtual machine specifications.

  • specification
    • language (The Java Language Specification)
    • vm (The Java Virtual Machine Specification)

The code for the deploy and install areas is not currently included in OpenJDK.

  • deploy
    • deployment_toolkit
    • plugin
    • webstart
  • install
    • auto_update
    • install
    • servicetags

In the JDK, there are a number of cross-cutting concerns whose organization is essentially orthogonal to other areas. Since these areas generally have dedicated teams working on them, it is easier to find bugs of interest if these bugs are grouped first by their cross-cutting component rather than by the affected technology.

  • docs
    • doclet
    • guides
    • hotspot
    • release_notes
    • tools
    • tutorial
  • embedded
    • build
    • hotspot
    • libraries
  • globalization
    • locale-data
    • translation
  • performance
    • hotspot
    • libraries

The list of subcomponents will no doubt grow over time, but my inclination is to resist that growth since the addition of each subcomponent makes the system as a whole more complicated and harder to use.

When the system gets closer to being externalized, I plan to post more blog entries describing recommended use of various custom fields in the JDK project.

Thursday Oct 25, 2012

JDK bug migration: bugs.sun.com now backed by JIRA

The JDK bug migration from a Sun legacy system to JIRA has reached another planned milestone: the data displayed on bugs.sun.com is now backed by JIRA rather than by the legacy system. Besides maintaining the URLs to old bugs, bugs filed since the migration to JIRA are now visible too.

The basic information presented about a bug is the same as before, but reformatted and using JIRA terminology:

  • Instead of a "category", a bug now has a "component / subcomponent" classification. As outlined previously, part of the migration effort was reclassifying bugs according to a new classification scheme; I'll write more about the new scheme in a subsequent blog post.

  • Instead of a list of JDK versions a bug is "reported against," there is a list of "affected versions." The names of the JDK versions have largely been regularized; code names like "tiger" and "mantis" have been replaced by the release numbers like "5.0" and "1.4.2".

  • Instead of "release fixed," there are now "Fixed Versions."

  • The legacy system had many fields that could hold a sequence of text entries, including "Description," "Workaround", and "Evaluation." JIRA instead only has two analogous fields labeled as "Description" and a unified stream of "Comments."

Nearly coincident with switching to JIRA, we also enabled an agent which automatically updates a JIRA issue in response to pushes into JDK-related Hg repositories. These comments include the changeset URL, the user making the push, and a time stamp. These comments are first added when a fix is pushed to a team integration repository and then added again when the fix is pushed into the master repository for a release.

We're still in early days of production usage of JIRA for JDK bug tracking, but the transition to production went smoothly and over 1,000 new issues have already been filed. Many other facets of the migration are still in the works, including hosting new incidents filed at bugs.sun.com in a tailored incidents project in JIRA.

Wednesday Sep 26, 2012

JDK bug migration milestone: JIRA now the system of record

I'm pleased to announce the OpenJDK bug database migration project has reached a significant milestone: the JDK has switched from the legacy Sun "bugtraq" system to a new internal JIRA instance as the system of record for our bug tracking. This completes the initial phase of the previously described plan of getting OpenJDK onto an externally visible and writable bug tracker. The identities contained in the current system include recognized OpenJDK contributors.

The bug migration effort to date has been sizable in multiple dimensions. There are around 140,000 distinct issues imported into the JDK project of the JIRA instance, nearly 165,000 if backport issues to track multiple-release information are included. Separately, the Code Tools OpenJDK project has its own JIRA project populated with several thousands existing bugs. Once the OpenJDK JIRA instance is externalized, approved OpenJDK projects will be able to request the creation of a JIRA project for issue tracking.

There are many differences in the schema used to model bugs between the legacy bug system and the schema for the new JIRA projects. We've favored simplifications to the existing system where possible and, after much discussion, we've settled on five main states for the OpenJDK JIRA projects:

  • New
  • Open
  • In progress
  • Resolved
  • Closed

The Open and In-progress states can have a substate Understanding field set to track whether the issues has its "Cause Known" or "Fix understood". In the closed state, a Verification field can indicate whether a fix has been verified, unverified, or if the fix has failed.

At the moment, there will be very little externally visible difference between JIRA for OpenJDK and the legacy system it replaces. One difference is that bug numbers for newly filed issues in the JIRA JDK project will be 8000000 and above. If you are working with JDK Hg repositories, update any local copies of jcheck to the latest version which recognizes this expanded bug range. (The bug numbers of existing issues have been preserved on the import into JIRA). Relatively soon, we plan for the pages published on bugs.sun.com to be generated from information in JIRA rather than in the legacy system. When this occurs, there will be some differences in the page display and the terminology used will be revised to reflect JIRA usage, such as referring to the "component/subcomponent" of an issue rather than its "category". The exact timing of this transition will be announced when it is known.

We don't currently have a firm timeline for externalization of the JIRA system. Updates will be provided as they become available. However, that is unlikely to happen before JavaOne next week!

Tuesday Jun 05, 2012

Moving monarchs and dragons: migrating the JDK bugs to JIRA

Among insects, monarch butterflies and dragonflies have the longest migrations; migrating JDK bugs involves a long journey as well! As previously announced by Mark back in March, we've been working according to a revised plan to transition the JDK bug management from Sun's legacy system to initially an Oracle-internal JIRA instance which is afterward made visible and usable externally. I've been busily working on this project for the last few months and the team has made good progress on many aspects of the effort:

  • JDK bugs will be imported into JIRA regardless of age; bugs will also be imported regardless of state, including closed bugs. Consequently, the JDK bug project will start pre-populated with over 100,000 existing bugs, some dating all the way back to 1994. This will allow a continuity of information and allow new issues to be linked to old ones.

  • Using a custom import process, the Sun bug numbers will be preserved in JIRA. For example, the Sun bug with bug number 4040458 will become "JDK-4040458" in JIRA. In JIRA the project name, "JDK" in our case, is part of the bug's identifier. Bugs created after the JIRA migration will be numbered starting at 8000000; bugs imported from the legacy system have numbers ranging between 1000000 and 79999999.

  • We're working with the bugs.sun.com team to try to maintain continuity of the ability to both read JDK bug information as well as to file new incidents. At least for now, the overall architecture of bugs.sun.com will be the same as it is today: it will be a gateway bridging to an Oracle-internal system, but the internal system will change to JIRA from the legacy database. Generally we are aiming to preserve the visibility of bugs currently viewable on bugs.sun.com; however, bugs in areas not related to the JDK will not be visible after the transition to JIRA. New incoming incidents will be sent to a separate JIRA project for initial triage before possibly being moved into the JDK project.

  • JDK bug management leans heavily on being able to track the state of bugs in multiple releases, especially to coordinate delivering synchronized security releases (known as CPUs, critital patch updates, in Oracle parlance). For a security release, it is common for half a dozen or more release trains to be affected (for example, JDK 5, JDK 6 update, OpenJDK 6, JDK 7 update, JDK 8, virtual releases for HotSpot express, etc.). We've determined we need to track at least the tuple of (release, responsible engineer/assignee for the release, status in the release) for the release trains a fix is going into. To do this in JIRA, we are creating a separate port/backport issue type along with a custom link type to allow the multiple release information to be easily grouped and presented together.

  • The Sun legacy system had a three-level classification scheme, product, category, and subcategory. Out of the box, JIRA only has a one-level classification, component. We've implemented a custom second-level classification, subcomponent. As part of the bug migration we've taken the opportunity to think about how bugs should be grouped under a two-level system and we'll the new system will be simpler and more regular. The main top-level components of the JDK product will include:

    • core-libs
    • client-libs
    • deploy
    • install
    • security-libs
    • other-libs
    • tools
    • hotspot
    For the libs areas, the primary name of the subcomponent will be the package of the API in question. In the core-libs component, there will be subcomponents like:
    • java.lang
    • java.lang.class_loading
    • java.math
    • java.util
    • java.util:i18n
    In the tools component, subcomponents will primarily correspond to command names in $JDK/bin like, jar, javac, and javap.

    The first several bulk imports of the JDK bugs into JIRA have gone well and we're continuing to refine the import to have greater fidelity to the current data, including by reconstructing information not brought over in a structured fashion during the previous large JDK bug system migration back in 2004.

    We don't currently have a firm timeline of when the new system will be usable externally, but as it becomes available, I'll share further information in follow-up blog posts.

Monday Jul 25, 2011

OSCON: The State of JDK OpenJDK

After a short keynote on JDK 7, later in the day on Monday I presented a talk about The State of JDK and OpenJDK; the slides for the talk are now available.

Monday Feb 28, 2011

OpenJDK 6: b22 regression test results

Running with the jtreg flags, "-a -ignore:quiet -ea -esa" in all repositories, using generally accessible hosts for the network configuration file, and adding "-s" for langtools, the basic regression test results on Linux for OpenJDK 6 build 22 are:

  • HotSpot, 97 tests passed and 1 failed.

  • Langtools, 1,391 tests passed.

  • JDK, 3,300 tests pass, 30 fail, and 3 have errors.

The preponderance of changes in b22 were for security fixes; the hotspot and langtools tests results are identical to b21:

0: b21-hotspot/summary.txt  pass: 97; fail: 1
1: b22-hotspot/summary.txt  pass: 97; fail: 1

No differences
0: b21-langtools/summary.txt  pass: 1,391
1: b22-langtools/summary.txt  pass: 1,391

No differences

And in jdk, the results were nearly identical:

0: b21-jdka/summary.txt  pass: 3,295; fail: 33; error: 4
1: b22-jdk/summary.txt   pass: 3,300; fail: 30; error: 3

0      1      Test
error  pass   com/sun/jdi/DoubleAgentTest.java
fail   pass   java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java
fail   pass   java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java
fail   pass   java/awt/Focus/TranserFocusToWindow/TranserFocusToWindow.java
---    pass   tools/launcher/LibraryPath.java

5 differences

(The b21 baseline for the jdk repository was the test run where assertions where enabled.

OpenJDK 6 b22 Source Bundle Published

On February 28, 2011 the source bundle for OpenJDK 6 b22 was published.

The main changes in b22 are the latest round of security updates; in addition, there are a few copyright and licensing fixes. A detailed list of all the changes in b22 is also available.

Tuesday Feb 08, 2011

FOSDEM 2011: OpenJDK 6 and Project Coin

At FOSDEM last weekend, I gave two presentations, one on OpenJDK 6 and the other on Project Coin.

In "The State of OpenJDK 6," after providing some historical context, I discussed various upcoming changes. As relayed elsewhere, Kelly O'Hair will be assisting in OpenJDK 6 release management and security fixes to OpenJDK 6 from Oracle will continue through the end-of-life of the JDK 6 train, which per Oracle policy will occur no sooner than July 2012 (one year after JDK 7 ships GA). Also of note, after JDK 7 ships GA, Oracle will continue development of the 7 update releases in the open, similar to how it has been done pre-GA. In particular, there will not be the same dichotomy between the OpenJDK 7 code base and the 7 update code base as there is between OpenJDK 6 and the 6 update train.

I prepared some additional slides about OpenJDK 6, but did not present them due to time considerations. In the backup portion of slide deck, slide 13 graphs that since b11 the majority of fixes pushed into OpenJDK 6 have been HotSpot changes with the corba, jaxp, and jaxws areas clearly in maintenance. Slides 15 and 16 cover OpenJDK 6 regression test results since b11. There has been a growing number of tests and the overall pass rate is high and generally increasing; langtools and hotspot recently typically have a 100% pass rate and the pass rate for the jdk repository has risen from 98% to 99%.

For Project Coin, I presented the current state the language changes, discussed the development of changes, and spoke briefly on some aspects of developing the changes in the open.

All in all, another fun year at FOSDEM; next time, I hope I'm less afflicted with jet lag!

Friday Jan 21, 2011

OpenJDK 6: b21 regression test results

Running with the usual jtreg flags, "-a -ignore:quiet" in all repositories, using generally accessible hosts for the network configuration file, and adding "-s -ea -esa" for langtools, the basic regression test results on Linux for OpenJDK 6 build 21 are:

  • HotSpot, 97 tests passed and 1 failed.

  • Langtools, 1,391 tests passed.

  • JDK, 3,300 tests pass, 29 fail, and 3 have errors.

More HotSpot tests were added and all but one pass; the new failing test is improperly platform-specific:

0: b20-hotspot/summary.txt  pass: 85
1: b21-hotspot/summary.txt  pass: 97; fail: 1

0      1      Test
---    pass   compiler/6431242/Test.java
---    pass   compiler/6894807/IsInstanceTest.java
---    pass   compiler/6932496/Test6932496.java
---    pass   compiler/6946040/TestCharShortByteSwap.java
---    pass   compiler/6958485/Test.java
---    pass   compiler/6973329/Test.java
---    pass   compiler/6982370/Test6982370.java
---    pass   compiler/7002666/Test7002666.java
---    pass   gc/6581734/Test6581734.java
---    pass   runtime/6626217/Test6626217.sh
---    pass   runtime/6888954/vmerrors.sh
---    pass   runtime/6925573/SortMethodsTest.java
---    fail   runtime/6929067/Test6929067.sh

13 differences

In langtools some tests were added and all the tests continue to pass:

0: b20-langtools/summary.txt  pass: 1,365
1: b21-langtools/summary.txt  pass: 1,391

0      1      Test
---    pass   tools/javac/6508981/TestInferBinaryName.java
---    pass   tools/javac/6734819/T6734819a.java
---    pass   tools/javac/6734819/T6734819b.java
---    pass   tools/javac/6734819/T6734819c.java
---    pass   tools/javac/6889255/T6889255.java
---    pass   tools/javac/T6595666.java
---    pass   tools/javac/T6625520.java
---    pass   tools/javac/T6705935.java
---    pass   tools/javac/T6956638.java
---    pass   tools/javac/api/6411310/Test.java
---    pass   tools/javac/api/6440333/T6440333.java
---    pass   tools/javac/api/6733837/T6733837.java
---    pass   tools/javac/api/Sibling.java
---    pass   tools/javac/api/T6483788.java
---    pass   tools/javac/api/T6501502.java
---    pass   tools/javac/api/T6838467.java
---    pass   tools/javac/api/T6877206.java
pass   ---    tools/javac/policy/Test.java
pass   ---    tools/javac/policy/Test.java#id1
pass   ---    tools/javac/policy/Test.java#id2
pass   ---    tools/javac/policy/Test.java#id3
pass   ---    tools/javac/policy/Test.java#id4
pass   ---    tools/javac/policy/Test.java#id5
pass   ---    tools/javac/policy/Test.java#id6
pass   ---    tools/javac/policy/Test.java#id7
---    pass   tools/javac/policy/test1/Test1a.java
---    pass   tools/javac/policy/test1/Test1a.java#id1
---    pass   tools/javac/policy/test1/Test1a.java#id2
---    pass   tools/javac/policy/test1/Test1a.java#id3
---    pass   tools/javac/policy/test1/Test1a.java#id4
---    pass   tools/javac/policy/test1/Test1a.java#id5
---    pass   tools/javac/policy/test1/Test1a.java#id6
---    pass   tools/javac/policy/test1/Test1a.java#id7
---    pass   tools/javac/policy/test1/Test1b.java
---    pass   tools/javac/policy/test1/Test1b.java#id1
---    pass   tools/javac/policy/test1/Test1b.java#id2
---    pass   tools/javac/policy/test1/Test1b.java#id3
---    pass   tools/javac/policy/test2/Test.java
---    pass   tools/javac/policy/test2/Test.java#id1
---    pass   tools/javac/policy/test2/Test.java#id2
---    pass   tools/javac/policy/test2/Test.java#id3
---    pass   tools/javac/policy/test3/Test.java

42 differences

And in jdk, a small percentage of tests were added and the existing tests have generally consistent results:

0: b20-jdk/summary.txt  pass: 3,273; fail: 33; error: 2
1: b21-jdk/summary.txt  pass: 3,300; fail: 29; error: 3

0      1      Test
---    pass   com/sun/java/swing/plaf/gtk/Test6963870.java
fail   pass   java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java
---    pass   java/awt/Frame/FrameSize/TestFrameSize.java
fail   pass   java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
fail   pass   java/awt/Multiscreen/LocationRelativeToTest/LocationRelativeToTest.java
fail   pass   java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html
---    pass   java/awt/font/TextLayout/TestSinhalaChar.java
pass   error  java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh
---    pass   java/math/BigDecimal/MultiplyTests.java
pass   fail   java/net/InetAddress/IPv4Formats.java
pass   fail   java/net/URL/OpenStream.java
pass   fail   java/net/URLClassLoader/ClassLoad.java
pass   fail   java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java
---    pass   java/util/logging/AnonLoggerWeakRefLeak.sh
---    pass   java/util/logging/LoggerWeakRefLeak.sh
---    pass   javax/imageio/plugins/png/ITXtTest.java
---    pass   javax/imageio/plugins/png/ItxtUtf8Test.java
---    pass   javax/swing/JPopupMenu/6675802/bug6675802.java
---    pass   javax/swing/JPopupMenu/6691503/bug6691503.java
---    pass   javax/swing/Security/6938813/bug6938813.java
---    pass   javax/swing/UIDefaults/6622002/bug6622002.java
---    pass   javax/swing/UIDefaults/6795356/SwingLazyValueTest.java
---    pass   javax/swing/UIDefaults/6795356/TableTest.java
---    pass   javax/swing/UIDefaults/6795356/bug6795356.java
fail   pass   javax/swing/plaf/synth/Test6933784.java
fail   pass   sun/nio/cs/Test4200310.sh
---    pass   sun/security/pkcs11/SecureRandom/TestDeserialization.java
---    pass   sun/security/pkcs11/Signature/TestRSAKeyLength.java
---    pass   sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java
---    fail   sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java
---    pass   sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java
---    pass   sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java
---    pass   sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java
---    pass   sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java
fail   pass   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
fail   pass   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
fail   pass   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java
fail   pass   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java
pass   fail   sun/security/validator/CertReplace.java
---    pass   sun/tools/common/CommonTests.sh

40 differences

In addition to the basic results, the hotspot and jdk regression test suites were rerun with assertions and system assertions enabled, -ea -esa. (The langtools tests are already run with assertions enabled.) The results for hotspot were identical to running without assertions; in jdk a few additional tests failed:


0: b21-jdk/summary.txt   pass: 3,300; fail: 29; error: 3
1: b21-jdka/summary.txt  pass: 3,295; fail: 33; error: 4

0      1      Test
pass   error  com/sun/jdi/DoubleAgentTest.java
pass   fail   java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java
pass   fail   java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java
pass   fail   java/awt/Focus/TranserFocusToWindow/TranserFocusToWindow.java
fail   pass   java/awt/xembed/server/RunTestXEmbed.java
pass   fail   java/net/Authenticator/B4769350.java
pass   fail   java/net/CookieHandler/TestHttpCookie.java
fail   pass   java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java
pass   fail   java/util/ResourceBundle/Test4300693.java

9 differences

Going forward, the baseline regression test results for all OpenJDK 6 repositories will be reported with assertions and system assertions enabled.

OpenJDK 6 b21 Source Bundle Published

On January 21, 2011 the source bundle for OpenJDK 6 b21 was published.

Major changes include the latest round of security fixes and, courtesy Andrew John Hughes, syncing in HotSpot 19. In addition, jaxp was upgraded to 1.4.4, Kelly removed the binary plug logic, some stray rebranding issues were corrected, Jon Gibbons backported a set of JavaFileManager fixes from JDK 7, and the usual sorts of small backports of fixes from JDK 7 occurred too.

A detailed list of all the changes in b21 is also available.

Tuesday Nov 16, 2010

Project Coin: JSR Filed!

Keeping with the plan of Plan B for JDK 7 and 8, a Java Specification Request (JSR) proposal has been submitted to the JCP covering the language features explored by Project Coin. The proposal for Small Language Changes to Enhance Productivity is now being considered by the relevant JCP Executive Committee under an approval ballot which runs for two weeks. This proposal is one of four proposals submitted to the JCP to cover the full Plan B roadmap.

I'm looking forward to working with veterans of Project Coin and other expert group members to finish specifying, implementing, and testing the language changes to complete getting them into the platform.

Monday Nov 15, 2010

Original apt API files

With the transition of the java.net site to a new infrastructure, the time has come to retire the long-hosted but dormant apt mirror API project, https://aptmirrorapi.dev.java.net/. The old source bundles in the project are just the JDK 5 apt API; the implementation was not included. This apt project predated OpenJDK; with OpenJDK, the apt API and implementation (and much, much more!) has been available under an open source license for several years. Additionally, annotation processing should transition away from the first-generation apt to the much-improved and standardized JSR 269 annotation processing available since JDK 6 and supported directly in javac. Moreover, the apt tool and API have been deprecated as of JDK 7.

Purely for historical interest, I'm placing an archive of the apt source bundles on this blog:

Thursday Oct 28, 2010

Project Coin Improving Multi-catch and More Precise Rethrow

We've been working on some improvements to the multi-catch and more precise rethrow feature and are planning to push the changes soon. First, as long as a catch parameter is effectively final (in other words not reassigned inside the catch block), the more precise analysis will be enabled if the exception is rethrown. An explicit final modifier will no longer be needed to enable the more precise analysis.

As pointed out in the original proposal form for Improved Exception Handling for Java, the more precise exception analysis can cause programs that currently compile to stop compiling since more unreachable code is identified. While the general evolution policy of the JDK does not promise source compatibility across releases, gratuitously breaking compatibility should be avoided. Fortunately, after examining millions of lines of code in a diverse set of code bases, include the JDK, no instances where the more precise analysis would cause an actual source incompatibility were found. (Details of the analysis will be written up later.)

Second, the catch parameter of a multi-catch clause (catch(Exception1 | Exception2 e) {...}) will be regarded as implicitly final; the compiler will reject code that writes to such a catch parameter. Consequently, an explicit final modifier will no longer be needed in this case, although it will remain legal. This provides a more concise syntax for multi-catch in JDK 7 while preserving flexibility to more fully support disjunctive types in later JDK releases.

Monday Jun 21, 2010

OpenJDK 6: b20 regression test results

Running with the usual jtreg flags, "-a -ignore:quiet" in all repositories and adding "-s -ea -esa" for langtools, the basic regression test results on Linux for OpenJDK 6 build 20 are:

  • HotSpot, 85 tests passed.

  • Langtools, 1,365 tests passed.

  • JDK, 3,273 tests pass, 33 fail, and 2 have errors.

All the HotSpot tests continue to pass and more tests were added:

0: b19-hotspot/summary.txt  pass: 62
1: b20-hotspot/summary.txt  pass: 85

0      1      Test
---    pass   compiler/6663854/Test6663854.java
---    pass   compiler/6769124/TestArrayCopy6769124.java
---    pass   compiler/6769124/TestDeoptInt6769124.java
---    pass   compiler/6769124/TestUnalignedLoad6769124.java
---    pass   compiler/6792161/Test6792161.java
---    pass   compiler/6866651/Test.java
---    pass   compiler/6877254/Test.java
---    pass   compiler/6879902/Test6879902.java
---    pass   compiler/6880034/Test6880034.java
---    pass   compiler/6885584/Test6885584.java
---    pass   compiler/6891750/Test6891750.java
---    pass   compiler/6895383/Test.java
---    pass   compiler/6896727/Test.java
---    pass   compiler/6901572/Test.java
---    pass   compiler/6909839/Test6909839.java
---    pass   compiler/6910484/Test.java
---    pass   compiler/6910605/Test.java
---    pass   compiler/6910618/Test.java
---    pass   compiler/6912517/Test.java
---    pass   compiler/6916644/Test6916644.java
---    pass   compiler/6921969/TestMultiplyLongHiZero.java
---    pass   compiler/6930043/Test6930043.java
---    pass   compiler/6935535/Test.java

23 differences

In langtools all the tests continue to pass and a few tests were added:

0: b19-langtools/summary.txt  pass: 1,359
1: b20-langtools/summary.txt  pass: 1,365

0      1      Test
---    pass   tools/javac/cast/6548436/T6548436a.java
---    pass   tools/javac/cast/6548436/T6548436b.java
---    pass   tools/javac/cast/6548436/T6548436c.java
---    pass   tools/javac/cast/6548436/T6548436d.java
---    pass   tools/javac/processing/6499119/ClassProcessor.java
---    pass   tools/javac/processing/T6920317.java

6 differences

And in jdk a few tests were also added by virtue of the backports. Otherwise, the existing tests have generally consistent results. As done starting with build 18, the test run below was executed outside of Sun's and Oracle's wide-area network using generally accessible hosts for the network configuration file; to specify the networking configuratuion file, pass a "-e JTREG_TESTENV=Path_to_file" option to jtreg.

0: b19-jdk/summary.txt  pass: 3,261; fail: 28; error: 5
1: b20-jdk/summary.txt  pass: 3,273; fail: 33; error: 2

0      1      Test
---    pass   com/sun/java/swing/plaf/nimbus/ColorCustomizationTest.java
---    pass   com/sun/java/swing/plaf/nimbus/Test6919629.java
error  pass   java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java
error  pass   java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java
---    pass   java/awt/Focus/FrameJumpingToMouse/FrameJumpingToMouse.java
---    pass   java/awt/Focus/NonFocusableWindowTest/NoEventsTest.java
error  fail   java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java
pass   ---    java/awt/Focus/NonFocusableWindowTest/Test.java
fail   pass   java/awt/Focus/TypeAhead/TestFocusFreeze.java
---    pass   java/awt/Focus/WrongKeyTypedConsumedTest/WrongKeyTypedConsumedTest.java
pass   fail   java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
---    fail   java/awt/Graphics2D/DrawString/RotTransText.java
pass   fail   java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html
---    fail   java/awt/font/Rotate/TranslatedOutlineTest.java
pass   error  java/nio/channels/SocketChannel/Connect.java
fail   pass   java/nio/charset/Charset/Contains.java
pass   fail   java/util/Locale/Bug4184873Test.java
---    pass   javax/swing/MultiUIDefaults/4300666/bug4300666.java
---    pass   javax/swing/MultiUIDefaults/4331767/bug4331767.java
---    pass   javax/swing/MultiUIDefaults/Test6860438.java
---    fail   javax/swing/plaf/synth/Test6933784.java
---    pass   sun/pisces/DashStrokeTest.java
error  pass   sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
---    pass   sun/security/tools/jarsigner/diffend.sh
---    pass   sun/security/validator/CertReplace.java
---    pass   sun/security/validator/SameDN.java

26 differences

OpenJDK 6: b20 Source Bundle Published

On June 21, 2010 the source bundle for OpenJDK 6 b20 was published.

The predominant change in this build was rebranding, replacing Sun copyrights with Oracle ones. In the HotSpot repository, this was largely accomplished by Andrew John Hughes's backport of HotSpot 17 into OpenJDK 6. Additional fixes for Zero were also applied as were backports of Nimbus and timezone changes. On the build front, the jaxp and jax-ws source bundles are not downloaded by default anymore. To allow them to be downloaded, add "ALLOW_DOWNLOADS=true" to the top-level make command.

A detailed list of all the changes is also available.

Friday May 07, 2010

Draft of Restarted "OpenJDK Developers' Guide" available for discussion

I've been working on a restarted version of the "OpenJDK Developers' Guide" and I have a draft far enough along for general discussion. The content of the existing guide is primarily logistical and procedural in nature; in time, I plan to migrate this information to a JDK 7 specific page because many of the details are release-specific. The new guide is more conceptual and once completed is intended to be able to last for several releases without major updating.

The table of contents of draft version 0.775 is:

The full draft is available from here.

The compatibility sections are currently more fully developed than the ones about developing a change. (Long-time readers of this blog will be familiar with earlier versions of some of the material.)

All level of feedback is welcome, from correcting typos, to stylistic suggestions, to proposals for new sections. Significant feedback should be sent to the project alias for the guide.

Initially, I plan to maintain the guide as an HTML file and publish new versions as needed. Over time, guide maintenance may transition to more formal version control, such as a small Mercurial repository or a wiki.

Thursday Apr 15, 2010

OpenJDK 6: b19 regression test results

Running with the usual jtreg flags, -a -ignore:quiet in all repositories and adding -s and now also -ea -esa for langtools, the basic regression test results on Linux for OpenJDK 6 build 19 are:

  • HotSpot, 62 tests passed.

  • Langtools, 1,359 tests passed.

  • JDK, 3,261 tests pass, 28 fail, and 5 have errors.

All the HotSpot tests continue to pass and more tests were added:

0: b18-hotspot/summary.txt  pass: 24
1: b19-hotspot/summary.txt  pass: 62

0      1      Test
---    pass   compiler/5057225/Test5057225.java
---    pass   compiler/6378821/Test6378821.java
---    pass   compiler/6539464/Test.java
---    pass   compiler/6589834/Test_ia32.java
---    pass   compiler/6603011/Test.java
---    pass   compiler/6636138/Test1.java
---    pass   compiler/6636138/Test2.java
---    pass   compiler/6711117/Test.java
---    pass   compiler/6772683/InterruptedTest.java
---    pass   compiler/6778657/Test.java
---    pass   compiler/6795161/Test.java
---    pass   compiler/6795465/Test6795465.java
---    pass   compiler/6797305/Test6797305.java
---    pass   compiler/6799693/Test.java
---    pass   compiler/6800154/Test6800154.java
---    pass   compiler/6814842/Test6814842.java
---    pass   compiler/6823354/Test6823354.java
---    pass   compiler/6823453/Test.java
---    pass   compiler/6826736/Test.java
---    pass   compiler/6832293/Test.java
---    pass   compiler/6833129/Test.java
---    pass   compiler/6837011/Test6837011.java
---    pass   compiler/6837094/Test.java
---    pass   compiler/6843752/Test.java
---    pass   compiler/6849574/Test.java
---    pass   compiler/6851282/Test.java
---    pass   compiler/6852078/Test6852078.java
---    pass   compiler/6855164/Test.java
---    pass   compiler/6855215/Test6855215.java
---    pass   compiler/6857159/Test6857159.java
---    pass   compiler/6859338/Test6859338.java
---    pass   compiler/6860469/Test.java
---    pass   compiler/6863155/Test6863155.java
---    pass   compiler/6863420/Test.java
---    pass   compiler/6865031/Test.java
---    pass   compiler/6875866/Test.java
---    pass   compiler/6892265/Test.java
---    pass   gc/6845368/bigobj.java

38 differences

In langtools all the tests continue to pass and a few tests were added:

0: b18-langtools/summary.txt  pass: 1,355
1: b19-langtools/summary.txt  pass: 1,359

0      1      Test
---    pass   tools/javac/enum/T6724345.java
---    pass   tools/javac/processing/6511613/clss41701.java
---    pass   tools/javac/processing/6634138/T6634138.java
---    pass   tools/javac/processing/model/util/elements/VacuousEnum.java

4 differences

And in jdk, many tests were backported form JDK 7 in addition to some new test being added. Otherwise, the existing tests have generally consistent results. As done started with build 18, the test run below was executed outside of Sun's and Oracle's wide-area network using the following contents for the testing network configuration file:

host=icedtea.classpath.org
refusing_host=ns1.gnu.org
far_host=developer.classpath.org

The file location to use for the networking configuration can be set by passing a -e JTREG_TESTENV=Path to file option to jtreg.

0: b18-jdk/summary.txt  pass: 3,148; fail: 19; error: 2
1: b19-jdk/summary.txt  pass: 3,261; fail: 28; error: 5

0      1      Test
---    error  java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java
---    error  java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java
---    error  java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java
---    pass   java/awt/Focus/NonFocusableWindowTest/Test.java
---    fail   java/awt/Focus/TypeAhead/TestFocusFreeze.java
---    fail   java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html
fail   pass   java/awt/event/KeyEvent/CorrectTime/CorrectTime.java
---    fail   java/awt/xembed/server/RunTestXEmbed.java
---    pass   java/nio/charset/Charset/AvailableCharsetNames.java
---    pass   java/nio/charset/Charset/CharsetContainmentTest.java
---    fail   java/nio/charset/Charset/Contains.java
---    pass   java/nio/charset/Charset/EmptyCharsetName.java
---    pass   java/nio/charset/Charset/EncDec.java
---    pass   java/nio/charset/Charset/IllegalCharsetName.java
---    fail   java/nio/charset/Charset/NIOCharsetAvailabilityTest.java
---    pass   java/nio/charset/Charset/NullCharsetName.java
---    pass   java/nio/charset/Charset/RegisteredCharsets.java
---    pass   java/nio/charset/Charset/default.sh
---    pass   java/nio/charset/CharsetDecoder/AverageMax.java
---    pass   java/nio/charset/CharsetDecoder/EmptyInput.java
---    pass   java/nio/charset/CharsetEncoder/CanEncode.java
---    pass   java/nio/charset/CharsetEncoder/Flush.java
---    pass   java/nio/charset/RemovingSunIO/SunioAlias.java
---    pass   java/nio/charset/RemovingSunIO/TestCOMP.java
---    pass   java/nio/charset/RemovingSunIO/TestUnmappableForLength.java
---    pass   java/nio/charset/coders/BashCache.java
---    pass   java/nio/charset/coders/BashStreams.java
---    pass   java/nio/charset/coders/Check.java
---    pass   java/nio/charset/coders/CheckSJISMappingProp.sh
---    pass   java/nio/charset/coders/Errors.java
---    pass   java/nio/charset/coders/FullRead.java
---    pass   java/nio/charset/coders/IOCoders.java
---    pass   java/nio/charset/coders/IsLegalReplacement.java
---    pass   java/nio/charset/coders/ResetISO2022JP.java
---    pass   java/nio/charset/coders/StreamTimeout.java
---    pass   java/nio/charset/coders/Surrogates.java
---    pass   java/nio/charset/spi/basic.sh
fail   pass   java/rmi/transport/pinLastArguments/PinLastArguments.java
---    pass   java/text/Bidi/BidiBug.java
---    pass   java/text/Bidi/BidiEmbeddingTest.java
---    pass   java/text/Bidi/BidiSurrogateTest.java
---    pass   java/util/prefs/CommentsInXml.java
---    pass   java/util/prefs/ConflictInFlush.java
---    pass   java/util/prefs/ExportNode.java
---    pass   java/util/prefs/ExportSubtree.java
---    pass   java/util/prefs/PrefsSpi.sh
---    pass   java/util/prefs/RemoveReadOnlyNode.java
---    pass   java/util/prefs/RemoveUnregedListener.java
---    pass   java/util/prefs/SerializeExceptions.java
---    pass   javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java
---    pass   javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java
---    pass   javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java
---    pass   javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java
---    pass   javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java
---    pass   javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java
---    pass   javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java
---    pass   javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java
---    pass   javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java
---    pass   javax/swing/JColorChooser/Test4165217.java
---    pass   javax/swing/JColorChooser/Test4177735.java
---    pass   javax/swing/JColorChooser/Test4193384.java
---    pass   javax/swing/JColorChooser/Test4234761.java
---    pass   javax/swing/JColorChooser/Test4461329.java
---    pass   javax/swing/JColorChooser/Test4711996.java
---    pass   javax/swing/border/Test4120351.java
---    pass   javax/swing/border/Test4124729.java
---    pass   javax/swing/border/Test6461042.java
---    pass   sun/nio/cs/BufferUnderflowEUCTWTest.java
---    pass   sun/nio/cs/CheckCaseInsensitiveEncAliases.java
---    pass   sun/nio/cs/CheckHistoricalNames.java
---    pass   sun/nio/cs/ConvertSingle.java
---    pass   sun/nio/cs/DecoderOverflow.java
---    pass   sun/nio/cs/EUCJPUnderflowDecodeTest.java
---    pass   sun/nio/cs/EucJpLinux0212.java
---    pass   sun/nio/cs/EucJpLinuxDecoderRecoveryTest.java
---    pass   sun/nio/cs/EuroConverter.java
---    pass   sun/nio/cs/FindASCIICodingBugs.java
---    pass   sun/nio/cs/FindASCIIRangeCodingBugs.java
---    pass   sun/nio/cs/FindCanEncodeBugs.java
---    pass   sun/nio/cs/FindDecoderBugs.java
---    pass   sun/nio/cs/FindEncoderBugs.java
---    pass   sun/nio/cs/FindOneCharEncoderBugs.java
---    pass   sun/nio/cs/HWKatakanaMS932EncodeTest.java
---    pass   sun/nio/cs/ISCIITest.java
---    pass   sun/nio/cs/ISO8859x.java
---    pass   sun/nio/cs/JISAutoDetectTest.java
---    pass   sun/nio/cs/LatinCharReplacementTWTest.java
---    pass   sun/nio/cs/LeftOverSurrogate.java
---    pass   sun/nio/cs/MalformedSurrogates.java
---    pass   sun/nio/cs/NIOJISAutoDetectTest.java
---    pass   sun/nio/cs/ReadZero.java
---    pass   sun/nio/cs/SJISCanEncode.java
---    pass   sun/nio/cs/StreamEncoderClose.java
---    pass   sun/nio/cs/SurrogateGB18030Test.java
---    pass   sun/nio/cs/SurrogateTestEUCTW.java
---    pass   sun/nio/cs/SurrogateTestHKSCS.java
---    fail   sun/nio/cs/Test4200310.sh
---    pass   sun/nio/cs/Test4206507.java
---    pass   sun/nio/cs/Test6254467.java
---    pass   sun/nio/cs/Test6275027.java
---    pass   sun/nio/cs/TestCompoundTest.java
---    pass   sun/nio/cs/TestConverterDroppedCharacters.java
---    pass   sun/nio/cs/TestCp834_SBCS.java
---    pass   sun/nio/cs/TestCp93xSISO.java
---    pass   sun/nio/cs/TestIBMBugs.java
---    pass   sun/nio/cs/TestISCII91.java
---    pass   sun/nio/cs/TestISO2022CNDecoder.java
---    pass   sun/nio/cs/TestISO2022JP.java
---    pass   sun/nio/cs/TestISO2022JPEncoder.java
---    pass   sun/nio/cs/TestISO2022JPSubBytes.java
---    pass   sun/nio/cs/TestIllegalISO2022Esc.java
---    pass   sun/nio/cs/TestIllegalSJIS.java
---    pass   sun/nio/cs/TestJIS0208Decoder.java
---    pass   sun/nio/cs/TestJIS0212Decoder.java
---    pass   sun/nio/cs/TestMS5022X.java
---    pass   sun/nio/cs/TestMiscEUC_JP.java
---    fail   sun/nio/cs/TestSJIS0213.java
---    pass   sun/nio/cs/TestTrailingEscapesISO2022JP.java
---    pass   sun/nio/cs/TestUTF8BOM.java
---    pass   sun/nio/cs/TestUTF_16.java
---    pass   sun/nio/cs/TestUni2HKSCS.java
---    pass   sun/nio/cs/TestX11JIS0201.java
---    pass   sun/nio/cs/UkrainianIsNotRussian.java
---    pass   sun/nio/cs/ZeroedByteArrayEUCTWTest.java
pass   ---    sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java
pass   ---    sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java
pass   ---    sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java
pass   ---    sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java
pass   ---    sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java
---    fail   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
---    pass   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java
---    pass   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java
---    pass   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java
---    fail   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
---    fail   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java
---    fail   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java
---    pass   sun/security/util/Oid/BerOid.java

137 differences

OpenJDK: 6 b19 Source Bundle Published

On April 15, 2010 the source bundle for OpenJDK 6 b19 was published.

Major changes in this build include the latest round of security fixes and, courtesy of Andrew John Hughes, several significant backports including the HotSpot 16 changes, Zero support, and regression tests previously published under open source in JDK 7. Also of note, all the langtools regression tests now pass when run with assertions enabled.

A detailed list of all the changes is also available.

Thursday Mar 25, 2010

OpenJDK 6 Processes

[The entry below is a lightly edited version of a message previously sent to the OpenJDK 6 development alias jdk6-dev@openjdk.java.net.]


Since questions about OpenJDK 6 processes come up from time to time, in my role as release manager I thought it would be helpful to more fully document the current engineering practices and receive comments about them.

OpenJDK 6 is an implementation of the Java SE 6 specification valuing stability, compatibility, and security. As an implementation of the Java SE 6 specification, all changes to OpenJDK 6 must be allowable within that specification. This requirement precludes many API changes. Acceptable API changes include those permitted by the endorsed standards mechanism, such as upgrading to a newer version of a standalone technology, like a component JSR. One example of such an API change was the upgrade of JAX-WS from 2.0 to 2.1 in OpenJDK 6 build b06.

Changes allowable within the Java SE 6 specification may still be rejected for inclusion in OpenJDK 6 if the behavioral compatibility risk is judged as too large. (See previous write-ups of kinds of compatibility and compatibly regions in JDK releases.) Behavioral compatibility concerns implementation properties of the JDK. Clients of the JDK can knowingly or unknowingly come to rely upon implementation-specification behaviors not guaranteed by the specification and care should be taken to not break such applications needlessly. In contrast, if a change is appropriate for every other JDK release train, it is generally appropriate for OpenJDK 6 too. Examples of such universal changes include security fixes and time zone information updates.

With the above caveats, bug fixes in JDK 7 that do not involve specification changes have presumptive validity for OpenJDK 6. That is, by default such fixes are assumed to be applicable to OpenJDK 6, especially if having "soaked" in JDK 7 for a time without incident. On a related point, the fixes from the stabilized HotSpot forests (for example HotSpot Express 14 or HotSpot Express 16) are suitable for bulk porting to the OpenJDK 6 HotSpot repository without review of individual bugs.

As a general guideline, if a change is applicable to both JDK 7 and OpenJDK 6, the change should be made in JDK 7 no later than the change is made in OpenJDK 6.

With the exception of security fixes, all OpenJDK 6 code review traffic should be sent to jdk6-dev@openjdk.java.net for consideration before a commit occurs. (For subscription instructions and to browse the archives see http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev) All fixes require the approval of the release manager and may require additional technical review and approval at the discretion of the release manager. Security fixes are first kept confidential and applied to a private forest before being pushed to the public forest as part of the general synchronized publication of the fix to effected JDK release trains.

The master Mercurial forest of OpenJDK 6 repositories resides at:
http://hg.openjdk.java.net/jdk6/jdk6

Since there is only a single master OpenJDK 6 forest, near the end of a build period the release manager may defer otherwise acceptable changes to the start of the next build.

The schedule to tag builds of OpenJDK 6 is on an as-needed basis. The timing and feature list of a build is coordinated on the jdk6-dev alias with the IcedTea 6 project, a downstream client of OpenJDK 6. Before a build is tagged, regression and other testing is performed to verify the quality of the build.

After feedback is collected from jdk6-dev and this blog entry, the OpenJDK 6 project page will be updated with the current process information.


Alternatively, in JDK 7 there are a hierarchy of staging integration forests under the master to manage a higher rate of change, see OpenJDK Mercurial Wheel). As the rate of change in OpenJDK 6 is comparatively small, as long as the end of build quiet periods continue to be acceptably short, having a single master forest should be simpler than starting and managing an intermediate staging forest kept open to accepting changes at all times.

About

darcy

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll