OK. Despite our deep interest in version strings, we rarely use
Runtime.Version.
On Thu, Jul 19, 2018 at 12:42 PM, Tony Printezis
wrote:
> Hi Martin,
>
> Yes, we have also used the opt field too. However, if I understand the
> spec correctly, when doing version comparisons, the opt string is
Hi Martin,
Yes, we have also used the opt field too. However, if I understand the spec
correctly, when doing version comparisons, the opt string is compared
alphanumerically. So if you add any numbers to it, you have to plan ahead
and pad with enough 0s to make sure the comparison works as
At Google we use --with-version-opt to put in local version data - that
works for us.
--with-version-patch is also available for third party build use.
On Thu, Jul 19, 2018 at 6:54 AM, Erik Joelsson
wrote:
> Since JEP 223 specifies an arbitrary length (something I had missed
> before), I
Hi Erik,
Thanks for the response. I created:
https://bugs.openjdk.java.net/browse/JDK-8207849
(infrastructure/build is the right component for this, right?)
and I’ll post a webrev soon.
Tony
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
On July 19, 2018 at 9:53:42 AM,
Since JEP 223 specifies an arbitrary length (something I had missed
before), I agree the build should support a few extra version numbers.
/Erik
On 2018-07-18 13:22, Tony Printezis wrote:
Hi all,
According to the Java version string spec (JEPs 223 and 322) the first part
of the version
Hi all,
According to the Java version string spec (JEPs 223 and 322) the first part
of the version string is a sequence of numbers separated by periods. The
sequence can be of arbitrary length. However, in the OpenJDK configure
scripts, the sequence length is fixed to exactly four numbers.
For
