From garydgregory at gmail.com Thu Jul 14 18:26:28 2016 From: garydgregory at gmail.com (Gary Gregory) Date: Thu, 14 Jul 2016 11:26:28 -0700 Subject: Runtime.Version Message-ID: Hello, Is it java.lang.Runtime.Version instead of just java.lang.Version because the class is meant to be JRE specific? Or could there be any consideration to having a java.lang.Version as a more generally useful class for developers to describe versions of objects that are not Java Runtime things, like a document or specification version, a version of anything really. Thank you, Gary -- E-Mail: garydgregory at gmail.com | ggregory at apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory From pbenedict at apache.org Mon Jul 18 15:01:32 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 18 Jul 2016 10:01:32 -0500 Subject: Backward compatibility / Version Concern Message-ID: Hello! I have a concern and a question. With JDK 9 reporting itself with 9.x.y.z, it seems some very old yet still regarded libraries are going to be tripped up. For example, Apache Log4J 1.x and Apache Commons Lang, have both assumed the 1.x format [1]. The most unfortunate case, however, is Log4J 1.x because it is no longer an actively maintained library and has gone EOL over a year go [2]. As a consequence, for maintainers of systems where Log4J 1.x is deeply embedded, they will have to upgrade to 2.x -- if possible [3]. I say "if possible" because sometimes the choice of a logging framework is not optional. It may either be mandated by policy or embedded into the use of some third-party framework the system cannot afford to replace. For anyone Oracle people reading this, you should know that Log4J 1.x is a pretty important library. Actually, it is so important that the removal of some internal Java API was reverted in Java 7 until a suitable public API was exposed in Java 8 [4]. In my opinion, the change of the version string is going to negatively impact old libraries and thus legacy systems. I don't see an easy upgrade path for these people with JDK 9. I'd like to propose a new -X switch to restore the "1.9.0" version string that's reported at runtime. It's my belief that an "escape hatch" should be provided as an emergency/stop-gap because I think too many systems may be negatively affected and caught off-guard by the new format. What are your thoughts? [1] https://lists.apache.org/thread.html/5d1d08cc1bbdf4bff318ebd2e4d4f54c91b28c533eb11e33b9c978ac@%3Cdev.commons.apache.org%3E [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008668.html [3] https://blogs.apache.org/logging/entry/moving_on_to_log4j_2 [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019334.html Cheers, Paul From volker.simonis at gmail.com Tue Jul 19 08:25:36 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 19 Jul 2016 10:25:36 +0200 Subject: Backward compatibility / Version Concern In-Reply-To: References: Message-ID: Hi Paul, good to see that somebody is finally really testing the full new version schema "9.x.y.z" and not just the shorthand version "9". Which version information is being used by Log4J? The one printed on the command line or one of the various versions strings which are stored in the system properties: java.specification.version = 9.0.0.1 java.version = 9.0.0.1-internal java.vm.specification.version = 9 java.vm.version = 9.0.0.1-internal+0-2016-07-14-165000.d046063.jdk9-dev For java.specification.version there's still the chance that this gets fixed by [1]. Building an old style version string from the new versioning scheme is a little hard as there's no one-to-one mapping. But maybe we can have an -X options which allows the user to set an arbitrary version number? Regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-8149519 On Mon, Jul 18, 2016 at 5:01 PM, Paul Benedict wrote: > Hello! I have a concern and a question. > > With JDK 9 reporting itself with 9.x.y.z, it seems some very old yet still > regarded libraries are going to be tripped up. For example, Apache Log4J > 1.x and Apache Commons Lang, have both assumed the 1.x format [1]. The most > unfortunate case, however, is Log4J 1.x because it is no longer an actively > maintained library and has gone EOL over a year go [2]. As a consequence, > for maintainers of systems where Log4J 1.x is deeply embedded, they will > have to upgrade to 2.x -- if possible [3]. I say "if possible" because > sometimes the choice of a logging framework is not optional. It may either > be mandated by policy or embedded into the use of some third-party > framework the system cannot afford to replace. > > For anyone Oracle people reading this, you should know that Log4J 1.x is a > pretty important library. Actually, it is so important that the removal of > some internal Java API was reverted in Java 7 until a suitable public API > was exposed in Java 8 [4]. > > In my opinion, the change of the version string is going to negatively > impact old libraries and thus legacy systems. I don't see an easy upgrade > path for these people with JDK 9. > > I'd like to propose a new -X switch to restore the "1.9.0" version string > that's reported at runtime. It's my belief that an "escape hatch" should be > provided as an emergency/stop-gap because I think too many systems may be > negatively affected and caught off-guard by the new format. > > What are your thoughts? > > [1] > https://lists.apache.org/thread.html/5d1d08cc1bbdf4bff318ebd2e4d4f54c91b28c533eb11e33b9c978ac@%3Cdev.commons.apache.org%3E > [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008668.html > [3] https://blogs.apache.org/logging/entry/moving_on_to_log4j_2 > [4] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019334.html > > Cheers, > Paul From daniil.x.titov at oracle.com Thu Jul 21 16:39:01 2016 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 21 Jul 2016 09:39:01 -0700 (PDT) Subject: The specification version for 9.1 updates Message-ID: <82c38a5b-1039-4294-93b6-08752d3df890@default> Hello, Per http://openjdk.java.net/jeps/223 "The major version number, incremented for a major release that contains significant new features as specified in a new edition of the Java SE Platform Specification" so $MINOR should not be part of the specification version. At the same time trying the build 9.1.1 (produced with following additional arguments passed to configure: "--with-version-pre= --with-version-major=9 --with-version-minor=1 --with-version-security=1 --with-version-opt=") and dumping system properties shows that "java.specification.version = 9.1.1" while "java.vm.specification.version = 9" Am I right that the specification version for 9.1 should still be 9? Thanks! Best regards, Daniil From iris.clark at oracle.com Thu Jul 21 18:23:30 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 21 Jul 2016 11:23:30 -0700 (PDT) Subject: The specification version for 9.1 updates In-Reply-To: <82c38a5b-1039-4294-93b6-08752d3df890@default> References: <82c38a5b-1039-4294-93b6-08752d3df890@default> Message-ID: <5d400390-e460-436b-9ea9-47bd36fb6a3f@default> Hi, Daniil. You're observing the following bug: 8149519: Investigate implementation of java.specification.verison https://bugs.openjdk.java.net/browse/JDK-8149519 (The summary should probably be changed to more accurately describe the problem.) I'm trying to get back to this bug, but the key point is that value of this system property is determined by JCP activity (e.g. a Maintenance Release), not the version of the JDK. > Am I right that the specification version for 9.1 should still be 9? Yes. The value will remain "9" at least until the first MR for JSR 379 (Java SE 9 Release Contents). Thanks, iris -----Original Message----- From: Daniil Titov Sent: Thursday, July 21, 2016 9:39 AM To: verona-dev at openjdk.java.net Subject: The specification version for 9.1 updates Hello, Per http://openjdk.java.net/jeps/223 "The major version number, incremented for a major release that contains significant new features as specified in a new edition of the Java SE Platform Specification" so $MINOR should not be part of the specification version. At the same time trying the build 9.1.1 (produced with following additional arguments passed to configure: "--with-version-pre= --with-version-major=9 --with-version-minor=1 --with-version-security=1 --with-version-opt=") and dumping system properties shows that "java.specification.version = 9.1.1" while "java.vm.specification.version = 9" Am I right that the specification version for 9.1 should still be 9? Thanks! Best regards, Daniil From daniil.x.titov at oracle.com Thu Jul 21 19:12:30 2016 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 21 Jul 2016 12:12:30 -0700 (PDT) Subject: The specification version for 9.1 updates In-Reply-To: <5d400390-e460-436b-9ea9-47bd36fb6a3f@default> References: <82c38a5b-1039-4294-93b6-08752d3df890@default> <5d400390-e460-436b-9ea9-47bd36fb6a3f@default> Message-ID: <022043b1-bed2-4655-af3e-459ebe3528d3@default> Thank you, Iris! Best regards, Daniil -----Original Message----- From: Iris Clark Sent: Thursday, July 21, 2016 11:24 AM To: Daniil Titov; verona-dev at openjdk.java.net Cc: Iris Clark Subject: RE: The specification version for 9.1 updates Hi, Daniil. You're observing the following bug: 8149519: Investigate implementation of java.specification.verison https://bugs.openjdk.java.net/browse/JDK-8149519 (The summary should probably be changed to more accurately describe the problem.) I'm trying to get back to this bug, but the key point is that value of this system property is determined by JCP activity (e.g. a Maintenance Release), not the version of the JDK. > Am I right that the specification version for 9.1 should still be 9? Yes. The value will remain "9" at least until the first MR for JSR 379 (Java SE 9 Release Contents). Thanks, iris -----Original Message----- From: Daniil Titov Sent: Thursday, July 21, 2016 9:39 AM To: verona-dev at openjdk.java.net Subject: The specification version for 9.1 updates Hello, Per http://openjdk.java.net/jeps/223 "The major version number, incremented for a major release that contains significant new features as specified in a new edition of the Java SE Platform Specification" so $MINOR should not be part of the specification version. At the same time trying the build 9.1.1 (produced with following additional arguments passed to configure: "--with-version-pre= --with-version-major=9 --with-version-minor=1 --with-version-security=1 --with-version-opt=") and dumping system properties shows that "java.specification.version = 9.1.1" while "java.vm.specification.version = 9" Am I right that the specification version for 9.1 should still be 9? Thanks! Best regards, Daniil From volker.simonis at gmail.com Fri Jul 22 09:31:41 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Jul 2016 11:31:41 +0200 Subject: The specification version for 9.1 updates In-Reply-To: <5d400390-e460-436b-9ea9-47bd36fb6a3f@default> References: <82c38a5b-1039-4294-93b6-08752d3df890@default> <5d400390-e460-436b-9ea9-47bd36fb6a3f@default> Message-ID: Hi Daniil, glad to see that somebody else it at least realizing this problem :) I'm assigned to this bug. I have a webrev out for review since April [1]. Last time I pinged the mailing list was in June [2]. Unfortunately nobody seems to be interested in fixing this. I think my proposed fix (see http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519/) is trivial and straightforward so I don't understand what's the problem with it. Regards, Volker [1] http://mail.openjdk.java.net/pipermail/verona-dev/2016-April/thread.html#393 [2] http://mail.openjdk.java.net/pipermail/verona-dev/2016-June/000420.html On Thu, Jul 21, 2016 at 8:23 PM, Iris Clark wrote: > Hi, Daniil. > > You're observing the following bug: > > 8149519: Investigate implementation of java.specification.verison > https://bugs.openjdk.java.net/browse/JDK-8149519 > > (The summary should probably be changed to more accurately describe the problem.) > > I'm trying to get back to this bug, but the key point is that value of this system property is determined by JCP activity (e.g. a Maintenance Release), not the version of the JDK. > >> Am I right that the specification version for 9.1 should still be 9? > > Yes. The value will remain "9" at least until the first MR for JSR 379 (Java SE 9 Release Contents). > > Thanks, > iris > > -----Original Message----- > From: Daniil Titov > Sent: Thursday, July 21, 2016 9:39 AM > To: verona-dev at openjdk.java.net > Subject: The specification version for 9.1 updates > > Hello, > > > > Per http://openjdk.java.net/jeps/223 "The major version number, incremented for a major release that contains significant new features as specified in a new edition of the Java SE Platform Specification" so $MINOR should not be part of the specification version. > > > > At the same time trying the build 9.1.1 (produced with following additional arguments passed to configure: > > "--with-version-pre= --with-version-major=9 --with-version-minor=1 --with-version-security=1 --with-version-opt=") and dumping system properties shows that "java.specification.version = 9.1.1" while "java.vm.specification.version = 9" > > > > Am I right that the specification version for 9.1 should still be 9? > > > > Thanks! > > > > Best regards, > > Daniil > > From david.dehaven at oracle.com Fri Jul 22 15:28:31 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 22 Jul 2016 08:28:31 -0700 Subject: The specification version for 9.1 updates In-Reply-To: References: <82c38a5b-1039-4294-93b6-08752d3df890@default> <5d400390-e460-436b-9ea9-47bd36fb6a3f@default> Message-ID: It's impacting deployment. JNLP treats versioned java/j2se tags with no href attributes as Java specification versions so matching on specification is behaving badly at the moment. -DrD- > Hi Daniil, > > glad to see that somebody else it at least realizing this problem :) > > I'm assigned to this bug. I have a webrev out for review since April > [1]. Last time I pinged the mailing list was in June [2]. > Unfortunately nobody seems to be interested in fixing this. > > I think my proposed fix (see > http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519/) is trivial > and straightforward so I don't understand what's the problem with it. > > Regards, > Volker > > [1] http://mail.openjdk.java.net/pipermail/verona-dev/2016-April/thread.html#393 > [2] http://mail.openjdk.java.net/pipermail/verona-dev/2016-June/000420.html > > > On Thu, Jul 21, 2016 at 8:23 PM, Iris Clark wrote: >> Hi, Daniil. >> >> You're observing the following bug: >> >> 8149519: Investigate implementation of java.specification.verison >> https://bugs.openjdk.java.net/browse/JDK-8149519 >> >> (The summary should probably be changed to more accurately describe the problem.) >> >> I'm trying to get back to this bug, but the key point is that value of this system property is determined by JCP activity (e.g. a Maintenance Release), not the version of the JDK. >> >>> Am I right that the specification version for 9.1 should still be 9? >> >> Yes. The value will remain "9" at least until the first MR for JSR 379 (Java SE 9 Release Contents). >> >> Thanks, >> iris >> >> -----Original Message----- >> From: Daniil Titov >> Sent: Thursday, July 21, 2016 9:39 AM >> To: verona-dev at openjdk.java.net >> Subject: The specification version for 9.1 updates >> >> Hello, >> >> >> >> Per http://openjdk.java.net/jeps/223 "The major version number, incremented for a major release that contains significant new features as specified in a new edition of the Java SE Platform Specification" so $MINOR should not be part of the specification version. >> >> >> >> At the same time trying the build 9.1.1 (produced with following additional arguments passed to configure: >> >> "--with-version-pre= --with-version-major=9 --with-version-minor=1 --with-version-security=1 --with-version-opt=") and dumping system properties shows that "java.specification.version = 9.1.1" while "java.vm.specification.version = 9" >> >> >> >> Am I right that the specification version for 9.1 should still be 9? >> >> >> >> Thanks! >> >> >> >> Best regards, >> >> Daniil >> >> From alejandro.murillo at oracle.com Fri Jul 22 18:17:09 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Fri, 22 Jul 2016 12:17:09 -0600 Subject: The specification version for 9.1 updates In-Reply-To: References: <82c38a5b-1039-4294-93b6-08752d3df890@default> <5d400390-e460-436b-9ea9-47bd36fb6a3f@default> Message-ID: <2b32a12a-e13c-43b6-cf0e-24b90b9d3bca@oracle.com> Hi Volker, Changes like this, although related to Verona, should be reviewed as any other regular fix going into jdk9/dev, so the RFR for this should be sent to the appropriate alias, this one should probably go to build-dev at openjdk Alejandro On 7/22/2016 3:31 AM, Volker Simonis wrote: > Hi Daniil, > > glad to see that somebody else it at least realizing this problem :) > > I'm assigned to this bug. I have a webrev out for review since April > [1]. Last time I pinged the mailing list was in June [2]. > Unfortunately nobody seems to be interested in fixing this. > > I think my proposed fix (see > http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519/) is trivial > and straightforward so I don't understand what's the problem with it. > > Regards, > Volker > > [1] http://mail.openjdk.java.net/pipermail/verona-dev/2016-April/thread.html#393 > [2] http://mail.openjdk.java.net/pipermail/verona-dev/2016-June/000420.html > > > On Thu, Jul 21, 2016 at 8:23 PM, Iris Clark wrote: >> Hi, Daniil. >> >> You're observing the following bug: >> >> 8149519: Investigate implementation of java.specification.verison >> https://bugs.openjdk.java.net/browse/JDK-8149519 >> >> (The summary should probably be changed to more accurately describe the problem.) >> >> I'm trying to get back to this bug, but the key point is that value of this system property is determined by JCP activity (e.g. a Maintenance Release), not the version of the JDK. >> >>> Am I right that the specification version for 9.1 should still be 9? >> Yes. The value will remain "9" at least until the first MR for JSR 379 (Java SE 9 Release Contents). >> >> Thanks, >> iris >> >> -----Original Message----- >> From: Daniil Titov >> Sent: Thursday, July 21, 2016 9:39 AM >> To: verona-dev at openjdk.java.net >> Subject: The specification version for 9.1 updates >> >> Hello, >> >> >> >> Per http://openjdk.java.net/jeps/223 "The major version number, incremented for a major release that contains significant new features as specified in a new edition of the Java SE Platform Specification" so $MINOR should not be part of the specification version. >> >> >> >> At the same time trying the build 9.1.1 (produced with following additional arguments passed to configure: >> >> "--with-version-pre= --with-version-major=9 --with-version-minor=1 --with-version-security=1 --with-version-opt=") and dumping system properties shows that "java.specification.version = 9.1.1" while "java.vm.specification.version = 9" >> >> >> >> Am I right that the specification version for 9.1 should still be 9? >> >> >> >> Thanks! >> >> >> >> Best regards, >> >> Daniil >> >> -- Alejandro From volker.simonis at gmail.com Tue Jul 26 12:22:30 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Jul 2016 14:22:30 +0200 Subject: The specification version for 9.1 updates In-Reply-To: <2b32a12a-e13c-43b6-cf0e-24b90b9d3bca@oracle.com> References: <82c38a5b-1039-4294-93b6-08752d3df890@default> <5d400390-e460-436b-9ea9-47bd36fb6a3f@default> <2b32a12a-e13c-43b6-cf0e-24b90b9d3bca@oracle.com> Message-ID: The initial RFR has been sent to both: verona-dev and core-libs-dev without any outcome. I've now forwarded it to build-dev as well. Maybe the reviewers will be more responsive there :) Thanks, Volker On Fri, Jul 22, 2016 at 8:17 PM, Alejandro Murillo wrote: > > Hi Volker, > Changes like this, although related to Verona, > should be reviewed as any other regular fix going into jdk9/dev, > so the RFR for this should be sent to the appropriate alias, > this one should probably go to build-dev at openjdk > > Alejandro > > > On 7/22/2016 3:31 AM, Volker Simonis wrote: >> >> Hi Daniil, >> >> glad to see that somebody else it at least realizing this problem :) >> >> I'm assigned to this bug. I have a webrev out for review since April >> [1]. Last time I pinged the mailing list was in June [2]. >> Unfortunately nobody seems to be interested in fixing this. >> >> I think my proposed fix (see >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519/) is trivial >> and straightforward so I don't understand what's the problem with it. >> >> Regards, >> Volker >> >> [1] >> http://mail.openjdk.java.net/pipermail/verona-dev/2016-April/thread.html#393 >> [2] >> http://mail.openjdk.java.net/pipermail/verona-dev/2016-June/000420.html >> >> >> On Thu, Jul 21, 2016 at 8:23 PM, Iris Clark wrote: >>> >>> Hi, Daniil. >>> >>> You're observing the following bug: >>> >>> 8149519: Investigate implementation of java.specification.verison >>> https://bugs.openjdk.java.net/browse/JDK-8149519 >>> >>> (The summary should probably be changed to more accurately describe the >>> problem.) >>> >>> I'm trying to get back to this bug, but the key point is that value of >>> this system property is determined by JCP activity (e.g. a Maintenance >>> Release), not the version of the JDK. >>> >>>> Am I right that the specification version for 9.1 should still be 9? >>> >>> Yes. The value will remain "9" at least until the first MR for JSR 379 >>> (Java SE 9 Release Contents). >>> >>> Thanks, >>> iris >>> >>> -----Original Message----- >>> From: Daniil Titov >>> Sent: Thursday, July 21, 2016 9:39 AM >>> To: verona-dev at openjdk.java.net >>> Subject: The specification version for 9.1 updates >>> >>> Hello, >>> >>> >>> >>> Per http://openjdk.java.net/jeps/223 "The major version number, >>> incremented for a major release that contains significant new features as >>> specified in a new edition of the Java SE Platform Specification" so $MINOR >>> should not be part of the specification version. >>> >>> >>> >>> At the same time trying the build 9.1.1 (produced with following >>> additional arguments passed to configure: >>> >>> "--with-version-pre= --with-version-major=9 --with-version-minor=1 >>> --with-version-security=1 --with-version-opt=") and dumping system >>> properties shows that "java.specification.version = 9.1.1" while >>> "java.vm.specification.version = 9" >>> >>> >>> >>> Am I right that the specification version for 9.1 should still be 9? >>> >>> >>> >>> Thanks! >>> >>> >>> >>> Best regards, >>> >>> Daniil >>> >>> > > -- > Alejandro > From Alan.Bateman at oracle.com Tue Jul 26 12:26:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Jul 2016 13:26:45 +0100 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: This looks right but I'm curious why it was initially implemented to use VERSION_NUMBER. -Alan On 26/07/2016 13:20, Volker Simonis wrote: > Forwarding to build-dev in the hope to get a review there :) > More details can be found in the bug description. > > Thank you and best regards, > Volker > > > ---------- Forwarded message ---------- > From: Volker Simonis > Date: Mon, Apr 4, 2016 at 6:47 PM > Subject: RFR(XXS): 8149519: Investigate implementation of > java.specification.version > To: Java Core Libs > Cc: verona-dev at openjdk.java.net > > > Hi, > > can I please have a review for this small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 > https://bugs.openjdk.java.net/browse/JDK-8149519 > > Currently the value of the java.specification.version property comes > from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is > currently set to VERSION_NUMBER which is the same value which is also > used for the java.version property. > > This is a bad idea, because VERSION_NUMBER is a dot separated sequence > of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. > for every build and/or update version). If we are configuring with > "--with-version-patch=1" for example, VERSION_NUMBER and java.version > will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION > and java.specification.version have the same, dotted value. And it > breaks a lot of legacy applications which parse > java.specification.version as a float number. That code would still > work if java.specification.version would be a concrete number (e.g. > '9' or '10'). > > I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in > common/autoconf/spec.gmk.in. This should be the "right value" until we > get a specification change during a major release which hasn't > happened for quite some time now. > > Regards, > Volker From volker.simonis at gmail.com Tue Jul 26 17:20:19 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Jul 2016 19:20:19 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: On Tue, Jul 26, 2016 at 2:26 PM, Alan Bateman wrote: > This looks right Thanks! > but I'm curious why it was initially implemented to use VERSION_NUMBER. Probably because until now VERSION_NUMBER == VERSION_MAJOR == 9? > > -Alan > > > > On 26/07/2016 13:20, Volker Simonis wrote: > >> Forwarding to build-dev in the hope to get a review there :) >> More details can be found in the bug description. >> >> Thank you and best regards, >> Volker >> >> >> ---------- Forwarded message ---------- >> From: Volker Simonis >> Date: Mon, Apr 4, 2016 at 6:47 PM >> Subject: RFR(XXS): 8149519: Investigate implementation of >> java.specification.version >> To: Java Core Libs >> Cc: verona-dev at openjdk.java.net >> >> >> Hi, >> >> can I please have a review for this small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >> https://bugs.openjdk.java.net/browse/JDK-8149519 >> >> Currently the value of the java.specification.version property comes >> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >> currently set to VERSION_NUMBER which is the same value which is also >> used for the java.version property. >> >> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >> for every build and/or update version). If we are configuring with >> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >> and java.specification.version have the same, dotted value. And it >> breaks a lot of legacy applications which parse >> java.specification.version as a float number. That code would still >> work if java.specification.version would be a concrete number (e.g. >> '9' or '10'). >> >> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >> common/autoconf/spec.gmk.in. This should be the "right value" until we >> get a specification change during a major release which hasn't >> happened for quite some time now. >> >> Regards, >> Volker > > From david.holmes at oracle.com Wed Jul 27 02:22:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jul 2016 12:22:52 +1000 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: +1 from me. Does the Verona JEP say anything about this? I certainly do not expect the specification version number of differ from the major release number. David On 26/07/2016 10:26 PM, Alan Bateman wrote: > This looks right but I'm curious why it was initially implemented to use > VERSION_NUMBER. > > -Alan > > > On 26/07/2016 13:20, Volker Simonis wrote: > >> Forwarding to build-dev in the hope to get a review there :) >> More details can be found in the bug description. >> >> Thank you and best regards, >> Volker >> >> >> ---------- Forwarded message ---------- >> From: Volker Simonis >> Date: Mon, Apr 4, 2016 at 6:47 PM >> Subject: RFR(XXS): 8149519: Investigate implementation of >> java.specification.version >> To: Java Core Libs >> Cc: verona-dev at openjdk.java.net >> >> >> Hi, >> >> can I please have a review for this small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >> https://bugs.openjdk.java.net/browse/JDK-8149519 >> >> Currently the value of the java.specification.version property comes >> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >> currently set to VERSION_NUMBER which is the same value which is also >> used for the java.version property. >> >> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >> for every build and/or update version). If we are configuring with >> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >> and java.specification.version have the same, dotted value. And it >> breaks a lot of legacy applications which parse >> java.specification.version as a float number. That code would still >> work if java.specification.version would be a concrete number (e.g. >> '9' or '10'). >> >> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >> common/autoconf/spec.gmk.in. This should be the "right value" until we >> get a specification change during a major release which hasn't >> happened for quite some time now. >> >> Regards, >> Volker > From magnus.ihse.bursie at oracle.com Thu Jul 28 21:30:19 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 28 Jul 2016 23:30:19 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: Some background on this: I initially introduced VERSION_SPECIFICATION as VERSION_MAJOR but had to revert it in the Verona branch since I was told that the specification number should be identical to the release version. My initial reaction was the same as yours, that the specification would match only the major part. I see now that Iris support this change, so I hope the old rationale for having the specification in lockstep with the release is no longer valid. /Magnus > 26 juli 2016 kl. 14:26 skrev Alan Bateman : > > This looks right but I'm curious why it was initially implemented to use VERSION_NUMBER. > > -Alan > > >> On 26/07/2016 13:20, Volker Simonis wrote: >> >> Forwarding to build-dev in the hope to get a review there :) >> More details can be found in the bug description. >> >> Thank you and best regards, >> Volker >> >> >> ---------- Forwarded message ---------- >> From: Volker Simonis >> Date: Mon, Apr 4, 2016 at 6:47 PM >> Subject: RFR(XXS): 8149519: Investigate implementation of >> java.specification.version >> To: Java Core Libs >> Cc: verona-dev at openjdk.java.net >> >> >> Hi, >> >> can I please have a review for this small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >> https://bugs.openjdk.java.net/browse/JDK-8149519 >> >> Currently the value of the java.specification.version property comes >> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >> currently set to VERSION_NUMBER which is the same value which is also >> used for the java.version property. >> >> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >> for every build and/or update version). If we are configuring with >> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >> and java.specification.version have the same, dotted value. And it >> breaks a lot of legacy applications which parse >> java.specification.version as a float number. That code would still >> work if java.specification.version would be a concrete number (e.g. >> '9' or '10'). >> >> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >> common/autoconf/spec.gmk.in. This should be the "right value" until we >> get a specification change during a major release which hasn't >> happened for quite some time now. >> >> Regards, >> Volker > From volker.simonis at gmail.com Fri Jul 29 17:42:12 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 Jul 2016 19:42:12 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: Hi Magnus, thanks for the background information! It's always the smallest issues which take the most time and the longest discussions. I'm just happy that we have no line-endings in the version string :) Regards, Volker On Thu, Jul 28, 2016 at 11:30 PM, Magnus Ihse Bursie wrote: > Some background on this: > > I initially introduced VERSION_SPECIFICATION as VERSION_MAJOR but had to revert it in the Verona branch since I was told that the specification number should be identical to the release version. My initial reaction was the same as yours, that the specification would match only the major part. > > I see now that Iris support this change, so I hope the old rationale for having the specification in lockstep with the release is no longer valid. > > /Magnus > >> 26 juli 2016 kl. 14:26 skrev Alan Bateman : >> >> This looks right but I'm curious why it was initially implemented to use VERSION_NUMBER. >> >> -Alan >> >> >>> On 26/07/2016 13:20, Volker Simonis wrote: >>> >>> Forwarding to build-dev in the hope to get a review there :) >>> More details can be found in the bug description. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> ---------- Forwarded message ---------- >>> From: Volker Simonis >>> Date: Mon, Apr 4, 2016 at 6:47 PM >>> Subject: RFR(XXS): 8149519: Investigate implementation of >>> java.specification.version >>> To: Java Core Libs >>> Cc: verona-dev at openjdk.java.net >>> >>> >>> Hi, >>> >>> can I please have a review for this small fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >>> https://bugs.openjdk.java.net/browse/JDK-8149519 >>> >>> Currently the value of the java.specification.version property comes >>> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >>> currently set to VERSION_NUMBER which is the same value which is also >>> used for the java.version property. >>> >>> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >>> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >>> for every build and/or update version). If we are configuring with >>> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >>> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >>> and java.specification.version have the same, dotted value. And it >>> breaks a lot of legacy applications which parse >>> java.specification.version as a float number. That code would still >>> work if java.specification.version would be a concrete number (e.g. >>> '9' or '10'). >>> >>> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >>> common/autoconf/spec.gmk.in. This should be the "right value" until we >>> get a specification change during a major release which hasn't >>> happened for quite some time now. >>> >>> Regards, >>> Volker >> From volker.simonis at gmail.com Fri Jul 29 17:42:50 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 Jul 2016 19:42:50 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: Thanks, David! On Wed, Jul 27, 2016 at 4:22 AM, David Holmes wrote: > +1 from me. Does the Verona JEP say anything about this? I certainly do not > expect the specification version number of differ from the major release > number. > > David > > > On 26/07/2016 10:26 PM, Alan Bateman wrote: >> >> This looks right but I'm curious why it was initially implemented to use >> VERSION_NUMBER. >> >> -Alan >> >> >> On 26/07/2016 13:20, Volker Simonis wrote: >> >>> Forwarding to build-dev in the hope to get a review there :) >>> More details can be found in the bug description. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> ---------- Forwarded message ---------- >>> From: Volker Simonis >>> Date: Mon, Apr 4, 2016 at 6:47 PM >>> Subject: RFR(XXS): 8149519: Investigate implementation of >>> java.specification.version >>> To: Java Core Libs >>> Cc: verona-dev at openjdk.java.net >>> >>> >>> Hi, >>> >>> can I please have a review for this small fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >>> https://bugs.openjdk.java.net/browse/JDK-8149519 >>> >>> Currently the value of the java.specification.version property comes >>> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >>> currently set to VERSION_NUMBER which is the same value which is also >>> used for the java.version property. >>> >>> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >>> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >>> for every build and/or update version). If we are configuring with >>> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >>> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >>> and java.specification.version have the same, dotted value. And it >>> breaks a lot of legacy applications which parse >>> java.specification.version as a float number. That code would still >>> work if java.specification.version would be a concrete number (e.g. >>> '9' or '10'). >>> >>> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >>> common/autoconf/spec.gmk.in. This should be the "right value" until we >>> get a specification change during a major release which hasn't >>> happened for quite some time now. >>> >>> Regards, >>> Volker >> >> >