JDK 10 forests open for bug fixes and small enhancements
david.holmes at oracle.com
Thu Jan 26 12:06:03 UTC 2017
Great to see this. However, it seems (understandably) what we have
populated jdk10 forests with is slightly out-of-date with respect to
current jdk9 forests. What is the automated process for getting any
missing JDK 9 fixes into JDK 10? At present we can't push anything via
JPRT because we get failures due to missing fixes.
On 26/01/2017 9:34 AM, mark.reinhold at oracle.com wrote:
> 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 , 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  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
>  http://openjdk.java.net/jeps/296
>  http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
More information about the jdk10-dev