> On 25 Feb 2016, at 09:06, Alan Bateman <alan.bate...@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.
Paul.
[*]
public List<Integer> version() {
class VersionList extends AbstractList<Integer> implements RandomAccess {
@Override
public Integer get(int index) {
return version[index];
}
@Override
public int size() {
return version.length;
}
}
return new VersionList();
}
