new convention for hsx project repository names
Daniel D. Daugherty
daniel.daugherty at oracle.com
Fri Aug 30 05:59:25 PDT 2013
I like it! Details about how this will affect 'version' info
would be good (to echo David H)... I suspect we'll go back
to reporting the same version string for both JDK and VM:
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)
and here's the first release where the version numbers diverged:
java version "1.6.0_04"
Java(TM) SE Runtime Environment (build 1.6.0_04-b12)
Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)
HSX-10... now at HSX-25... it's been a long road...
On 8/29/13 10:09 PM, John Coomes wrote:
> The hsx Project has maintained a version number for HotSpot that is
> distinct from the JDK version--for example HotSpot version hs24 is
> being delivered into jdk7u40, and hs25 into jdk8. (For interested
> readers, some background info about separate versions is included at
> the end of this message.)
> The separate version has also been reflected in repository paths, e.g.:
> One often-mentioned problem with this naming scheme is that the
> correspondence between an hsx repository and the JDK release into which
> it will be delivered is not obvious. So we are planning on changing the
> repository naming convention going forward.
> More precisely, the new repository for HotSpot (and HotSpot-related)
> changes targeting jdk7u60 and later 7 updates would be:
> (The old convention would have used the name http://.../hsx/hsx24.<N>)
> This new repo will correspond to the jdk7u on-going development repo,
> i.e., http://hg.openjdk.java.net/jdk7u/jdk7u.
> Extending this a little into the future, once jdk7u60 reaches a point
> where a separate stabilization repo is needed, we will create
> http://hg.openjdk.java.net/hsx/jdk7u60. At that time the hsx/jdk7u
> repo would change to target the following jdk7u update release (if
> there is one).
> Similar conventions would apply to repositories for jdk8 updates once
> we have a need for them.
> Existing hsx repos should continue to be used; in particular, we will
> continue to use the on-going development repos for the forseeable
> These are currently targeting jdk8, and will switch to jdk9 in the near
> future. At that point a new jdk8 stabilization repo would be created:
> to be used instead of the existing hsx/hsx25 repo (hsx/hsx25 is
> currently used only by the hotspot gatekeeper, Alejandro Murillo).
> Despite the length of this message, I think the naming change is
> straightforward and will (slightly) simplify HotSpot development.
> Since there are already HotSpot changes pending for jdk7u60, I want to
> create the new repo within the next few days. If you have questions
> or feedback, please follow-up on the list.
> Background on the separate HotSpot version number:
> Because the same HotSpot source has been delivered simultaneously into
> multiple JDK releases (e.g., builds of hs23 were delivered into jdk8 and
> into jdk7u4, builds of hs22 were delivered into early jdk8 builds and
> into jdk7u2, and so on), a separate HotSpot version facilitated tracking
> the sources as they propagated to different releases. But at the same
> time, it also imposed the overhead of having to map from a HotSpot
> version to a JDK version and back again. This is not always simple,
> particularly for those that do not work with HotSpot on a day-to-day
> More recent hsx versions (hs24 and hs25), have really targeted only a
> single JDK release (although a few builds of hs24 did go into both jdk8
> and into jdk7u<N>). We expect this trend to continue, and thus the
> overhead of mapping from a HotSpot version to a JDK version is
More information about the hotspot-dev