Re: [13] RFR: JDK-8225392: Comparison builds are failing due to cacerts file
On 6/14/19 11:33 AM, Weijun Wang wrote: Here is the updated webrev http://cr.openjdk.java.net/~weijun/8225392/webrev.01/ The only change is ordering in 'keytool -list' and its test. Looks fine. --Sean Thanks, Max On Jun 14, 2019, at 7:55 PM, Sean Mullan wrote: On 6/14/19 1:49 AM, Weijun Wang wrote: BTW, something not related but similar: Do you like me to also sort aliases alphabetically in the output of "keytool -list"? Yes, I think that is useful. --Sean
Re: jdk 14 version string scheme changed?
The configure script has parsing logic for interpreting a full version string and splitting it into all the parts if you need inspiration. /Erik On 2019-06-14 13:51, Martin Buchholz wrote: Thanks! (OPT is harder to parse out than I expected ...) On Fri, Jun 14, 2019 at 12:57 PM Erik Joelsson mailto:erik.joels...@oracle.com>> wrote: Hello Martin, It is intentional. The extra number is our internal CI build number. From JDK 14 we have decided to stop rebuilding for promotion and instead use a build already built and tested in our CI. The new number is part of the $OPT string as defined in JEP-223 [1]. "$OPT, matching|([-a-zA-Z0-9\.]+)|--- Additional build information, if desired.In the case of an|internal|build this will often contain the date and time of the build." Note that the addition of this particular number is only done on builds published by Oracle. Other publishers of OpenJDK binaries are free to add their additional information in that string, and AFAIK it's common practice to do so. /Erik [1] https://openjdk.java.net/jeps/223 On 2019-06-14 12:25, Martin Buchholz wrote: The first jdk14 build reports: openjdk full version "14-ea+1-1" while jdk13 has: openjdk full version "13-ea+25" The trailing "-1" looks like a bug - is it intentional?
Re: jdk 14 version string scheme changed?
Thanks! (OPT is harder to parse out than I expected ...) On Fri, Jun 14, 2019 at 12:57 PM Erik Joelsson wrote: > Hello Martin, > > It is intentional. The extra number is our internal CI build number. From > JDK 14 we have decided to stop rebuilding for promotion and instead use a > build already built and tested in our CI. > > The new number is part of the $OPT string as defined in JEP-223 [1]. > > "$OPT, matching ([-a-zA-Z0-9\.]+) --- Additional build information, if > desired. In the case of an internal build this will often contain the > date and time of the build." > > Note that the addition of this particular number is only done on builds > published by Oracle. Other publishers of OpenJDK binaries are free to add > their additional information in that string, and AFAIK it's common practice > to do so. > > /Erik > > [1] https://openjdk.java.net/jeps/223 > On 2019-06-14 12:25, Martin Buchholz wrote: > > The first jdk14 build reports: > openjdk full version "14-ea+1-1" > while jdk13 has: > openjdk full version "13-ea+25" > > The trailing "-1" looks like a bug - is it intentional? > >
Re: jdk 14 version string scheme changed?
Hello Martin, It is intentional. The extra number is our internal CI build number. From JDK 14 we have decided to stop rebuilding for promotion and instead use a build already built and tested in our CI. The new number is part of the $OPT string as defined in JEP-223 [1]. "$OPT, matching|([-a-zA-Z0-9\.]+)|--- Additional build information, if desired.In the case of an|internal|build this will often contain the date and time of the build." Note that the addition of this particular number is only done on builds published by Oracle. Other publishers of OpenJDK binaries are free to add their additional information in that string, and AFAIK it's common practice to do so. /Erik [1] https://openjdk.java.net/jeps/223 On 2019-06-14 12:25, Martin Buchholz wrote: The first jdk14 build reports: openjdk full version "14-ea+1-1" while jdk13 has: openjdk full version "13-ea+25" The trailing "-1" looks like a bug - is it intentional?
jdk 14 version string scheme changed?
The first jdk14 build reports: openjdk full version "14-ea+1-1" while jdk13 has: openjdk full version "13-ea+25" The trailing "-1" looks like a bug - is it intentional?
Re: [13] RFR: JDK-8225392: Comparison builds are failing due to cacerts file
I'm happy with this. /Erik On 2019-06-14 08:33, Weijun Wang wrote: Here is the updated webrev http://cr.openjdk.java.net/~weijun/8225392/webrev.01/ The only change is ordering in 'keytool -list' and its test. Thanks, Max On Jun 14, 2019, at 7:55 PM, Sean Mullan wrote: On 6/14/19 1:49 AM, Weijun Wang wrote: BTW, something not related but similar: Do you like me to also sort aliases alphabetically in the output of "keytool -list"? Yes, I think that is useful. --Sean
[13] RFR: JDK-8225392: Comparison builds are failing due to cacerts file
Here is the updated webrev http://cr.openjdk.java.net/~weijun/8225392/webrev.01/ The only change is ordering in 'keytool -list' and its test. Thanks, Max > On Jun 14, 2019, at 7:55 PM, Sean Mullan wrote: > > On 6/14/19 1:49 AM, Weijun Wang wrote: >> BTW, something not related but similar: Do you like me to also sort aliases >> alphabetically in the output of "keytool -list"? > > Yes, I think that is useful. > > --Sean
Re: RFR: JDK-8225392: Comparison builds are failing due to cacerts file
On 6/14/19 1:49 AM, Weijun Wang wrote: BTW, something not related but similar: Do you like me to also sort aliases alphabetically in the output of "keytool -list"? Yes, I think that is useful. --Sean
