RFR: 8144062: Determine appropriate module for jdk.Version

Paul Sandoz paul.sandoz at oracle.com
Thu Feb 25 09:14:43 UTC 2016

> On 25 Feb 2016, at 09:06, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 25/02/2016 05:59, Iris Clark wrote:
>> Hi, Alan, Mandy, and Mark.
>> After exploring a few module options (jdk.Version, jdk.dev [0]),
>> it looks like the best choice is to move jdk.Version to
>> java.lang.Runtime.Version (a nested class of Runtime).  It supports
>> the values returned by the java.{vm.}?version and
>> java.{vm.}?specification.version system properties.  By making
>> Version an SE API, it may be exported by the java.base module.
>> Please review the following changes to move jdk.Version to
>> jdk.lang.Runtime.Version.  Note that beyond the package name and
>> class declaration (to static), the only other changes in Version
>> are related to indentation.
> This looks good. We should probably change the synopsis on the JIRA issue to make it clearer that it is promoting Version to a standard API.

Dunno if the following was discussed for the review of internal impl.

I think it would be better to internally maintain an int[] for the version numbers rather than List<Integer>, that is more efficient in terms of space and comparing/equality (you can even use the new array comparison methods, thus the compareVersion becomes a one-liner).

It’s ok to take the hit for returning List<Integer> a simple AbstractList wrapper (also implementing RandomAccess) will suffice [*].

> Once this is in then the multi-release JAR file patch can be updated to make use of this.

And since this will now be part of SE it might be possible to revisit (as a follow on issue) the definition and use of the JarFile.Release enum by MR-JARs.


public List<Integer> version() {
    class VersionList extends AbstractList<Integer> implements RandomAccess {
        public Integer get(int index) {
            return version[index];

        public int size() {
            return version.length;
    return new VersionList();

More information about the core-libs-dev mailing list