JDK 10 forests open for bug fixes and small enhancements

[mark.reinhold at oracle.com]

The Mercurial forests for JDK 10 are now available:

  http://hg.openjdk.java.net/jdk10/jdk10    --  Master + dev (combined)
  http://hg.openjdk.java.net/jdk10/hs       --  HotSpot
  http://hg.openjdk.java.net/jdk10/sandbox  --  Sandbox
  http://hg.openjdk.java.net/jdk10/client   --  Client libraries

Corresponding -changes mailing lists have also been created.

The main differences from the forests for JDK 9 are that there are fewer
of them, and that the "dev" and master forests have been combined.  Most
committers should push directly into jdk10/jdk10 except when working on
HotSpot, a branch in the sandbox forest, or the client libraries.

As of today these forests are open for bug fixes and small enhancements.

Many committers will continue to focus mainly on JDK 9 for the next few
months so, for now, we'll semi-automatically pull changes from JDK 9 and
merge them into JDK 10.  This means that if you make a change in JDK 9
then you needn't do any extra work to get it into JDK 10, though if a
merge conflict arises then you might be asked to help resolve it.

For work that's new in JDK 10, please try to keep destabilizing changes
to a minimum, for now, in order to reduce the overhead of the continuous
merges from JDK 9.  If you want to work on a destabilizing change for
JDK 10 then consider starting that work in a sandbox branch.

Once JDK 9 is closer to being done we'll use the JEP 2.0 process [2], as
usual, to target significant features.

The JDK 10 forests have the same structure as the JDK 9 forests.  The
repository consolidation proposed in JEP 296 [1] might be implemented
later in the release.

In the (hopefully infrequent) event that a change in JDK 10 needs to be
back-ported to JDK 9 we'll have to figure out how to handle the duplicate
bug ids that will arise when a back-ported change is later merged forward
into JDK 10.  One solution may just be to disable the unique bug-id test
in jcheck, on the assumption that existing social conventions adequately
protect us from the pathological scenarios that are prevented by this
test.  Thoughts welcome ...

- Mark


[1] http://openjdk.java.net/jeps/296
[2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html