RFR [9] 8177738: Runtime.Version must be a value-based class

Pavel Rappo pavel.rappo at oracle.com
Mon Apr 3 23:40:30 UTC 2017


> On 3 Apr 2017, at 20:39, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> 962 * [1-9][0-9]*((\.0)*\.[1-9][0-9]*)*
> 
> You removed the initial “^” which is still mentioned in JDK-8148822
> 
> < `^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$`. The sequence may be of arbitrary
> ---
>> `^[1-9][0-9]*((\.0)*\.[1-9][0-9]*)*$`. The sequence may be of arbitrary
> 
> JEP 223 is still using the former. Which is correct?

The patch from the thread [1] I referred to in my previous email removes ^ and $. 
So in this case I simply reused the patch and, once again [2], I do agree this
is an odd place to use boundary matchers, given $VNUM is only a prefix in $VSTR
and not the whole regex.

As for the JEP question, it's more for original designers/authors. If we agree
on it I will update the JEP.

> Since Version is now value based i think you need to check where it’s identity is used and replace with equals (which means ensuring that equals is efficient and could use identity under the covers). See usages in JarFile.

Will do, thanks!

>> 
> Separately i wish we could avoid using List<Integer> as the internal representation, it’s very inefficient, int[] is much better, the cost is then on the version() method but it’s easy to create an immutable List wrapping the array. (I logged an issue for that, but cannot remember the number.)

What are you concerns specifically? 
The startup time? 
The amount of simultaneously existing Version objects at runtime?
The use of `Integer` wrapper?

--------------------------------------------------------------------------------
[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/044277.html
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046941.html




More information about the core-libs-dev mailing list