new convention for hsx project repository names
John.Coomes at oracle.com
Thu Aug 29 21:09:27 PDT 2013
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,
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