Re: adding additional numbers to the Java version string
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 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 expected. Given > that the spec now allows extra numbers in the version string, it’d be good > to be able to use that instead. > > Additionally, we want both compareTo() and compareToIgnoreOptional() to > show our version as different to the upstream one it’s synced up to. And > adding an extra number to the version string satisfies that too. > > Other folks might want this to behave differently, and that’s totally OK! > But, the change I proposed will help anyone who has the above requirement. > >
Re: adding additional numbers to the Java version string
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 expected. Given that the spec now allows extra numbers in the version string, it’d be good to be able to use that instead. Additionally, we want both compareTo() and compareToIgnoreOptional() to show our version as different to the upstream one it’s synced up to. And adding an extra number to the version string satisfies that too. Other folks might want this to behave differently, and that’s totally OK! But, the change I proposed will help anyone who has the above requirement. Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On July 19, 2018 at 1:30:40 PM, Martin Buchholz (marti...@google.com) wrote: 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 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 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 our internal builds we’d like to add at least one additional number to >> the version string. Is there any interest in a change to the scripts to >> allow that? >> >> I’ve prototyped this in a generic way (can add up to 3 additional numbers, >> called “extra1”, “extra2”, and “extra3”). These are set by passing >> --with-version-extra(1|2|3)=… to configure. If they are not set, the >> version string is of course exactly the same as it was before. I also >> changed the way the value of --with-version-string=… is parsed to be able >> to also extract the additional three numbers, if present. >> >> Would this be generally helpful? >> >> Tony >> >> — >> Tony Printezis | @TonyPrintezis | tprinte...@twitter.com >> > >
Re: adding additional numbers to the Java version string
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 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 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 our internal builds we’d like to add at least one additional number to >> the version string. Is there any interest in a change to the scripts to >> allow that? >> >> I’ve prototyped this in a generic way (can add up to 3 additional numbers, >> called “extra1”, “extra2”, and “extra3”). These are set by passing >> --with-version-extra(1|2|3)=… to configure. If they are not set, the >> version string is of course exactly the same as it was before. I also >> changed the way the value of --with-version-string=… is parsed to be able >> to also extract the additional three numbers, if present. >> >> Would this be generally helpful? >> >> Tony >> >> — >> Tony Printezis | @TonyPrintezis | tprinte...@twitter.com >> > >
Re: adding additional numbers to the Java version string
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, Erik Joelsson (erik.joels...@oracle.com) wrote: 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 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 our internal builds we’d like to add at least one additional number to > the version string. Is there any interest in a change to the scripts to > allow that? > > I’ve prototyped this in a generic way (can add up to 3 additional numbers, > called “extra1”, “extra2”, and “extra3”). These are set by passing > --with-version-extra(1|2|3)=… to configure. If they are not set, the > version string is of course exactly the same as it was before. I also > changed the way the value of --with-version-string=… is parsed to be able > to also extract the additional three numbers, if present. > > Would this be generally helpful? > > Tony > > — > Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
Re: adding additional numbers to the Java version string
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 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 our internal builds we’d like to add at least one additional number to the version string. Is there any interest in a change to the scripts to allow that? I’ve prototyped this in a generic way (can add up to 3 additional numbers, called “extra1”, “extra2”, and “extra3”). These are set by passing --with-version-extra(1|2|3)=… to configure. If they are not set, the version string is of course exactly the same as it was before. I also changed the way the value of --with-version-string=… is parsed to be able to also extract the additional three numbers, if present. Would this be generally helpful? Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
adding additional numbers to the Java version string
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 our internal builds we’d like to add at least one additional number to the version string. Is there any interest in a change to the scripts to allow that? I’ve prototyped this in a generic way (can add up to 3 additional numbers, called “extra1”, “extra2”, and “extra3”). These are set by passing --with-version-extra(1|2|3)=… to configure. If they are not set, the version string is of course exactly the same as it was before. I also changed the way the value of --with-version-string=… is parsed to be able to also extract the additional three numbers, if present. Would this be generally helpful? Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
