From goetz.lindenmaier at sap.com Mon Apr 1 07:17:44 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 1 Apr 2019 07:17:44 +0000 Subject: Coordinating the build number for 11.0.3 In-Reply-To: <115CADB7-03AE-4DC4-AFAB-C70047D7CCF8@azul.com> References: <115CADB7-03AE-4DC4-AFAB-C70047D7CCF8@azul.com> Message-ID: Hi Gil, I think you can never be sure that you don't need another build. Therefore you can not predict the final build number. See what happened with 11.0.2. I assume Andrew ?? will push a -ga tag with the security changes, so that will be the one to go for. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Gil Tene > Sent: Freitag, 29. M?rz 2019 23:02 > To: jdk-updates-dev at openjdk.java.net > Subject: Coordinating the build number for 11.0.3 > > As we approach the April update and the release of 11.0.3 by the > JDK11u project, I'd like to suggest a coordination of the eventual > build number that we expect to use for the actual released build in > the project (after integration of security fixes that are being worked > on in the dark). > > Since the build number is a part of the versions string per JEP 322, > and since this is the most specific part of the version string that is > common across the various binary distributions (e.g. > Azul Zulu, AdoptOpenJDK, Corretto, Liberica, Red Hat, etc.), it > is useful for us all to use the same build number when we release > the first build of a new update of 11u. This has been the practice in > the past. E.g. for 11.0.2, we all aligned on the same "build 11.0.2+9" > in the version string. > > Since the update itself is time sensitive, and it is useful to commence > testing ahead of time, knowing the build number to use in the builds > we test would be helpful in getting the builds ready to go ASAP once > the release is finalized. > > So, I propose that we pre-choose a build number for the anticipated > April release of 11.0.3. I have no strong opinions on what that number > should be. It should probably not overlap with past or current builds of > 11.0.3 in 11u, and "leaving room" (a gap of a few integer spaces > between the current build numbers and the anticipated one) is probably > a good idea. > > ? Gil. From goetz.lindenmaier at sap.com Mon Apr 1 07:41:22 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 1 Apr 2019 07:41:22 +0000 Subject: Coordinating the build number for 11.0.3 In-Reply-To: References: <115CADB7-03AE-4DC4-AFAB-C70047D7CCF8@azul.com> Message-ID: > So, maybe we can agree that the final build number will always be the publicly > visible build number + 1. Andrew, not knowing your exact processes regarding > the handling of CPU changes, would you think you'd be able to commit to that? I don't think this is a good idea. Either you build directly from the jdk11u repository. If so, wait until the -ga is pushed, and build that. If you build your own repository to decouple from jdk11u in the last days, use your own tags. You can never be sure it's the same, so you should not pretend so. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Samstag, 30. M?rz 2019 20:55 > To: Andrew John Hughes ; jdk-updates- > dev at openjdk.java.net; Gil Tene > Subject: [CAUTION] RE: Coordinating the build number for 11.0.3 > > Hi Gil, Andrew, > > I don't really like the idea to define the exact build number beforehand with > leap space for additional builds. > > However, I can see that it would be helpful for distributions that want to > release a binary right at the release day without waiting for the public release > of the CPU changes, then picking them up, merging, triggering builds and do > regression testing. Doing so will obviously delay the availability of the binaries > and incurs some uncalculatable risk regarding merging and regressions. > > So, maybe we can agree that the final build number will always be the publicly > visible build number + 1. Andrew, not knowing your exact processes regarding > the handling of CPU changes, would you think you'd be able to commit to that? > > Best regards > Christoph > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Andrew John Hughes > > Sent: Samstag, 30. M?rz 2019 03:19 > > To: jdk-updates-dev at openjdk.java.net > > Subject: Re: Coordinating the build number for 11.0.3 > > > > > > > > On 29/03/2019 22:02, Gil Tene wrote: > > > As we approach the April update and the release of 11.0.3 by the > > > JDK11u project, I'd like to suggest a coordination of the eventual > > > build number that we expect to use for the actual released build in > > > the project (after integration of security fixes that are being worked > > > on in the dark). > > > > > > Since the build number is a part of the versions string per JEP 322, > > > and since this is the most specific part of the version string that is > > > common across the various binary distributions (e.g. > > > Azul Zulu, AdoptOpenJDK, Corretto, Liberica, Red Hat, etc.), it > > > is useful for us all to use the same build number when we release > > > the first build of a new update of 11u. This has been the practice in > > > the past. E.g. for 11.0.2, we all aligned on the same "build 11.0.2+9" > > > in the version string. > > > > > > Since the update itself is time sensitive, and it is useful to commence > > > testing ahead of time, knowing the build number to use in the builds > > > we test would be helpful in getting the builds ready to go ASAP once > > > the release is finalized. > > > > > > So, I propose that we pre-choose a build number for the anticipated > > > April release of 11.0.3. I have no strong opinions on what that number > > > should be. It should probably not overlap with past or current builds of > > > 11.0.3 in 11u, and "leaving room" (a gap of a few integer spaces > > > between the current build numbers and the anticipated one) is probably > > > a good idea. > > > > > > ? Gil. > > > > > > > Well, it's already at 5: > > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe > > > > So I would expect the CPU additions to make it 6, but it may have to go > > higher if issues arise. > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > https://keybase.io/gnu_andrew From doko at ubuntu.com Mon Apr 1 09:24:58 2019 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 1 Apr 2019 11:24:58 +0200 Subject: Coordinating the build number for 11.0.3 In-Reply-To: References: <115CADB7-03AE-4DC4-AFAB-C70047D7CCF8@azul.com> Message-ID: On 30.03.19 20:54, Langer, Christoph wrote: > Hi Gil, Andrew, > > I don't really like the idea to define the exact build number beforehand with leap space for additional builds. > > However, I can see that it would be helpful for distributions that want to release a binary right at the release day without waiting for the public release of the CPU changes, then picking them up, merging, triggering builds and do regression testing. Doing so will obviously delay the availability of the binaries and incurs some uncalculatable risk regarding merging and regressions. How important is this? At least for Linux distributions you always have something like -, so you can do multiple builds, and even adding the CPU changes as a bumped distro release version without waiting for the CPU merges. > So, maybe we can agree that the final build number will always be the publicly visible build number + 1. Andrew, not knowing your exact processes regarding the handling of CPU changes, would you think you'd be able to commit to that? > > Best regards > Christoph > > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Andrew John Hughes >> Sent: Samstag, 30. M?rz 2019 03:19 >> To: jdk-updates-dev at openjdk.java.net >> Subject: Re: Coordinating the build number for 11.0.3 >> >> >> >> On 29/03/2019 22:02, Gil Tene wrote: >>> As we approach the April update and the release of 11.0.3 by the >>> JDK11u project, I'd like to suggest a coordination of the eventual >>> build number that we expect to use for the actual released build in >>> the project (after integration of security fixes that are being worked >>> on in the dark). >>> >>> Since the build number is a part of the versions string per JEP 322, >>> and since this is the most specific part of the version string that is >>> common across the various binary distributions (e.g. >>> Azul Zulu, AdoptOpenJDK, Corretto, Liberica, Red Hat, etc.), it >>> is useful for us all to use the same build number when we release >>> the first build of a new update of 11u. This has been the practice in >>> the past. E.g. for 11.0.2, we all aligned on the same "build 11.0.2+9" >>> in the version string. >>> >>> Since the update itself is time sensitive, and it is useful to commence >>> testing ahead of time, knowing the build number to use in the builds >>> we test would be helpful in getting the builds ready to go ASAP once >>> the release is finalized. >>> >>> So, I propose that we pre-choose a build number for the anticipated >>> April release of 11.0.3. I have no strong opinions on what that number >>> should be. It should probably not overlap with past or current builds of >>> 11.0.3 in 11u, and "leaving room" (a gap of a few integer spaces >>> between the current build numbers and the anticipated one) is probably >>> a good idea. >>> >>> ? Gil. >>> >> >> Well, it's already at 5: >> >> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe >> >> So I would expect the CPU additions to make it 6, but it may have to go >> higher if issues arise. >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> https://keybase.io/gnu_andrew > From dalibor.topic at oracle.com Mon Apr 1 13:32:04 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 1 Apr 2019 15:32:04 +0200 Subject: Handling Backport Changesets In-Reply-To: References: Message-ID: <48b692d9-4e07-5524-3919-0a6984c18d9b@oracle.com> Fwiw, JIRA entries for backports record a single Assignee. Quoting from https://wiki.openjdk.java.net/display/general/JBS+Overview "Backports are full issues, but only a few fields are expected to be set: fixVersion: indicates which specific release a backport is targeting or fixed in assignee: holds the engineer responsible for the backport" So my suggestion would be to simply keep that information accurate in JIRA as your 'Backported-by' information, rather than adding a category of metadata to commits. This has a couple of advantages. It's not possible to fix mistakes in commit metadata, for example, while it can be done easily in JIRA. cheers, dalibor topic On 29.03.2019 16:00, Andrew John Hughes wrote: > Just a heads up that I've filed: > > https://bugs.openjdk.java.net/browse/JDK-8221692 > > to try and get backporting formally recognised in changesets, in the > same way as Contributed-by. > > Hopefully, this will resolve the confusion over who to credit for such > changes. > > Thanks, > -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From gil at azul.com Mon Apr 1 15:34:39 2019 From: gil at azul.com (Gil Tene) Date: Mon, 1 Apr 2019 15:34:39 +0000 Subject: Coordinating the build number for 11.0.3 In-Reply-To: References: <115CADB7-03AE-4DC4-AFAB-C70047D7CCF8@azul.com> Message-ID: <5410CFB8-2828-4CD8-8871-76958E87B7F9@azul.com> Sent from my iPad On Apr 1, 2019, at 2:25 AM, Matthias Klose > wrote: > On 30.03.19 20:54, Langer, Christoph wrote: >> Hi Gil, Andrew, >> >> I don't really like the idea to define the exact build number beforehand with leap space for additional builds. >> >> However, I can see that it would be helpful for distributions that want to release a binary right at the release day without waiting for the public release of the CPU changes, then picking them up, merging, triggering builds and do regression testing. Doing so will obviously delay the availability of the binaries and incurs some uncalculatable risk regarding merging and regressions. > > How important is this? At least for Linux distributions you always have > something like -, so you can do > multiple builds, and even adding the CPU changes as a bumped distro release > version without waiting for the CPU merges. Using the ana;ogy above, the build number in e.g. 11.0.2+9 clearly belongs on the equivalent part. There is a completely separate portion of the JEP 322 version string where the different binary builds have been placing the equivalent part, which has room for it's own subversions and build notions. See the below for how the latest 11.0.2 (+9) looks for some common builds (and it looked the same for the initial +7 version that came out as well). Zulu 11: Lumpy.local-37% Contents/Home/bin/java -version openjdk version "11.0.2" 2019-01-15 LTS OpenJDK Runtime Environment Zulu11.29+11-CA (build 11.0.2+9-LTS) OpenJDK 64-Bit Server VM Zulu11.29+11-CA (build 11.0.2+9-LTS, mixed mode) AdoptOpenJDK 11: Lumpy.local-51% Contents/Home/bin/java -version openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.2+9) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.2+9, mixed mode) Cortretto 11: Lumpy.local-63% Contents/Home/bin/java -version openjdk version "11.0.2" 2019-01-15 LTS OpenJDK Runtime Environment Corretto-11.0.2.9.1 (build 11.0.2+9-LTS) OpenJDK 64-Bit Server VM Corretto-11.0.2.9.1 (build 11.0.2+9-LTS, mixed mode) Oracle-built OpenJDK 11 builds: Lumpy.local-41% Contents/Home/bin/java -version openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) > >> So, maybe we can agree that the final build number will always be the publicly visible build number + 1. Andrew, not knowing your exact processes regarding the handling of CPU changes, would you think you'd be able to commit to that? >> >> Best regards >> Christoph >> >> >>> -----Original Message----- >>> From: jdk-updates-dev > On >>> Behalf Of Andrew John Hughes >>> Sent: Samstag, 30. M?rz 2019 03:19 >>> To: jdk-updates-dev at openjdk.java.net >>> Subject: Re: Coordinating the build number for 11.0.3 >>> >>> >>> >>> On 29/03/2019 22:02, Gil Tene wrote: >>>> As we approach the April update and the release of 11.0.3 by the >>>> JDK11u project, I'd like to suggest a coordination of the eventual >>>> build number that we expect to use for the actual released build in >>>> the project (after integration of security fixes that are being worked >>>> on in the dark). >>>> >>>> Since the build number is a part of the versions string per JEP 322, >>>> and since this is the most specific part of the version string that is >>>> common across the various binary distributions (e.g. >>>> Azul Zulu, AdoptOpenJDK, Corretto, Liberica, Red Hat, etc.), it >>>> is useful for us all to use the same build number when we release >>>> the first build of a new update of 11u. This has been the practice in >>>> the past. E.g. for 11.0.2, we all aligned on the same "build 11.0.2+9" >>>> in the version string. >>>> >>>> Since the update itself is time sensitive, and it is useful to commence >>>> testing ahead of time, knowing the build number to use in the builds >>>> we test would be helpful in getting the builds ready to go ASAP once >>>> the release is finalized. >>>> >>>> So, I propose that we pre-choose a build number for the anticipated >>>> April release of 11.0.3. I have no strong opinions on what that number >>>> should be. It should probably not overlap with past or current builds of >>>> 11.0.3 in 11u, and "leaving room" (a gap of a few integer spaces >>>> between the current build numbers and the anticipated one) is probably >>>> a good idea. >>>> >>>> ? Gil. >>>> >>> >>> Well, it's already at 5: >>> >>> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe >>> >>> So I would expect the CPU additions to make it 6, but it may have to go >>> higher if issues arise. >>> -- >>> Andrew :) >>> >>> Senior Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com ) >>> >>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >>> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >>> https://keybase.io/gnu_andrew >> From gil at azul.com Mon Apr 1 15:56:07 2019 From: gil at azul.com (Gil Tene) Date: Mon, 1 Apr 2019 15:56:07 +0000 Subject: Coordinating the build number for 11.0.3 In-Reply-To: References: <115CADB7-03AE-4DC4-AFAB-C70047D7CCF8@azul.com> Message-ID: > On Apr 1, 2019, at 12:17 AM, Lindenmaier, Goetz wrote: > > Hi Gil, > > I think you can never be sure that you don't need another > build. Therefore you can not predict the final build number. > See what happened with 11.0.2. 11.0.2 initially came out with an 11.0.2+7, and later (quickly) updated to 11.0.2+9 (which, ironically, fixed a mistake in the date in version string). I am not expecting coordination to "save" us from a "11.0.2+7 to 11.0.2+9 like", post-initial GA shift, as such a change cannot be foreseen and would require re-testing in any case. But I do want it to allow for a coordinated "11.0.2+7 like" situation, so that tested binaries can be primed to go with our best-guess version string in them. My point is that we can avoid the "guess" part of the best-guess by coordinating the build number that will be used if no additional changes (other than in-the-dark security fix integration) will occur. I think that leaving room for 2-3 additional build numbers [in order to deal with potential for multiple build number increments during the eventual integration of security updates] is one way to do that. Alternately, carefully working to integrate all security updates in a single shot (making sure that the build number only increments by one) is another approach. I'm good with either, I just want a target build number to [speculatively] start tests on, and an understanding that we want to aim for that build number actually being the eventual build number (barring surprises) so that the various binaries can end up with the same "11.0.3+42" part of the version string of all goes well, without having to re-spin and re-test after the upstream gets published. > > I assume Andrew ?? will push a -ga tag with the security > changes, so that will be the one to go for. > > Best regards, > Goetz. > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Gil Tene >> Sent: Freitag, 29. M?rz 2019 23:02 >> To: jdk-updates-dev at openjdk.java.net >> Subject: Coordinating the build number for 11.0.3 >> >> As we approach the April update and the release of 11.0.3 by the >> JDK11u project, I'd like to suggest a coordination of the eventual >> build number that we expect to use for the actual released build in >> the project (after integration of security fixes that are being worked >> on in the dark). >> >> Since the build number is a part of the versions string per JEP 322, >> and since this is the most specific part of the version string that is >> common across the various binary distributions (e.g. >> Azul Zulu, AdoptOpenJDK, Corretto, Liberica, Red Hat, etc.), it >> is useful for us all to use the same build number when we release >> the first build of a new update of 11u. This has been the practice in >> the past. E.g. for 11.0.2, we all aligned on the same "build 11.0.2+9" >> in the version string. >> >> Since the update itself is time sensitive, and it is useful to commence >> testing ahead of time, knowing the build number to use in the builds >> we test would be helpful in getting the builds ready to go ASAP once >> the release is finalized. >> >> So, I propose that we pre-choose a build number for the anticipated >> April release of 11.0.3. I have no strong opinions on what that number >> should be. It should probably not overlap with past or current builds of >> 11.0.3 in 11u, and "leaving room" (a gap of a few integer spaces >> between the current build numbers and the anticipated one) is probably >> a good idea. >> >> ? Gil. From hohensee at amazon.com Mon Apr 1 17:04:46 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 1 Apr 2019 17:04:46 +0000 Subject: Backports to jdk11u are still tagged as 11.0.3 Message-ID: <349A7BDE-CBE1-42BD-B316-743221D63D42@amazon.com> See https://bugs.openjdk.java.net/browse/JDK-8207760 https://bugs.openjdk.java.net/browse/JDK-8221767 We should be tagging them 11.0.4, right? Thanks, Paul From hohensee at amazon.com Mon Apr 1 17:09:06 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 1 Apr 2019 17:09:06 +0000 Subject: Backports to jdk11u are still tagged as 11.0.3 In-Reply-To: <349A7BDE-CBE1-42BD-B316-743221D63D42@amazon.com> References: <349A7BDE-CBE1-42BD-B316-743221D63D42@amazon.com> Message-ID: <94E62DE7-2FE9-47D9-B9A1-BAEF3D795D7C@amazon.com> My bad, I mistakenly pushed to jdk11u rather than jdk11u-dev. I'll revert the push. ?On 4/1/19, 10:05 AM, "jdk-updates-dev on behalf of Hohensee, Paul" wrote: See https://bugs.openjdk.java.net/browse/JDK-8207760 https://bugs.openjdk.java.net/browse/JDK-8221767 We should be tagging them 11.0.4, right? Thanks, Paul From hohensee at amazon.com Mon Apr 1 17:24:40 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 1 Apr 2019 17:24:40 +0000 Subject: Backports to jdk11u are still tagged as 11.0.3 In-Reply-To: <94E62DE7-2FE9-47D9-B9A1-BAEF3D795D7C@amazon.com> References: <349A7BDE-CBE1-42BD-B316-743221D63D42@amazon.com> <94E62DE7-2FE9-47D9-B9A1-BAEF3D795D7C@amazon.com> Message-ID: Reversion JBS issue: https://bugs.openjdk.java.net/browse/JDK-8221769 Reversion webrev: http://cr.openjdk.java.net/~phh/8221769/webrev.00/ Please approve and tag JDK-8221769 jdk11u-fix-yes. Thanks, Paul ?On 4/1/19, 10:10 AM, "jdk-updates-dev on behalf of Hohensee, Paul" wrote: My bad, I mistakenly pushed to jdk11u rather than jdk11u-dev. I'll revert the push. On 4/1/19, 10:05 AM, "jdk-updates-dev on behalf of Hohensee, Paul" wrote: See https://bugs.openjdk.java.net/browse/JDK-8207760 https://bugs.openjdk.java.net/browse/JDK-8221767 We should be tagging them 11.0.4, right? Thanks, Paul From christoph.langer at sap.com Mon Apr 1 20:32:26 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 1 Apr 2019 20:32:26 +0000 Subject: Backports to jdk11u are still tagged as 11.0.3 In-Reply-To: References: <349A7BDE-CBE1-42BD-B316-743221D63D42@amazon.com> <94E62DE7-2FE9-47D9-B9A1-BAEF3D795D7C@amazon.com> Message-ID: Hi Paul, not nice ... but I'm always glad it wasn't me ?? I've added jdk11u-critical-request to the backout bug, which is what's needed for jdk11u push approval, and for the created packport bug I've set the version to 11-pool, so hgupdater will reuse it and set the correct version when you correctly push to jdk11u-dev. Consider the backout change reviewed. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Montag, 1. April 2019 19:25 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: Backports to jdk11u are still tagged as 11.0.3 > > Reversion JBS issue: https://bugs.openjdk.java.net/browse/JDK-8221769 > Reversion webrev: http://cr.openjdk.java.net/~phh/8221769/webrev.00/ > > Please approve and tag JDK-8221769 jdk11u-fix-yes. > > Thanks, > > Paul > > ?On 4/1/19, 10:10 AM, "jdk-updates-dev on behalf of Hohensee, Paul" updates-dev-bounces at openjdk.java.net on behalf of > hohensee at amazon.com> wrote: > > My bad, I mistakenly pushed to jdk11u rather than jdk11u-dev. I'll revert > the push. > > On 4/1/19, 10:05 AM, "jdk-updates-dev on behalf of Hohensee, Paul" updates-dev-bounces at openjdk.java.net on behalf of > hohensee at amazon.com> wrote: > > See > > https://bugs.openjdk.java.net/browse/JDK-8207760 > https://bugs.openjdk.java.net/browse/JDK-8221767 > > We should be tagging them 11.0.4, right? > > Thanks, > > Paul > > > > > From gnu.andrew at redhat.com Tue Apr 2 01:17:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 2 Apr 2019 02:17:30 +0100 Subject: Coordinating the build number for 11.0.3 In-Reply-To: References: <115CADB7-03AE-4DC4-AFAB-C70047D7CCF8@azul.com> Message-ID: On 30/03/2019 19:54, Langer, Christoph wrote: > Hi Gil, Andrew, > > I don't really like the idea to define the exact build number beforehand with leap space for additional builds. > > However, I can see that it would be helpful for distributions that want to release a binary right at the release day without waiting for the public release of the CPU changes, then picking them up, merging, triggering builds and do regression testing. Doing so will obviously delay the availability of the binaries and incurs some uncalculatable risk regarding merging and regressions. > > So, maybe we can agree that the final build number will always be the publicly visible build number + 1. Andrew, not knowing your exact processes regarding the handling of CPU changes, would you think you'd be able to commit to that? > > Best regards > Christoph > > > No. I can guarantee that it won't be lower than that. I don't see that as a problem, as a downstream version that patches ahead of the unembargo will be able to use freeze version + 1, and can sync to any later version once it is made public. Or, as Goetz says, use your own tags. Best regards, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Apr 2 01:22:03 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 2 Apr 2019 02:22:03 +0100 Subject: [FREEZE] 11.0.3 NOW FROZEN Message-ID: The release tree: https://hg.openjdk.java.net/jdk-updates/jdk11u/ is now frozen in preparation for release on 2019-04-16. The final release will be based on 11.0.3+5 [0] and will have a version no lower than 11.0.3+6. There are two changes in the repository after 11.0.3+5 [1] [2]. These changes were not committed until after the agreed deadline of the 1st and so will now have to wait until 11.0.4. I suggest that, in future, we aim to tag the release on the day of the deadline or the last working day before to avoid such confusion. [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Apr 2 01:48:03 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 2 Apr 2019 02:48:03 +0100 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: Message-ID: On 02/04/2019 02:22, Andrew John Hughes wrote: > The release tree: > > https://hg.openjdk.java.net/jdk-updates/jdk11u/ > > is now frozen in preparation for release on 2019-04-16. > > The final release will be based on 11.0.3+5 [0] and will have a version > no lower than 11.0.3+6. > > There are two changes in the repository after 11.0.3+5 [1] [2]. These > changes were not committed until after the agreed deadline of the 1st > and so will now have to wait until 11.0.4. > > I suggest that, in future, we aim to tag the release on the day of the > deadline or the last working day before to avoid such confusion. > > [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe > [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 > Note that the final part of the Japanese era work: https://bugs.openjdk.java.net/browse/JDK-8205432 will be included in the CPU and I'll backport it to the public jdk11u-dev branch so others can include it too. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Tue Apr 2 07:24:13 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Apr 2019 07:24:13 +0000 Subject: Backports to jdk11u are still tagged as 11.0.3 In-Reply-To: <349A7BDE-CBE1-42BD-B316-743221D63D42@amazon.com> References: <349A7BDE-CBE1-42BD-B316-743221D63D42@amazon.com> Message-ID: Hi, we are tagging jdk11u-dev with 11.0.4. We will tag jdk11u with 11.0.3 until after it was released. We will move 11.0.4 to jdk11u around April 30. Then we will start developing 11.0.5 in jdk11u-dev and will stabilize 11.0.4 in jdk11u. Best regards, Goetz > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Montag, 1. April 2019 19:05 > To: jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] Backports to jdk11u are still tagged as 11.0.3 > > See > > https://bugs.openjdk.java.net/browse/JDK-8207760 > https://bugs.openjdk.java.net/browse/JDK-8221767 > > We should be tagging them 11.0.4, right? > > Thanks, > > Paul > From goetz.lindenmaier at sap.com Tue Apr 2 07:38:10 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Apr 2019 07:38:10 +0000 Subject: Timeline for 11.0.4 development Message-ID: Hi, I propose to explicitly state the following dates on https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u As for 11.0.3, I can do the builds, tests and tags proposed here until RC phase. JDK 11.0.4 timeline * March 2019 jdk11u-dev forest open * Tuesday, April 30: Branch jdk11u-dev to jdk11u * Wednesday, Mai 1 2019: Tag 11.0.4+1 * Wendesday, Mai 29 2019: Tag 11.0.4+5 RDP2 * Wednesday June 26 2019: Tag 11.0.4+9 RC phase (code freeze) * Mid July 2019 GA JDK 11.0.5 timeline * Wednesday, Mai 1 2019 Tag 11.0.5+0 in jdk11u-dev, Forest open for development. Best regards, Goetz. From shade at redhat.com Tue Apr 2 08:00:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 2 Apr 2019 10:00:25 +0200 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: Message-ID: On 4/2/19 3:22 AM, Andrew John Hughes wrote: > There are two changes in the repository after 11.0.3+5 [1] [2]. These > changes were not committed until after the agreed deadline of the 1st > and so will now have to wait until 11.0.4. That would be very confusing, as [1] is recorded to be in 11.0.3 in JIRA now, in addition to being in repository history as between 11.0.3+5 and 11.0.3+6. Either revert the patches after 11.0.3+5 and let us push to 11.0.4, or pull the patches into 11.0.3 CPU. > I suggest that, in future, we aim to tag the release on the day of the > deadline or the last working day before to avoid such confusion. I suggest, once again, that we mechanically lock the repository when we don't accept the pushes. Let only the maintainers to push. Then Andrew can push the CPU update himself before unfreezing the repo. > [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe > [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 -- Thanks, -Aleksey From sgehwolf at redhat.com Tue Apr 2 08:30:32 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 02 Apr 2019 10:30:32 +0200 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: Message-ID: On Tue, 2019-04-02 at 10:00 +0200, Aleksey Shipilev wrote: > On 4/2/19 3:22 AM, Andrew John Hughes wrote: > > There are two changes in the repository after 11.0.3+5 [1] [2]. These > > changes were not committed until after the agreed deadline of the 1st > > and so will now have to wait until 11.0.4. > > That would be very confusing, as [1] is recorded to be in 11.0.3 in JIRA now, in addition to being > in repository history as between 11.0.3+5 and 11.0.3+6. Either revert the patches after 11.0.3+5 and > let us push to 11.0.4, or pull the patches into 11.0.3 CPU. As I understand it, it's only [1] which we'd be talking about. [2] apparently got pushed to jdk-updates/jdk11u by accident[*]. Revert is in progress. +1 to cleaning jdk-updates/jdk11u up/re-tagging as Aleksey said. Personally, I'd be in favor of a tag 11.0.3+6 for: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 Thanks, Severin [*] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000859.html > > I suggest that, in future, we aim to tag the release on the day of the > > deadline or the last working day before to avoid such confusion. > > I suggest, once again, that we mechanically lock the repository when we don't accept the pushes. Let > only the maintainers to push. Then Andrew can push the CPU update himself before unfreezing the repo. > > > [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe > > [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 > > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 > > From takiguc at linux.vnet.ibm.com Tue Apr 2 09:18:44 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 02 Apr 2019 18:18:44 +0900 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: Message-ID: <9e9867cd51aeea9ddc2f59ffd0749b1d@linux.vnet.ibm.com> Hello. I am sorry to disturb you. Japanese era name will be changed by May 1st, 2019. Japanese users require following fix for new Japanese era name. JDK-8205432 Replace the placeholder Japanese era name [1] Current 11.0.3 has placeholder (dummy entry), we really need above fix. But fix request for jdk11u has not been approved yet. I requested to pick up new Japanese era name fix before. [2] I really appreciate to pick JDK-8205432 by 11.0.3. [1] https://bugs.openjdk.java.net/browse/JDK-8205432 [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-March/000728.html Thanks, Ichiroh Takiguchi IBM Japan Ltd. On 2019-04-02 10:22, Andrew John Hughes wrote: > The release tree: > > https://hg.openjdk.java.net/jdk-updates/jdk11u/ > > is now frozen in preparation for release on 2019-04-16. > > The final release will be based on 11.0.3+5 [0] and will have a version > no lower than 11.0.3+6. > > There are two changes in the repository after 11.0.3+5 [1] [2]. These > changes were not committed until after the agreed deadline of the 1st > and so will now have to wait until 11.0.4. > > I suggest that, in future, we aim to tag the release on the day of the > deadline or the last working day before to avoid such confusion. > > [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe > [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 From christoph.langer at sap.com Tue Apr 2 09:59:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 2 Apr 2019 09:59:25 +0000 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: Message-ID: Hi, Andrew Hughes, as the maintainer of the CPU forest, has let us know that he can/will pull a final public tag (11.0.3+6) in jdk11u until 6PM UTC today. To clean up the current situation, Goetz and me will push the backout change for the accidental JDK-8207760 [0] commit and then tag 11.0.3+6. @Andrew Haley: Can you please confirm this by approving the backout bug JDK-8221769 [1] with jdk11u-critical-yes? Thanks & Best regards Christoph [0] http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 [1] https://bugs.openjdk.java.net/browse/JDK-8221769 > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Severin Gehwolf > Sent: Dienstag, 2. April 2019 10:31 > To: Aleksey Shipilev ; Andrew John Hughes > ; 'jdk-updates-dev at openjdk.java.net' updates-dev at openjdk.java.net> > Subject: Re: [FREEZE] 11.0.3 NOW FROZEN > > On Tue, 2019-04-02 at 10:00 +0200, Aleksey Shipilev wrote: > > On 4/2/19 3:22 AM, Andrew John Hughes wrote: > > > There are two changes in the repository after 11.0.3+5 [1] [2]. These > > > changes were not committed until after the agreed deadline of the 1st > > > and so will now have to wait until 11.0.4. > > > > That would be very confusing, as [1] is recorded to be in 11.0.3 in JIRA now, > in addition to being > > in repository history as between 11.0.3+5 and 11.0.3+6. Either revert the > patches after 11.0.3+5 and > > let us push to 11.0.4, or pull the patches into 11.0.3 CPU. > > As I understand it, it's only [1] which we'd be talking about. [2] > apparently got pushed to jdk-updates/jdk11u by accident[*]. Revert is > in progress. > > +1 to cleaning jdk-updates/jdk11u up/re-tagging as Aleksey said. > Personally, I'd be in favor of a tag 11.0.3+6 for: > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 > > Thanks, > Severin > > [*] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/000859.html > > > > I suggest that, in future, we aim to tag the release on the day of the > > > deadline or the last working day before to avoid such confusion. > > > > I suggest, once again, that we mechanically lock the repository when we > don't accept the pushes. Let > > only the maintainers to push. Then Andrew can push the CPU update > himself before unfreezing the repo. > > > > > [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe > > > [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 > > > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 > > > > From christoph.langer at sap.com Tue Apr 2 10:03:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 2 Apr 2019 10:03:51 +0000 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: <9e9867cd51aeea9ddc2f59ffd0749b1d@linux.vnet.ibm.com> References: <9e9867cd51aeea9ddc2f59ffd0749b1d@linux.vnet.ibm.com> Message-ID: Hi Ichiroh, Andrew has written in an earlier mail [0], that he is going to do the backport of the Japanese era change. He'll include it in the CPU as well as push it for jdk11u-dev, once ready. Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000864.html > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ichiroh Takiguchi > Sent: Dienstag, 2. April 2019 11:19 > To: Andrew John Hughes > Cc: 'jdk-updates-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: [FREEZE] 11.0.3 NOW FROZEN > > Hello. > > I am sorry to disturb you. > > Japanese era name will be changed by May 1st, 2019. > Japanese users require following fix for new Japanese era name. > JDK-8205432 Replace the placeholder Japanese era name [1] > > Current 11.0.3 has placeholder (dummy entry), we really need above fix. > But fix request for jdk11u has not been approved yet. > I requested to pick up new Japanese era name fix before. [2] > I really appreciate to pick JDK-8205432 by 11.0.3. > > [1] https://bugs.openjdk.java.net/browse/JDK-8205432 > [2] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > March/000728.html > > Thanks, > Ichiroh Takiguchi > IBM Japan Ltd. > > On 2019-04-02 10:22, Andrew John Hughes wrote: > > The release tree: > > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/ > > > > is now frozen in preparation for release on 2019-04-16. > > > > The final release will be based on 11.0.3+5 [0] and will have a version > > no lower than 11.0.3+6. > > > > There are two changes in the repository after 11.0.3+5 [1] [2]. These > > changes were not committed until after the agreed deadline of the 1st > > and so will now have to wait until 11.0.4. > > > > I suggest that, in future, we aim to tag the release on the day of the > > deadline or the last working day before to avoid such confusion. > > > > [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe > > [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 > > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 From takiguc at linux.vnet.ibm.com Tue Apr 2 10:15:35 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 02 Apr 2019 19:15:35 +0900 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: <9e9867cd51aeea9ddc2f59ffd0749b1d@linux.vnet.ibm.com> Message-ID: Hello Christoph. Thank you for reply. I'm very sorry, I missed Andrew's mail[0]. :-( [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000864.html Thanks, Ichiroh Takiguchi On 2019-04-02 19:03, Langer, Christoph wrote: > Hi Ichiroh, > > Andrew has written in an earlier mail [0], that he is going to do the > backport of the Japanese era change. He'll include it in the CPU as > well as push it for jdk11u-dev, once ready. > > Best regards > Christoph > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000864.html > > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Ichiroh Takiguchi >> Sent: Dienstag, 2. April 2019 11:19 >> To: Andrew John Hughes >> Cc: 'jdk-updates-dev at openjdk.java.net' > dev at openjdk.java.net> >> Subject: Re: [FREEZE] 11.0.3 NOW FROZEN >> >> Hello. >> >> I am sorry to disturb you. >> >> Japanese era name will be changed by May 1st, 2019. >> Japanese users require following fix for new Japanese era name. >> JDK-8205432 Replace the placeholder Japanese era name [1] >> >> Current 11.0.3 has placeholder (dummy entry), we really need above >> fix. >> But fix request for jdk11u has not been approved yet. >> I requested to pick up new Japanese era name fix before. [2] >> I really appreciate to pick JDK-8205432 by 11.0.3. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8205432 >> [2] >> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- >> March/000728.html >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan Ltd. >> >> On 2019-04-02 10:22, Andrew John Hughes wrote: >> > The release tree: >> > >> > https://hg.openjdk.java.net/jdk-updates/jdk11u/ >> > >> > is now frozen in preparation for release on 2019-04-16. >> > >> > The final release will be based on 11.0.3+5 [0] and will have a version >> > no lower than 11.0.3+6. >> > >> > There are two changes in the repository after 11.0.3+5 [1] [2]. These >> > changes were not committed until after the agreed deadline of the 1st >> > and so will now have to wait until 11.0.4. >> > >> > I suggest that, in future, we aim to tag the release on the day of the >> > deadline or the last working day before to avoid such confusion. >> > >> > [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe >> > [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 >> > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 From aph at redhat.com Tue Apr 2 10:36:06 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 2 Apr 2019 11:36:06 +0100 Subject: Timeline for 11.0.4 development In-Reply-To: References: Message-ID: On 4/2/19 8:38 AM, Lindenmaier, Goetz wrote: > I propose to explicitly state the following dates on > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > As for 11.0.3, I can do the builds, tests and tags proposed here > until RC phase. > JDK 11.0.4 timeline > > * March 2019 jdk11u-dev forest open > * Tuesday, April 30: Branch jdk11u-dev to jdk11u > * Wednesday, Mai 1 2019: Tag 11.0.4+1 > * Wendesday, Mai 29 2019: Tag 11.0.4+5 RDP2 > * Wednesday June 26 2019: Tag 11.0.4+9 RC phase (code freeze) These dates sound plausible. Was there some agreement that the RC build numbers should be fixed? I know Gil Tene asked for it and there was some discussion, but that's not the same thing. Deciding build numbers in advance rather than them just being, you know, build numbers doesn't sound obviously right to me. > * Mid July 2019 GA GA is 16 July 2019. June 26 for the freeze sounds about right, but we might freeze before then. > JDK 11.0.5 timeline > > * Wednesday, Mai 1 2019 Tag 11.0.5+0 in jdk11u-dev, Forest open > for development. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Tue Apr 2 10:53:04 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Apr 2019 10:53:04 +0000 Subject: Timeline for 11.0.4 development In-Reply-To: References: Message-ID: Hi Andrew, > > I propose to explicitly state the following dates on > > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > > > As for 11.0.3, I can do the builds, tests and tags proposed here > > until RC phase. > > > JDK 11.0.4 timeline > > > > * March 2019 jdk11u-dev forest open > > * Tuesday, April 30: Branch jdk11u-dev to jdk11u > > * Wednesday, Mai 1 2019: Tag 11.0.4+1 > > * Wendesday, Mai 29 2019: Tag 11.0.4+5 RDP2 > > * Wednesday June 26 2019: Tag 11.0.4+9 RC phase (code freeze) > > These dates sound plausible. > > Was there some agreement that the RC build numbers should be fixed? I > know Gil Tene asked for it and there was some discussion, but that's > not the same thing. Deciding build numbers in advance rather than them > just being, you know, build numbers doesn't sound obviously right to me. I think there was agreement not to fix the build number in advance. > > > * Mid July 2019 GA > > GA is 16 July 2019. June 26 for the freeze sounds about right, but we > might freeze before then. Please announce in-time if you intend to freeze before that. Or should we better put June 19 there, it's easier to give it an extra week than to go more early? Best regards, Goetz. > > JDK 11.0.5 timeline > > > > * Wednesday, Mai 1 2019 Tag 11.0.5+0 in jdk11u-dev, Forest open > > for development. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue Apr 2 11:01:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 2 Apr 2019 11:01:25 +0000 Subject: Timeline for 11.0.4 development In-Reply-To: References: Message-ID: Hi Goetz, > I propose to explicitly state the following dates on > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > As for 11.0.3, I can do the builds, tests and tags proposed here until RC phase. > JDK 11.0.4 timeline > > * March 2019 jdk11u-dev forest open > * Tuesday, April 30: Branch jdk11u-dev to jdk11u > * Wednesday, Mai 1 2019: Tag 11.0.4+1 > * Wendesday, Mai 29 2019: Tag 11.0.4+5 RDP2 > * Wednesday June 26 2019: Tag 11.0.4+9 RC phase (code freeze) > * Mid July 2019 GA > > JDK 11.0.5 timeline > > * Wednesday, Mai 1 2019 Tag 11.0.5+0 in jdk11u-dev, Forest open for > development. I like explicitly stating concrete days for cutoff and tagging to avoid situations like we currently have in jdk11u. I however think we should do the jdk11u-dev to jdk11u branching on May 29, 2019. Then we have 6 weeks for RDP which should be enough. Maybe we shouldn't stick to this RDP2 term in the context of jdk11u, anyway. We should have 3 phases: 1. When release is still in jdk11u-dev 2. RDP (Ramp down phase) - after the branch jdk11u-dev -> jdk11u happened (e.g. 6 weeks before GA) 3. CPU Freeze - e.g. 2 weeks before GA Furthermore, I think we should only tag a new build if we have had changes compared to the last tag. It's of no use to have a tag following another in a repo if nothing happened. So, we also shouldn't announce build numbers beforehand. Best regards Christoph From goetz.lindenmaier at sap.com Tue Apr 2 11:10:20 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Apr 2019 11:10:20 +0000 Subject: Timeline for 11.0.4 development In-Reply-To: References: Message-ID: Hi Christoph, the earlier we branch off, the earlier we can push a bit more risky changes to jdk11u-dev. Like downporting "JEP 344-Abortable Mixed Collections for G1 to jdk11u" We could push such a change an May 1 to jdk11u-dev, and it would be delivered on Oct. 15. If we branch off on May 29, this gives us 4 weeks less. As it's not RDP2, we could still push acceptable changes to jdk11u. Also, jdk11u would be "closed" for 6 weeks, giving lots of chances for wrong pushes :) Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Dienstag, 2. April 2019 13:01 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: Timeline for 11.0.4 development > > Hi Goetz, > > > I propose to explicitly state the following dates on > > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > > > As for 11.0.3, I can do the builds, tests and tags proposed here until RC > phase. > > JDK 11.0.4 timeline > > > > * March 2019 jdk11u-dev forest open > > * Tuesday, April 30: Branch jdk11u-dev to jdk11u > > * Wednesday, Mai 1 2019: Tag 11.0.4+1 > > * Wendesday, Mai 29 2019: Tag 11.0.4+5 RDP2 > > * Wednesday June 26 2019: Tag 11.0.4+9 RC phase (code freeze) > > * Mid July 2019 GA > > > > JDK 11.0.5 timeline > > > > * Wednesday, Mai 1 2019 Tag 11.0.5+0 in jdk11u-dev, Forest open for > > development. > > I like explicitly stating concrete days for cutoff and tagging to avoid situations > like we currently have in jdk11u. > > I however think we should do the jdk11u-dev to jdk11u branching on May 29, > 2019. Then we have 6 weeks for RDP which should be enough. > > Maybe we shouldn't stick to this RDP2 term in the context of jdk11u, anyway. > We should have 3 phases: > > 1. When release is still in jdk11u-dev > 2. RDP (Ramp down phase) - after the branch jdk11u-dev -> jdk11u happened > (e.g. 6 weeks before GA) > 3. CPU Freeze - e.g. 2 weeks before GA > > Furthermore, I think we should only tag a new build if we have had changes > compared to the last tag. It's of no use to have a tag following another in a > repo if nothing happened. > > So, we also shouldn't announce build numbers beforehand. > > Best regards > Christoph From christoph.langer at sap.com Tue Apr 2 12:47:55 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 2 Apr 2019 12:47:55 +0000 Subject: Backports to jdk11u are still tagged as 11.0.3 In-Reply-To: References: <349A7BDE-CBE1-42BD-B316-743221D63D42@amazon.com> <94E62DE7-2FE9-47D9-B9A1-BAEF3D795D7C@amazon.com> Message-ID: Hi Paul, I've pushed the backout change to jdk11u, so everything is repaired. You can now push 8207760 correctly to jdk11u-dev, I guess ?? Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 1. April 2019 22:32 > To: Hohensee, Paul ; jdk-updates- > dev at openjdk.java.net > Subject: RE: Backports to jdk11u are still tagged as 11.0.3 > > Hi Paul, > > not nice ... but I'm always glad it wasn't me ?? > > I've added jdk11u-critical-request to the backout bug, which is what's > needed for jdk11u push approval, and for the created packport bug I've set > the version to 11-pool, so hgupdater will reuse it and set the correct version > when you correctly push to jdk11u-dev. > > Consider the backout change reviewed. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Hohensee, Paul > > Sent: Montag, 1. April 2019 19:25 > > To: jdk-updates-dev at openjdk.java.net > > Subject: Re: Backports to jdk11u are still tagged as 11.0.3 > > > > Reversion JBS issue: https://bugs.openjdk.java.net/browse/JDK-8221769 > > Reversion webrev: http://cr.openjdk.java.net/~phh/8221769/webrev.00/ > > > > Please approve and tag JDK-8221769 jdk11u-fix-yes. > > > > Thanks, > > > > Paul > > > > ?On 4/1/19, 10:10 AM, "jdk-updates-dev on behalf of Hohensee, Paul" > updates-dev-bounces at openjdk.java.net on behalf of > > hohensee at amazon.com> wrote: > > > > My bad, I mistakenly pushed to jdk11u rather than jdk11u-dev. I'll revert > > the push. > > > > On 4/1/19, 10:05 AM, "jdk-updates-dev on behalf of Hohensee, Paul" > > updates-dev-bounces at openjdk.java.net on behalf of > > hohensee at amazon.com> wrote: > > > > See > > > > https://bugs.openjdk.java.net/browse/JDK-8207760 > > https://bugs.openjdk.java.net/browse/JDK-8221767 > > > > We should be tagging them 11.0.4, right? > > > > Thanks, > > > > Paul > > > > > > > > > > From goetz.lindenmaier at sap.com Tue Apr 2 12:53:16 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Apr 2019 12:53:16 +0000 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: Message-ID: Hi Andrew, We backed out 8207760 and I pushed a new tag. We would appreciate a lot if you could use tag jdk-11.0.3+6 for your internal repository. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew John Hughes > Sent: Dienstag, 2. April 2019 03:22 > To: 'jdk-updates-dev at openjdk.java.net' > Subject: [FREEZE] 11.0.3 NOW FROZEN > > The release tree: > > https://hg.openjdk.java.net/jdk-updates/jdk11u/ > > is now frozen in preparation for release on 2019-04-16. > > The final release will be based on 11.0.3+5 [0] and will have a version > no lower than 11.0.3+6. > > There are two changes in the repository after 11.0.3+5 [1] [2]. These > changes were not committed until after the agreed deadline of the 1st > and so will now have to wait until 11.0.4. > > I suggest that, in future, we aim to tag the release on the day of the > deadline or the last working day before to avoid such confusion. > > [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe > [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From aph at redhat.com Tue Apr 2 12:57:00 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 2 Apr 2019 13:57:00 +0100 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: Message-ID: On 4/2/19 9:00 AM, Aleksey Shipilev wrote: > I suggest, once again, that we mechanically lock the repository when > we don't accept the pushes. Let only the maintainers to push. Then > Andrew can push the CPU update himself before unfreezing the repo. > >> [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe >> [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 >> [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 OK, OK, you're right. We can make those changes after the CPU. Never let it be said that I'm too stubborn to admit when I'm beaten. :-) Thinking some more, though, this illuminates a real problem in our processes. A rule of user interface design is that actions should be easily reversible: Make actions reversible (be forgiving) This rule means that the user should always be able to quickly backtrack whatever they are doing. This allows users to explore the product without the constant fear of failure -- when a user knows that errors can be easily undone, this encourages exploration of unfamiliar options. On the contrary, if a user has to be extremely careful with every action they take, it leads to a slower exploration and nerve-racking experience that no one wants. https://theblog.adobe.com/4-golden-rules-ui-design/ It's clear to me that our source control system and its interaction with the bug database fails this rule, and spectacularly so. A contributor should be able to say "oops!" after a mistaken checkin and easily undo it. Today, though, backing out a change requires interaction between multiple people and systems and a public apology. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Tue Apr 2 12:57:40 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Apr 2019 12:57:40 +0000 Subject: jdk11u closed until jdk11u-dev is moved to jdk11u Message-ID: Hi everybody, please note that you should not push any changes to jdk11u any more. This repo is closed until 11.0.4 is moved from jdk11u-dev to jdk11u, which will be somewhere in May. We will update the JDK 11.0.4 timeline with precise dates, see [0]. Best regards, Goetz https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u From goetz.lindenmaier at sap.com Tue Apr 2 13:06:09 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Apr 2019 13:06:09 +0000 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: Message-ID: > Today, though, backing out a change requires > interaction between multiple people and systems and a public apology. We could allow a backout after reviews without requiring jdk11u-fix-request tagging. Appropriate 'R'eviewers should be always online. The JBS bug can be fixed by hand. Best regards, Goetz. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Tue Apr 2 13:24:17 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 2 Apr 2019 15:24:17 +0200 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: Message-ID: <4f4778fe-61cb-1581-77f6-fbfa2463c3d4@redhat.com> On 4/2/19 2:57 PM, Andrew Haley wrote: > A rule of user interface design is that actions should be easily > reversible: Processes are in place to prevent avoidable mistakes [1]. *This* is the real problem in current process: it relies on people being always 100% aware, awake and following the fluid and frequently-changing rules, and we know that errare humanium est. We have to build processes with that thought in mind: the lightweight process of reversal minimizes the cost of error, while mechanical checks eliminate that cost to begin with. The problem with reversals is that mistakes usually happen when we are in hurry, which is exactly the time when we don't want to make mistakes and waste time fixing them. The repository that is used to make a time-sensitive release is one of those things. -- Thanks, -Aleksey [1] The post you linked makes this point before making the point you cite: "Engineer for errors: Errors are inadvertent in the user journey. Bad error handling paired with useless error messages can fill users with frustration and lead them to abandon your app. [...] Good error messages are precise, polite, and constructive. [...] Even better than writing good error messages is creating a design that prevents a problem from occurring in the first place. Try to either eliminate error-prone conditions or check for them [...]" From aph at redhat.com Tue Apr 2 13:31:39 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 2 Apr 2019 14:31:39 +0100 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: <4f4778fe-61cb-1581-77f6-fbfa2463c3d4@redhat.com> References: <4f4778fe-61cb-1581-77f6-fbfa2463c3d4@redhat.com> Message-ID: <1e4f4142-5cf1-c2e6-0fa7-d03f90c121f6@redhat.com> On 4/2/19 2:24 PM, Aleksey Shipilev wrote: > On 4/2/19 2:57 PM, Andrew Haley wrote: >> A rule of user interface design is that actions should be easily >> reversible: > > Processes are in place to prevent avoidable mistakes [1]. *This* is > the real problem in current process: it relies on people being > always 100% aware, awake and following the fluid and > frequently-changing rules, and we know that errare humanium est. We > have to build processes with that thought in mind: the lightweight > process of reversal minimizes the cost of error, while mechanical > checks eliminate that cost to begin with. Yes, exactly. But the "mechanical check" we're talking about, that of restricting access, is not a check at all: all it does is restrict the group of people who make the mistakes. > The problem with reversals is that mistakes usually happen when we > are in hurry, which is exactly the time when we don't want to make > mistakes and waste time fixing them. The repository that is used to > make a time-sensitive release is one of those things. Exactly so. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Tue Apr 2 13:47:52 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 2 Apr 2019 13:47:52 +0000 Subject: Backports to jdk11u are still tagged as 11.0.3 In-Reply-To: References: <349A7BDE-CBE1-42BD-B316-743221D63D42@amazon.com> <94E62DE7-2FE9-47D9-B9A1-BAEF3D795D7C@amazon.com> Message-ID: <1903A1E4-F4E5-42ED-855E-87541AAEFD9D@amazon.com> Thanks! Paul ?On 4/2/19, 5:49 AM, "Langer, Christoph" wrote: Hi Paul, I've pushed the backout change to jdk11u, so everything is repaired. You can now push 8207760 correctly to jdk11u-dev, I guess ?? Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 1. April 2019 22:32 > To: Hohensee, Paul ; jdk-updates- > dev at openjdk.java.net > Subject: RE: Backports to jdk11u are still tagged as 11.0.3 > > Hi Paul, > > not nice ... but I'm always glad it wasn't me ?? > > I've added jdk11u-critical-request to the backout bug, which is what's > needed for jdk11u push approval, and for the created packport bug I've set > the version to 11-pool, so hgupdater will reuse it and set the correct version > when you correctly push to jdk11u-dev. > > Consider the backout change reviewed. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Hohensee, Paul > > Sent: Montag, 1. April 2019 19:25 > > To: jdk-updates-dev at openjdk.java.net > > Subject: Re: Backports to jdk11u are still tagged as 11.0.3 > > > > Reversion JBS issue: https://bugs.openjdk.java.net/browse/JDK-8221769 > > Reversion webrev: http://cr.openjdk.java.net/~phh/8221769/webrev.00/ > > > > Please approve and tag JDK-8221769 jdk11u-fix-yes. > > > > Thanks, > > > > Paul > > > > On 4/1/19, 10:10 AM, "jdk-updates-dev on behalf of Hohensee, Paul" > updates-dev-bounces at openjdk.java.net on behalf of > > hohensee at amazon.com> wrote: > > > > My bad, I mistakenly pushed to jdk11u rather than jdk11u-dev. I'll revert > > the push. > > > > On 4/1/19, 10:05 AM, "jdk-updates-dev on behalf of Hohensee, Paul" > > updates-dev-bounces at openjdk.java.net on behalf of > > hohensee at amazon.com> wrote: > > > > See > > > > https://bugs.openjdk.java.net/browse/JDK-8207760 > > https://bugs.openjdk.java.net/browse/JDK-8221767 > > > > We should be tagging them 11.0.4, right? > > > > Thanks, > > > > Paul > > > > > > > > > > From gil at azul.com Tue Apr 2 15:49:33 2019 From: gil at azul.com (Gil Tene) Date: Tue, 2 Apr 2019 15:49:33 +0000 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: , Message-ID: <72B589A5-41E0-4EC4-916D-FCA2AD5C283E@azul.com> Once the 11.0.3+6 tag is set, can you please clarify/restate the following statement from the first e-mail in this thread: The final release will be based on 11.0.3+5 [0] and will have a version no lower than 11.0.3+6. Is is fair to (now) assume that this has moved by 1, and will now be the following? ?The final release will be based on 11.0.3+6 [0] and will have a version no lower than 11.0.3+7.? Sent from my iPad On Apr 2, 2019, at 3:01 AM, Langer, Christoph > wrote: Hi, Andrew Hughes, as the maintainer of the CPU forest, has let us know that he can/will pull a final public tag (11.0.3+6) in jdk11u until 6PM UTC today. To clean up the current situation, Goetz and me will push the backout change for the accidental JDK-8207760 [0] commit and then tag 11.0.3+6. @Andrew Haley: Can you please confirm this by approving the backout bug JDK-8221769 [1] with jdk11u-critical-yes? Thanks & Best regards Christoph [0] http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 [1] https://bugs.openjdk.java.net/browse/JDK-8221769 -----Original Message----- From: jdk-updates-dev > On Behalf Of Severin Gehwolf Sent: Dienstag, 2. April 2019 10:31 To: Aleksey Shipilev >; Andrew John Hughes >; 'jdk-updates-dev at openjdk.java.net' > Subject: Re: [FREEZE] 11.0.3 NOW FROZEN On Tue, 2019-04-02 at 10:00 +0200, Aleksey Shipilev wrote: On 4/2/19 3:22 AM, Andrew John Hughes wrote: There are two changes in the repository after 11.0.3+5 [1] [2]. These changes were not committed until after the agreed deadline of the 1st and so will now have to wait until 11.0.4. That would be very confusing, as [1] is recorded to be in 11.0.3 in JIRA now, in addition to being in repository history as between 11.0.3+5 and 11.0.3+6. Either revert the patches after 11.0.3+5 and let us push to 11.0.4, or pull the patches into 11.0.3 CPU. As I understand it, it's only [1] which we'd be talking about. [2] apparently got pushed to jdk-updates/jdk11u by accident[*]. Revert is in progress. +1 to cleaning jdk-updates/jdk11u up/re-tagging as Aleksey said. Personally, I'd be in favor of a tag 11.0.3+6 for: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 Thanks, Severin [*] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- April/000859.html I suggest that, in future, we aim to tag the release on the day of the deadline or the last working day before to avoid such confusion. I suggest, once again, that we mechanically lock the repository when we don't accept the pushes. Let only the maintainers to push. Then Andrew can push the CPU update himself before unfreezing the repo. [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0 [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339 From gnu.andrew at redhat.com Tue Apr 2 16:40:15 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 2 Apr 2019 17:40:15 +0100 Subject: Timeline for 11.0.4 development In-Reply-To: References: Message-ID: <78da027e-5956-7168-5704-77a687122412@redhat.com> On 02/04/2019 08:38, Lindenmaier, Goetz wrote: > Hi, > > I propose to explicitly state the following dates on > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > As for 11.0.3, I can do the builds, tests and tags proposed here > until RC phase. > JDK 11.0.4 timeline > > * March 2019 jdk11u-dev forest open > * Tuesday, April 30: Branch jdk11u-dev to jdk11u > * Wednesday, Mai 1 2019: Tag 11.0.4+1 > * Wendesday, Mai 29 2019: Tag 11.0.4+5 RDP2 > * Wednesday June 26 2019: Tag 11.0.4+9 RC phase (code freeze) > * Mid July 2019 GA > > JDK 11.0.5 timeline > > * Wednesday, Mai 1 2019 Tag 11.0.5+0 in jdk11u-dev, Forest open for development. > > > Best regards, > Goetz. > I'm not sure what this is based on. As previously stated, the freeze will be on the first working day of the month, so it will be Monday, 1st of July, 2019. The tag will depend on what the last one was at that point. When was it determined that tags would be mid-week? That seems an odd time to me. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Apr 2 16:42:37 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 2 Apr 2019 17:42:37 +0100 Subject: [FREEZE] 11.0.3 NOW FROZEN In-Reply-To: References: <9e9867cd51aeea9ddc2f59ffd0749b1d@linux.vnet.ibm.com> Message-ID: <23f57672-9d77-8cdf-beb0-3b806cc2995a@redhat.com> On 02/04/2019 11:15, Ichiroh Takiguchi wrote: > Hello Christoph. > Thank you for reply. > I'm very sorry, I missed Andrew's mail[0]. :-( > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000864.html > > > Thanks, > Ichiroh Takiguchi > No harm done. Thanks for making sure it wasn't missed :) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Apr 2 16:48:26 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 2 Apr 2019 17:48:26 +0100 Subject: [FREEZE] 11.0.3 NOW FROZEN (again); jdk11u tree CLOSED Message-ID: The release tree: https://hg.openjdk.java.net/jdk-updates/jdk11u/ is now frozen in preparation for release on 2019-04-16. The final release will be based on 11.0.3+6 [0] and will have a version no lower than 11.0.3+7. Yes, I mean it this time. No ifs, no buts. [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/bd1035b5571b -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Tue Apr 2 17:26:23 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 2 Apr 2019 18:26:23 +0100 Subject: Timeline for 11.0.4 development In-Reply-To: References: Message-ID: <9dedfa1b-aecc-3d9d-9728-0f750c06637e@redhat.com> On 4/2/19 8:38 AM, Lindenmaier, Goetz wrote: > I propose to explicitly state the following dates on > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u Related: I've been told by Oracle that if we know a week or so in advance what a new release value will be, we should tell them so that they can be sure it's available when we need to update the repo conf to use it. This will avoid the delays we've seen recently. Thank you. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Tue Apr 2 18:26:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 2 Apr 2019 19:26:48 +0100 Subject: Timeline for 11.0.4 development In-Reply-To: <9dedfa1b-aecc-3d9d-9728-0f750c06637e@redhat.com> References: <9dedfa1b-aecc-3d9d-9728-0f750c06637e@redhat.com> Message-ID: <8709af19-dfe4-f924-90f3-aeec338457a2@redhat.com> On 02/04/2019 18:26, Andrew Haley wrote: > On 4/2/19 8:38 AM, Lindenmaier, Goetz wrote: > >> I propose to explicitly state the following dates on >> https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > Related: I've been told by Oracle that if we know a week or so in advance what > a new release value will be, we should tell them so that they can be sure it's > available when we need to update the repo conf to use it. This will avoid the > delays we've seen recently. Thank you. > Well, we should know what they will all be going forward. For 8u, the series is: openjdk8u212 openjdk8u222 openjdk8u232 openjdk8u242 etc. For 11u, the series is: 11.0.3 11.0.4 11.0.5 11.0.6 etc. The former are the same as Oracle, but with 'openjdk' prepended. The latter are the same as Oracle without the '-oracle' suffix. So they could make sure they are available when they create the equivalent Oracle ones. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Tue Apr 2 21:09:59 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Apr 2019 21:09:59 +0000 Subject: Timeline for 11.0.4 development In-Reply-To: <78da027e-5956-7168-5704-77a687122412@redhat.com> References: <78da027e-5956-7168-5704-77a687122412@redhat.com> Message-ID: Hi Andrew, I proposed the tagging date here, and didn't get any objections: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html Monday is not good for me, Tuesday would work. It's because I check our testing before I pick a change to tag. Currently, on Tuesday I have a look whether the build of Monday evening is fine. If not, I can try to do an emergency fix on Tuesday working day. Our infrastructure pulls on Tuesday evening, tests, and Wednesday morning I tag the change that was tested. If I see severe regressions, I will open bugs. On Wednesday, I merge the tag to jdk11u-dev, and Wednesday evening build and tests start for jdk11u-dev with the new tag merged. This I push on Thursday. ... I could do all this one day more early, starting Monday. Further, on Mondays, every once in a while our machines are down because IT did some 'harmless' maintenance to our servers on the weekend. Then we don't have builds or tests. If you pick a fixed date, like 1st of the month, it's always a varying weekday. This is confusing and not well aligned with a weekly tag. Anyways, you can clone any day after the freeze was announced, this is not observable ?? Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew John Hughes > Sent: Tuesday, April 2, 2019 6:40 PM > To: jdk-updates-dev at openjdk.java.net > Subject: Re: Timeline for 11.0.4 development > > > > On 02/04/2019 08:38, Lindenmaier, Goetz wrote: > > Hi, > > > > I propose to explicitly state the following dates on > > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > > > As for 11.0.3, I can do the builds, tests and tags proposed here > > until RC phase. > > JDK 11.0.4 timeline > > > > * March 2019 jdk11u-dev forest open > > * Tuesday, April 30: Branch jdk11u-dev to jdk11u > > * Wednesday, Mai 1 2019: Tag 11.0.4+1 > > * Wendesday, Mai 29 2019: Tag 11.0.4+5 RDP2 > > * Wednesday June 26 2019: Tag 11.0.4+9 RC phase (code freeze) > > * Mid July 2019 GA > > > > JDK 11.0.5 timeline > > > > * Wednesday, Mai 1 2019 Tag 11.0.5+0 in jdk11u-dev, Forest open for > development. > > > > > > Best regards, > > Goetz. > > > > I'm not sure what this is based on. > > As previously stated, the freeze will be on the first working day of the > month, so it will be Monday, 1st of July, 2019. The tag will depend on > what the last one was at that point. > > When was it determined that tags would be mid-week? That seems an odd > time to me. > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Tue Apr 2 21:15:49 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Apr 2019 21:15:49 +0000 Subject: [FREEZE] 11.0.3 NOW FROZEN (again); jdk11u tree CLOSED In-Reply-To: References: Message-ID: Hi Andrew, Thanks for updating to tag 11.0.3+6. I think it's important no changes dangling in the repo that won't make the release. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew John Hughes > Sent: Tuesday, April 2, 2019 6:48 PM > To: 'jdk-updates-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: [FREEZE] 11.0.3 NOW FROZEN (again); jdk11u tree CLOSED > > The release tree: > > https://hg.openjdk.java.net/jdk-updates/jdk11u/ > > is now frozen in preparation for release on 2019-04-16. > > The final release will be based on 11.0.3+6 [0] and will have a version > no lower than 11.0.3+7. > > Yes, I mean it this time. No ifs, no buts. > > [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/bd1035b5571b > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From ivan.gerasimov at oracle.com Tue Apr 2 21:52:17 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 2 Apr 2019 14:52:17 -0700 Subject: [12u] RFR 8221801 : Update src/java.base/share/legal/public_suffix.md Message-ID: <51ef833a-e67b-1c77-6064-262e53828dc6@oracle.com> Hello! I'm seeking to backport the fix to 12u, and the corresponding regression test had to be slightly edited. Turns out that Mach5 runs jtreg4.2-b13 for 12u builds, and that version does not support "test.root" system property. The modification is straight-forward. WEBREV: http://cr.openjdk.java.net/~igerasim/8221801/00/webrev/ Would you please help review? -- With kind regards, Ivan Gerasimov From weijun.wang at oracle.com Wed Apr 3 00:46:02 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Apr 2019 08:46:02 +0800 Subject: [12u] RFR 8221801 : Update src/java.base/share/legal/public_suffix.md In-Reply-To: <51ef833a-e67b-1c77-6064-262e53828dc6@oracle.com> References: <51ef833a-e67b-1c77-6064-262e53828dc6@oracle.com> Message-ID: Hi Ivan, Code change looks fine to me. The system property is also new to me and it saved a lot of "../../..". Thanks, Max > On Apr 3, 2019, at 5:52 AM, Ivan Gerasimov wrote: > > Hello! > > I'm seeking to backport the fix to 12u, and the corresponding regression test had to be slightly edited. > > Turns out that Mach5 runs jtreg4.2-b13 for 12u builds, and that version does not support "test.root" system property. > > The modification is straight-forward. > > WEBREV: http://cr.openjdk.java.net/~igerasim/8221801/00/webrev/ > > Would you please help review? > > -- > With kind regards, > Ivan Gerasimov > From gnu.andrew at redhat.com Wed Apr 3 00:50:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 3 Apr 2019 01:50:48 +0100 Subject: Timeline for 11.0.4 development In-Reply-To: References: <78da027e-5956-7168-5704-77a687122412@redhat.com> Message-ID: <9a994c26-9e28-2597-1aee-08c0acbfad0b@redhat.com> On 02/04/2019 22:09, Lindenmaier, Goetz wrote: > Hi Andrew, > > I proposed the tagging date here, and didn't get any objections: > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html > > Monday is not good for me, Tuesday would work. > It's because I check our testing before I pick a change > to tag. > Currently, on Tuesday I have a look whether the build of > Monday evening is fine. If not, I can try to do an emergency fix > on Tuesday working day. > Our infrastructure pulls on Tuesday evening, tests, > and Wednesday morning I tag the change that was tested. > If I see severe regressions, I will open bugs. > On Wednesday, I merge the tag to jdk11u-dev, and Wednesday > evening build and tests start for jdk11u-dev with the new > tag merged. > This I push on Thursday. > > ... I could do all this one day more early, starting Monday. > > Further, on Mondays, every once in a while our machines > are down because IT did some 'harmless' maintenance to > our servers on the weekend. Then we don't have builds or tests. > > If you pick a fixed date, like 1st of the month, it's > always a varying weekday. This is confusing and > not well aligned with a weekly tag. > > Anyways, you can clone any day after the freeze > was announced, this is not observable ?? > > Best regards, > Goetz. > > Sorry, I missed that announcement. There's been a lot of traffic on both lists and it's been hard to keep track at times. I'm happy for you to decide the day as you're doing the work. As to the date of the freeze, I suggested the 1st because it was a known date on every cycle. Doing it earlier works in my favour, so I'm not going to argue against that too strongly! I'm just aware that people were still pushing changes on the 1st this time around. Obviously, the problem of using the last tagging date of the month before (March, June, September and December) has its own problems, as it varies how much time people have to commit. It could mean the last date is as early as a week before (not sure if you intend to have the last tag on Wednesday the 1st if it falls that way, or the Wednesday before). However, this doesn't seem too problematic if it is announced clearly well in advance, as you have here. Also, putting it on the wiki is a good idea, as things get lost in all this e-mail. In short, I'm happy to go with this schedule and freeze after you tag on the 26th. Do you plan a similar schedule for 8u? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From ivan.gerasimov at oracle.com Wed Apr 3 00:53:29 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 2 Apr 2019 17:53:29 -0700 Subject: [12u] RFR 8221801 : Update src/java.base/share/legal/public_suffix.md In-Reply-To: References: <51ef833a-e67b-1c77-6064-262e53828dc6@oracle.com> Message-ID: <6db5e007-13c5-7ac4-63b1-c9428edf2b1d@oracle.com> Thank you Weijun! On 4/2/19 5:46 PM, Weijun Wang wrote: > Hi Ivan, > > Code change looks fine to me. The system property is also new to me and it saved a lot of "../../..". > > Thanks, > Max > >> On Apr 3, 2019, at 5:52 AM, Ivan Gerasimov wrote: >> >> Hello! >> >> I'm seeking to backport the fix to 12u, and the corresponding regression test had to be slightly edited. >> >> Turns out that Mach5 runs jtreg4.2-b13 for 12u builds, and that version does not support "test.root" system property. >> >> The modification is straight-forward. >> >> WEBREV: http://cr.openjdk.java.net/~igerasim/8221801/00/webrev/ >> >> Would you please help review? >> >> -- >> With kind regards, >> Ivan Gerasimov >> > -- With kind regards, Ivan Gerasimov From christoph.langer at sap.com Wed Apr 3 07:26:17 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 3 Apr 2019 07:26:17 +0000 Subject: Timeline for 11.0.4 development In-Reply-To: <9a994c26-9e28-2597-1aee-08c0acbfad0b@redhat.com> References: <78da027e-5956-7168-5704-77a687122412@redhat.com> <9a994c26-9e28-2597-1aee-08c0acbfad0b@redhat.com> Message-ID: Hi Andrew, > I'm happy for you to decide the day as you're doing the work. > > As to the date of the freeze, I suggested the 1st because it was a known > date on every cycle. Doing it earlier works in my favour, so I'm not > going to argue against that too strongly! I'm just aware that people > were still pushing changes on the 1st this time around. As for this one: The maintainers that approve patches have some control over this. E.g. if the freeze comes close, the maintainer should not hesitate to defer critical fixes or, in case of approval let the requester know that the fix must pe pushed quickly. > Obviously, the problem of using the last tagging date of the month > before (March, June, September and December) has its own problems, as it > varies how much time people have to commit. It could mean the last date > is as early as a week before (not sure if you intend to have the last > tag on Wednesday the 1st if it falls that way, or the Wednesday before). Oracle delivers the patches always on a Tuesday. So we should plan for the last tag in the public repo 3 weeks before that. > However, this doesn't seem too problematic if it is announced clearly > well in advance, as you have here. Also, putting it on the wiki is a > good idea, as things get lost in all this e-mail. Yes, I think we should announce the freeze for the "tagging Wednesday" that we aim for and I'll definitely add/update the days in the Wiki, once we have them confirmed. > In short, I'm happy to go with this schedule and freeze after you tag on > the 26th. ?? > Do you plan a similar schedule for 8u? I think when we have the schedule confirmed for jdk11u, we can simply take it over to jdk8u. I can do the announcement mail and update both Wikis (jdk8u and jdk11u). As for jdk8u in general: Since the SAP team does not build a downstream SapMachine 8 binary, we are looking at OpenJDK8u with quite low focus. E.g. we don't have the extensive testing environment at hand as we do for JDK11. So beginning with the next update release, I would step back from doing the tagging/integration work in jdk8u. Best regards Christoph From goetz.lindenmaier at sap.com Wed Apr 3 07:42:14 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 3 Apr 2019 07:42:14 +0000 Subject: Timeline for 11.0.4 development In-Reply-To: References: <78da027e-5956-7168-5704-77a687122412@redhat.com> <9a994c26-9e28-2597-1aee-08c0acbfad0b@redhat.com> Message-ID: Hi, > > Obviously, the problem of using the last tagging date of the month > > before (March, June, September and December) has its own problems, as it > > varies how much time people have to commit. It could mean the last date > > is as early as a week before (not sure if you intend to have the last > > tag on Wednesday the 1st if it falls that way, or the Wednesday before). > > Oracle delivers the patches always on a Tuesday. So we should plan for the last > tag in the public repo 3 weeks before that. Yes, that was my math behind those dates. The jdk11u-dev->jdk11u would be two weeks after ga of 11.0.3, leaving time for emergency fixes like we saw in 11.0.2. > > However, this doesn't seem too problematic if it is announced clearly > > well in advance, as you have here. Also, putting it on the wiki is a > > good idea, as things get lost in all this e-mail. > > Yes, I think we should announce the freeze for the "tagging Wednesday" that > we aim for and I'll definitely add/update the days in the Wiki, once we have > them confirmed. Christoph, I think we have basic agreement on the dates now. Could you put them on the page? We still can adapt them if there are objections. And I would propose to list 11.0.5 first, 11.0.3 last. The list will get longer, and this will have the relevant dates first. Best regards, Goetz. From aph at redhat.com Wed Apr 3 08:32:27 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 3 Apr 2019 09:32:27 +0100 Subject: Timeline for 11.0.4 development In-Reply-To: References: <78da027e-5956-7168-5704-77a687122412@redhat.com> Message-ID: <20a089d3-31f8-3c8a-8447-a4328db7ec47@redhat.com> On 4/2/19 10:09 PM, Lindenmaier, Goetz wrote: > I proposed the tagging date here, and didn't get any objections: > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html This has happened a couple of times now: people have posted something, received no objections, and taken it as consent. That is not how things work. We proceed by consensus: that is, we try to reach an agreement that a substantial majority of us are happy with. I realize that getting people to reply can be painful, but that's the only way to achieve a consensus. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Wed Apr 3 09:50:23 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 3 Apr 2019 09:50:23 +0000 Subject: Timeline for 11.0.4 development In-Reply-To: <20a089d3-31f8-3c8a-8447-a4328db7ec47@redhat.com> References: <78da027e-5956-7168-5704-77a687122412@redhat.com> <20a089d3-31f8-3c8a-8447-a4328db7ec47@redhat.com> Message-ID: Hi Andrew, ... to be sure my further tagging and merging of repos is agreed upon ...: The dates I proposed here: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000866.html seem to have basic consensus. I took your mail http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000873.html as an approval so far. Andrew Hughes and Christoph have agreed, too, as I understand. Could you please, as a project lead, confirm that we will act upon this schedule? Then Christoph will put it on the webpage. If it's on the webpage, I hope the dates get more visibility. If then any concerns are raised, we can still update them. Best regards, Goetz. > -----Original Message----- > From: Andrew Haley > Sent: Mittwoch, 3. April 2019 10:32 > To: Lindenmaier, Goetz ; 'Andrew John Hughes' > ; jdk-updates-dev at openjdk.java.net > Subject: Re: Timeline for 11.0.4 development > > On 4/2/19 10:09 PM, Lindenmaier, Goetz wrote: > > I proposed the tagging date here, and didn't get any objections: > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > February/000648.html > > This has happened a couple of times now: people have posted something, > received no objections, and taken it as consent. That is not how > things work. We proceed by consensus: that is, we try to reach an > agreement that a substantial majority of us are happy with. > > I realize that getting people to reply can be painful, but that's the > only way to achieve a consensus. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Wed Apr 3 13:10:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 3 Apr 2019 13:10:28 +0000 Subject: [11u] RFR, RFA, discussion: JDK-8210633, JDK-8205432 (Japanese Era changes) Message-ID: Hi, looking at JBS, we can see that for JDK 11.0.3 the two changes for JDK-8210633, JDK-8205432 regarding the Japanese era need to be included. Since the jdk11u repository is frozen now, Andrew Hughes will add them to the CPU repository and merge them to jdk11u on April the 16th. However, there's probably some interest in the patches for the community to build with. JDK-8210633 applies cleanly from its original commit [0]. @Andrew Haley: I've requested both, jdk11u and jdk11u-critical approval for this change. Please do the needful. JDK-8205432 had to be resolved against jdk11u. I've prepared a webrev for it [1]. I hereby request a review of this backport patch. I had to do the following modifications: make/data/cldr/common/main/ja.xml -> applied against src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ja.xml (file has moved) make/data/cldr/common/main/root.xml -> applied against src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/root.xml (file has moved) test/jdk/java/time/test/java/time/format/TestNonIsoFormatter.java -> copyright hunk failed, ignore test/jdk/java/util/Calendar/CalendarTestScripts/CalendarAdapter.java -> doesn't apply because test don't exist in jdk11 test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java -> doesn't apply because test don't exist in jdk11 test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese.cts -> doesn't apply because test don't exist in jdk11 test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_add.cts -> doesn't apply because test don't exist in jdk11 test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_minmax.cts -> doesn't apply because test don't exist in jdk11 test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_roll.cts -> doesn't apply because test don't exist in jdk11 test/jdk/java/util/Calendar/JapaneseEraNameTest.java -> resolved, the update for China locale did not apply since China is not tested in jdk11u test/jdk/java/util/Calendar/JapaneseLenientEraTest.java -> copyright hunk failed, ignore @Andrew Hughes: Shall I push both patches to jdk11u-dev once they are reviewed and approved? You could probably cherry-pick them from jdk11u-dev to the CPU repository then. Or did you already do some work for JDK-8205432 in the CPU which you want to be transported the other way? Just let me know the next steps. Best regards Christoph [0] http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519 [1] http://cr.openjdk.java.net/~clanger/webrevs/8205432.jdk11u-dev.0/ From christoph.langer at sap.com Wed Apr 3 14:51:18 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 3 Apr 2019 14:51:18 +0000 Subject: [11u] RFR Backport: 8221610: Resurrect (legacy) JRE bundle target Message-ID: Hi, I'd like to backport the resurrection of the legacy JRE bundle target to jdk11 updates because it would help a lot in our build infrastructure. Maybe other downstream vendors can take profit of this, too. The patch doesn't apply cleanly, so I had to resolve a bit. Please review my changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8221610 Original commit: http://hg.openjdk.java.net/jdk/jdk/rev/f062188117ad Backport Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221610.jdk11u-dev.0/ Modifications I had to make: make/Bundles.gmk -> copyright year make/Main.gmk -> ALL_TARGETS += product-bundles legacy-bundles ... needed some resolving Thanks Christoph From erik.joelsson at oracle.com Wed Apr 3 15:15:27 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 3 Apr 2019 08:15:27 -0700 Subject: [11u] RFR Backport: 8221610: Resurrect (legacy) JRE bundle target In-Reply-To: References: Message-ID: Looks good. /Erik On 2019-04-03 07:51, Langer, Christoph wrote: > Hi, > > I'd like to backport the resurrection of the legacy JRE bundle target to jdk11 updates because it would help a lot in our build infrastructure. Maybe other downstream vendors can take profit of this, too. > > The patch doesn't apply cleanly, so I had to resolve a bit. Please review my changes. > Bug: https://bugs.openjdk.java.net/browse/JDK-8221610 > Original commit: http://hg.openjdk.java.net/jdk/jdk/rev/f062188117ad > Backport Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221610.jdk11u-dev.0/ > > Modifications I had to make: > make/Bundles.gmk -> copyright year > make/Main.gmk -> ALL_TARGETS += product-bundles legacy-bundles ... needed some resolving > > Thanks > Christoph > From gnu.andrew at redhat.com Wed Apr 3 15:14:52 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 3 Apr 2019 16:14:52 +0100 Subject: [11u] RFR, RFA, discussion: JDK-8210633, JDK-8205432 (Japanese Era changes) In-Reply-To: References: Message-ID: On 03/04/2019 14:10, Langer, Christoph wrote: > Hi, > > ? > > looking at JBS, we can see that for JDK 11.0.3 the two changes for > JDK-8210633, JDK-8205432 regarding the Japanese era need to be included. > > ? > > Since the jdk11u repository is frozen now, Andrew Hughes will add them > to the CPU repository and merge them to jdk11u on April the 16^th . > However, there?s probably some interest in the patches for the community > to build with. > > ? > > JDK-8210633 applies cleanly from its original commit [0]. @Andrew Haley > : I?ve requested both, jdk11u and jdk11u-critical > approval for this change. Please do the needful. > > ? > > JDK-8205432 had to be resolved against jdk11u. I?ve prepared a webrev > for it [1]. I hereby request a review of this backport patch. I had to > do the following modifications: > > ? > > make/data/cldr/common/main/ja.xml -> applied against > src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ja.xml > (file has moved) > > make/data/cldr/common/main/root.xml -> applied against > src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/root.xml > (file has moved) > > test/jdk/java/time/test/java/time/format/TestNonIsoFormatter.java -> > copyright hunk failed, ignore > > test/jdk/java/util/Calendar/CalendarTestScripts/CalendarAdapter.java -> > doesn't apply because test don't exist in jdk11 > > test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java -> doesn't > apply because test don't exist in jdk11 > > test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese.cts -> > doesn't apply because test don't exist in jdk11 > > test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_add.cts -> > doesn't apply because test don't exist in jdk11 > > test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_minmax.cts > -> doesn't apply because test don't exist in jdk11 > > test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_roll.cts > -> doesn't apply because test don't exist in jdk11 > > test/jdk/java/util/Calendar/JapaneseEraNameTest.java -> resolved, the > update for China locale did not apply since China is not tested in jdk11u > > test/jdk/java/util/Calendar/JapaneseLenientEraTest.java -> copyright > hunk failed, ignore > > ? > > ? > > @Andrew Hughes : Shall I push both patches > to jdk11u-dev once they are reviewed and approved? You could probably > cherry-pick them from jdk11u-dev to the CPU repository then. Or did you > already do some work for JDK-8205432 in the CPU which you want to be > transported the other way? Just let me know the next steps. > > ? > > Best regards > > Christoph > > ? > > [0] http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519 > > [1] http://cr.openjdk.java.net/~clanger/webrevs/8205432.jdk11u-dev.0/ > > ? > As I said here: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000864.html I'm working on this. In fact, I already have this in our local versions of 11.0.3+7 and 8u212-b03. I'm just waiting on approvals of https://bugs.openjdk.java.net/browse/JDK-8219890 and https://bugs.openjdk.java.net/browse/JDK-8208656 before posting. Please don't duplicate work others are doing. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Wed Apr 3 15:33:42 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 3 Apr 2019 15:33:42 +0000 Subject: [11u] RFR, RFA, discussion: JDK-8210633, JDK-8205432 (Japanese Era changes) In-Reply-To: References: Message-ID: Hi Andrew > > @Andrew Hughes : Shall I push both > patches > > to jdk11u-dev once they are reviewed and approved? You could probably > > cherry-pick them from jdk11u-dev to the CPU repository then. Or did you > > already do some work for JDK-8205432 in the CPU which you want to be > > transported the other way? Just let me know the next steps. > > > > > > > > Best regards > > > > Christoph > > > > > > > > [0] http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519 > > > > [1] http://cr.openjdk.java.net/~clanger/webrevs/8205432.jdk11u-dev.0/ > > > > > > > > As I said here: > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/000864.html > > I'm working on this. In fact, I already have this in our local versions > of 11.0.3+7 and 8u212-b03. I'm just waiting on approvals of > https://bugs.openjdk.java.net/browse/JDK-8219890 and > https://bugs.openjdk.java.net/browse/JDK-8208656 before posting. > > Please don't duplicate work others are doing. Well, I knew this but I didn't know how exactly you were planning to do it. So it was a good exercise to familiarize with the topic ?? Now I see, you're planning to also take the prerequisites JDK-8219890 and JDK-8208656. Looks like a good idea to me and probably completely saves the need for adapting the patch for JDK-8205432. ?? As for the process, then I think you should add jdk11u-critical-request to the bugs JDK-8219890 and JDK-8208656, since you'll take them into 11.0.3 via the CPU. And I guess a Fix Request comment mentioning that these bugs are prerequisite to JDK-8205432 would be nice, too. Looking forward to seeing pushes of JDK-8205432, JDK-8219890, JDK-8208656 and JDK-8205432 in jdk11u-dev then. Thanks, Christoph From gnu.andrew at redhat.com Wed Apr 3 18:00:12 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 3 Apr 2019 19:00:12 +0100 Subject: RFR: [11u] 8205432: Replace the placeholder Japanese era name Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8205432 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.01/ This is a largely clean backport with some minor adjustments, as mentioned in Christoph's e-mail [0]: make/data/cldr/common/main/ja.xml -> applied against src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ja.xml (file has moved) make/data/cldr/common/main/root.xml -> applied against src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/root.xml (file has moved) test/jdk/java/time/test/java/time/format/TestNonIsoFormatter.java -> copyright hunk failed as date is already 2019 from previous era fix test/jdk/java/util/Calendar/JapaneseLenientEraTest.java -> copyright hunk failed as date is already 2019 from previous era fix The remaining changes Christoph mentions are no longer applicable due to other backports: * The missing TestScripts tests mentioned in Christoph's e-mail are now present, thanks to the backport of JDK-8208656 and the patch applies cleanly to them. * The missing China test in test/jdk/java/util/Calendar/JapaneseEraNameTest.java was added by the backport of JDK-8219890 and the patch applies cleanly after that. [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000901.html Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Wed Apr 3 18:41:29 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 3 Apr 2019 18:41:29 +0000 Subject: [11u] 8205432: Replace the placeholder Japanese era name In-Reply-To: References: Message-ID: Looks good. Paul ?On 4/3/19, 11:02 AM, "jdk-updates-dev on behalf of Andrew John Hughes" wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8205432 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.01/ This is a largely clean backport with some minor adjustments, as mentioned in Christoph's e-mail [0]: make/data/cldr/common/main/ja.xml -> applied against src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ja.xml (file has moved) make/data/cldr/common/main/root.xml -> applied against src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/root.xml (file has moved) test/jdk/java/time/test/java/time/format/TestNonIsoFormatter.java -> copyright hunk failed as date is already 2019 from previous era fix test/jdk/java/util/Calendar/JapaneseLenientEraTest.java -> copyright hunk failed as date is already 2019 from previous era fix The remaining changes Christoph mentions are no longer applicable due to other backports: * The missing TestScripts tests mentioned in Christoph's e-mail are now present, thanks to the backport of JDK-8208656 and the patch applies cleanly to them. * The missing China test in test/jdk/java/util/Calendar/JapaneseEraNameTest.java was added by the backport of JDK-8219890 and the patch applies cleanly after that. [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000901.html Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Wed Apr 3 19:48:19 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 3 Apr 2019 19:48:19 +0000 Subject: RFR: [11u] 8205432: Replace the placeholder Japanese era name In-Reply-To: References: Message-ID: +1 ?? > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew John Hughes > Sent: Mittwoch, 3. April 2019 20:00 > To: 'jdk-updates-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RFR: [11u] 8205432: Replace the placeholder Japanese era name > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205432 > Webrev: > https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.01/ > > This is a largely clean backport with some minor adjustments, as > mentioned in Christoph's e-mail [0]: > > make/data/cldr/common/main/ja.xml -> applied against > src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ja.x > ml > (file has moved) > > make/data/cldr/common/main/root.xml -> applied against > src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/roo > t.xml > (file has moved) > > test/jdk/java/time/test/java/time/format/TestNonIsoFormatter.java -> > copyright hunk failed as date is already 2019 from previous era fix > > test/jdk/java/util/Calendar/JapaneseLenientEraTest.java -> copyright > hunk failed as date is already 2019 from previous era fix > > The remaining changes Christoph mentions are no longer applicable due to > other backports: > > * The missing TestScripts tests mentioned in Christoph's e-mail are now > present, thanks to the backport of JDK-8208656 and the patch applies > cleanly to them. > > * The missing China test in > test/jdk/java/util/Calendar/JapaneseEraNameTest.java was added by the > backport of JDK-8219890 and the patch applies cleanly after that. > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/000901.html > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Apr 3 20:59:16 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 3 Apr 2019 21:59:16 +0100 Subject: RFR: [11u] 8205432: Replace the placeholder Japanese era name In-Reply-To: References: Message-ID: <2ca4b1a6-3b53-6046-8284-f73799213e0e@redhat.com> On 03/04/2019 20:48, Langer, Christoph wrote: > +1 ?? > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Andrew John Hughes >> Sent: Mittwoch, 3. April 2019 20:00 >> To: 'jdk-updates-dev at openjdk.java.net' > dev at openjdk.java.net> >> Subject: RFR: [11u] 8205432: Replace the placeholder Japanese era name >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8205432 >> Webrev: >> https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.01/ >> >> This is a largely clean backport with some minor adjustments, as >> mentioned in Christoph's e-mail [0]: >> >> make/data/cldr/common/main/ja.xml -> applied against >> src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ja.x >> ml >> (file has moved) >> >> make/data/cldr/common/main/root.xml -> applied against >> src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/roo >> t.xml >> (file has moved) >> >> test/jdk/java/time/test/java/time/format/TestNonIsoFormatter.java -> >> copyright hunk failed as date is already 2019 from previous era fix >> >> test/jdk/java/util/Calendar/JapaneseLenientEraTest.java -> copyright >> hunk failed as date is already 2019 from previous era fix >> >> The remaining changes Christoph mentions are no longer applicable due to >> other backports: >> >> * The missing TestScripts tests mentioned in Christoph's e-mail are now >> present, thanks to the backport of JDK-8208656 and the patch applies >> cleanly to them. >> >> * The missing China test in >> test/jdk/java/util/Calendar/JapaneseEraNameTest.java was added by the >> backport of JDK-8219890 and the patch applies cleanly after that. >> >> [0] >> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- >> April/000901.html >> >> Thanks, >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> https://keybase.io/gnu_andrew > Thanks guys :-) Pushed: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/952508675ebd -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Apr 4 03:11:10 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 4 Apr 2019 04:11:10 +0100 Subject: OpenJDK 11.0.3+6 EA Released Message-ID: <9e39a349-7a61-0396-eca1-a3f44a7d9096@redhat.com> I've made available an early access source bundle for 11.0.3, based on the freeze point of jdk-11.0.3+6: https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.3+6.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.3+6.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: c1726b42751cfd01bc7a17b8e3664d86f20b6bfc15fc6f7374bd03c81c7f9845 openjdk-11.0.3+6.tar.xz caca88f069cee3e553e7d6dd6b7321f5d85a3d5c8a6c2e412ebeae0ecff01693 openjdk-11.0.3+6.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.3+6.sha256 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Thu Apr 4 10:38:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 4 Apr 2019 12:38:53 +0200 Subject: [11u, 12u] RFR (S) 8221870: use driver to run CtwRunner in applications/ctw tests Message-ID: Original test bug: https://bugs.openjdk.java.net/browse/JDK-8221870 This significantly improves memory utilization for CTW tests by using one less VM per TEST_JOB. Since tests are regenerated, it also catches new modules that were not covered by CTW testing before. Again, since this is regenerated and requires some manual fiddling to cover java_base_2, java_desktop_2, and removing modules with no Java classes, it needs separate review. 12u fix: http://cr.openjdk.java.net/~shade/8221870/webrev.12u.01/ 11u fix: http://cr.openjdk.java.net/~shade/8221870/webrev.11u.01/ Testing: applications/ctw/modules on Linux x86_64 {fastdebug,release} -- Thanks, -Aleksey From igor.ignatyev at oracle.com Thu Apr 4 17:25:14 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 4 Apr 2019 10:25:14 -0700 Subject: [11u, 12u] RFR (S) 8221870: use driver to run CtwRunner in applications/ctw tests In-Reply-To: References: Message-ID: <34355645-A305-490B-8ABF-0AAEA1F776FD@oracle.com> Hi Aleksey, both webrevs look good to me. -- Igor > On Apr 4, 2019, at 3:38 AM, Aleksey Shipilev wrote: > > Original test bug: > https://bugs.openjdk.java.net/browse/JDK-8221870 > > This significantly improves memory utilization for CTW tests by using one less VM per TEST_JOB. > Since tests are regenerated, it also catches new modules that were not covered by CTW testing > before. Again, since this is regenerated and requires some manual fiddling to cover java_base_2, > java_desktop_2, and removing modules with no Java classes, it needs separate review. > > 12u fix: > http://cr.openjdk.java.net/~shade/8221870/webrev.12u.01/ > 11u fix: > http://cr.openjdk.java.net/~shade/8221870/webrev.11u.01/ > > Testing: applications/ctw/modules on Linux x86_64 {fastdebug,release} > > -- > Thanks, > -Aleksey > > From shade at redhat.com Fri Apr 5 08:57:18 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 5 Apr 2019 10:57:18 +0200 Subject: [11u, 12u] RFR (S) 8221870: use driver to run CtwRunner in applications/ctw tests In-Reply-To: <34355645-A305-490B-8ABF-0AAEA1F776FD@oracle.com> References: <34355645-A305-490B-8ABF-0AAEA1F776FD@oracle.com> Message-ID: On 4/4/19 7:25 PM, Igor Ignatyev wrote: > both webrevs look good to me. Thanks, I pushed to 11u, and wait for 12u maintainer approval. -Aleksey >> 12u fix: >> http://cr.openjdk.java.net/~shade/8221870/webrev.12u.01/ >> >> >> 11u fix: >> http://cr.openjdk.java.net/~shade/8221870/webrev.11u.01/ From goetz.lindenmaier at sap.com Fri Apr 5 12:55:26 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 5 Apr 2019 12:55:26 +0000 Subject: [jdk11u-dev]: 8219918: ProblemList hotspot tests failing in SAP testing. Message-ID: Hi, I would like to downport ProblemListing some tests for aix. Unfortunately, the context in the ProblemList changed, so I need a most trivial review: Jdk11u-dev webrev: http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/04-downport_jdk11/ original webrev: http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/03/ jdk change: http://hg.openjdk.java.net/jdk/jdk/rev/b34bcfbcc2fd bug: https://bugs.openjdk.java.net/browse/JDK-8219918 Best regards, Goetz. From hohensee at amazon.com Fri Apr 5 13:26:02 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 5 Apr 2019 13:26:02 +0000 Subject: [jdk11u-dev]: 8219918: ProblemList hotspot tests failing in SAP testing. In-Reply-To: References: Message-ID: Looks good, and trivial. Paul ?On 4/5/19, 5:57 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" wrote: Hi, I would like to downport ProblemListing some tests for aix. Unfortunately, the context in the ProblemList changed, so I need a most trivial review: Jdk11u-dev webrev: http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/04-downport_jdk11/ original webrev: http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/03/ jdk change: http://hg.openjdk.java.net/jdk/jdk/rev/b34bcfbcc2fd bug: https://bugs.openjdk.java.net/browse/JDK-8219918 Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Apr 8 07:37:13 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Apr 2019 07:37:13 +0000 Subject: [jdk11u-dev]: 8219918: ProblemList hotspot tests failing in SAP testing. In-Reply-To: References: Message-ID: Thanks, Paul! Best regards, Goetz. > -----Original Message----- > From: Hohensee, Paul > Sent: Freitag, 5. April 2019 15:26 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [jdk11u-dev]: 8219918: ProblemList hotspot tests failing in SAP > testing. > > Looks good, and trivial. > > Paul > > ?On 4/5/19, 5:57 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" updates-dev-bounces at openjdk.java.net on behalf of > goetz.lindenmaier at sap.com> wrote: > > Hi, > > I would like to downport ProblemListing some tests for aix. > > Unfortunately, the context in the ProblemList changed, so > I need a most trivial review: > Jdk11u-dev webrev: > http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/04- > downport_jdk11/ > original webrev: > http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/03/ > jdk change: > http://hg.openjdk.java.net/jdk/jdk/rev/b34bcfbcc2fd > bug: > https://bugs.openjdk.java.net/browse/JDK-8219918 > > Best regards, > Goetz. > From christoph.langer at sap.com Tue Apr 9 12:43:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 9 Apr 2019 12:43:10 +0000 Subject: Classify JDK-8219890 and JDK-8208656 as critical in JBS Message-ID: Hi Andrew, I can see that the changes for JDK-8219890 [0] and JDK-8208656 [1] have been pushed to jdk8u-dev and jdk11u-dev in the meanwhile. These are most probably prerequisites of the Japanese era update JDK-8205432 [2] that comes with the JDK 8u212 and JDK 11.0.3 CPUs. Can you confirm that? Since I strongly believe so, I have added "jdk11u-critical-request" and "jdk8u-critical-request" to both plus a fix request comment that states its relation to JDK-8205432. I think we should make sure that public fixes which get integrated into the CPU repositories and will hence get merged on the release day are flagged as "critical-yes". This will bring them up in the relevant JBS views, e.g. [3] for jdk8u and [4] for jdk11u and downstream providers of OpenJDK can easily check which public changes will be included on top of the last public tag and get merged in on the release day. Thanks & best regards Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8219890 [1] https://bugs.openjdk.java.net/browse/JDK-8208656 [2] https://bugs.openjdk.java.net/browse/JDK-8205432 [3] https://bugs.openjdk.java.net/issues/?filter=36562 [4] https://bugs.openjdk.java.net/issues/?filter=36558 From gnu.andrew at redhat.com Tue Apr 9 17:48:39 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 9 Apr 2019 18:48:39 +0100 Subject: Classify JDK-8219890 and JDK-8208656 as critical in JBS In-Reply-To: References: Message-ID: <4457948b-4bf5-c2ee-0148-4ceb00ea04fd@redhat.com> On 09/04/2019 13:43, Langer, Christoph wrote: > Hi Andrew, > > ? > > I can see that the changes for JDK-8219890 [0] and JDK-8208656 [1] have > been pushed to jdk8u-dev and jdk11u-dev in the meanwhile. > > ? > > These are most probably prerequisites of the Japanese era update > JDK-8205432 [2] that comes with the JDK 8u212 and JDK 11.0.3 CPUs. Can > you confirm that? They are. It would be a little easier to answer such questions if you included the summaries so I know which bugs you're referring to. All these numbers are pretty meaningless. > > ? > > Since I strongly believe so, I have added ?jdk11u-critical-request? and > ?jdk8u-critical-request? to both plus a fix request comment that states > its relation to JDK-8205432. > > ? > > I think we should make sure that public fixes which get integrated into > the CPU repositories and will hence get merged on the release day are > flagged as ?critical-yes?. This will bring them up in the relevant JBS > views, e.g. [3] for jdk8u and [4] for jdk11u and downstream providers of > OpenJDK can easily check which public changes will be included on top of > the last public tag and get merged in on the release day. I've assumed jdkx-critical-request to be relevant during the period between branch and freeze. Changes after freeze will be posted, reviewed and approved in bulk (as Oracle did with the full set). It is uncommon for any of these changes to be public. These Japanese changes are unusual in that they had to wait until the era name was announced on 2019-04-01. Most of the changes after freeze are not visible bugs to which I can apply such a label, and, where we can, it may also be confusing to apply the critical label and then push to the -dev tree. They can't be pushed to the main tree because they are preceded by embargoed changes. For downstream providers who are members of the vulnerability group, I have provided an exact list of what is included after the freeze. I think that's clearer than trying to work it out from the bug database, which will inevitably be incomplete. Those who are not members of the group can not know the full set of changes in the final release until the unembargo date. So, in short, I don't have a strong objection to using the tag for these later changes, but they are not going to provide a complete picture of the release. If they did, we would just be pushing the changes directly to the main tree. > > ? > > Thanks & best regards > > Christoph > > ? > > [0] https://bugs.openjdk.java.net/browse/JDK-8219890 > > [1] https://bugs.openjdk.java.net/browse/JDK-8208656 > > [2] https://bugs.openjdk.java.net/browse/JDK-8205432 > > [3] https://bugs.openjdk.java.net/issues/?filter=36562 > > [4] https://bugs.openjdk.java.net/issues/?filter=36558 > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Wed Apr 10 08:05:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 10 Apr 2019 08:05:48 +0000 Subject: Classify JDK-8219890 and JDK-8208656 as critical in JBS In-Reply-To: <4457948b-4bf5-c2ee-0148-4ceb00ea04fd@redhat.com> References: <4457948b-4bf5-c2ee-0148-4ceb00ea04fd@redhat.com> Message-ID: Hi Andrew, > > I can see that the changes for JDK-8219890 [0] and JDK-8208656 [1] have > > been pushed to jdk8u-dev and jdk11u-dev in the meanwhile. > > > > > > > > These are most probably prerequisites of the Japanese era update > > JDK-8205432 [2] that comes with the JDK 8u212 and JDK 11.0.3 CPUs. Can > > you confirm that? > > They are. > > It would be a little easier to answer such questions if you included the > summaries so I know which bugs you're referring to. All these numbers > are pretty meaningless. OK, right, will try to remember next time. ?? > > > > Since I strongly believe so, I have added ?jdk11u-critical-request? and > > ?jdk8u-critical-request? to both plus a fix request comment that states > > its relation to JDK-8205432. > > > > > > > > I think we should make sure that public fixes which get integrated into > > the CPU repositories and will hence get merged on the release day are > > flagged as ?critical-yes?. This will bring them up in the relevant JBS > > views, e.g. [3] for jdk8u and [4] for jdk11u and downstream providers of > > OpenJDK can easily check which public changes will be included on top of > > the last public tag and get merged in on the release day. > > I've assumed jdkx-critical-request to be relevant during the period > between branch and freeze. > > Changes after freeze will be posted, reviewed and approved in bulk (as > Oracle did with the full set). It is uncommon for any of these changes > to be public. These Japanese changes are unusual in that they had to > wait until the era name was announced on 2019-04-01. Most of the changes > after freeze are not visible bugs to which I can apply such a label, > and, where we can, it may also be confusing to apply the critical label > and then push to the -dev tree. They can't be pushed to the main tree > because they are preceded by embargoed changes. > > For downstream providers who are members of the vulnerability group, I > have provided an exact list of what is included after the freeze. I > think that's clearer than trying to work it out from the bug database, > which will inevitably be incomplete. Those who are not members of the > group can not know the full set of changes in the final release until > the unembargo date. > > So, in short, I don't have a strong objection to using the tag for these > later changes, but they are not going to provide a complete picture of > the release. If they did, we would just be pushing the changes directly > to the main tree. I can see your points. That's a bit of a process discussion I guess. ?? So, right, most of the changes after freeze are probably embargoed changes to invisible bugs. However, there will also be some public fixes, e.g. prerequisites to other CPU changes or fixes that we need to pull into a CPU for other reasons, such as the Japanese era. The latter were somewhat special in that they were pushed to jdk8u-dev and jdk11u-dev as well instead of waiting for the merge back from CPU. It's also good that you provide the full list of changes to the vulnerability group, which for sure would be the only way to get a complete picture. However, for the public JBS part I'd like to have some tagging to the visible bugs that go into a CPU. I think the "critical" labels would be a good way to do this. This of course will not mean that a change can/will be pushed to the dev codelines in advance such as the Japanese era stuff. But these tags will give the complete picture when comparing the contents of the OpenJDK community release with the Oracle release. And, the information about public bugs being part of a CPU was always visible for Oracle updates via the JBS backport items. Though you could not see the actual fix obviously. Maybe there's some feedback from other people about this? Thanks Christoph From christoph.langer at sap.com Wed Apr 10 08:31:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 10 Apr 2019 08:31:05 +0000 Subject: [11u]: JDK-8210739 Calling JSpinner's setFont with null throws NullPointerException not in 11.0.3 Message-ID: Hi, I want to make you aware of the following: As per the diff filter OpenJDK 11.0.3 vs. Oracle 11.0.3 [0], the issue JDK-8210739 ?Calling JSpinner's setFont with null throws NullPointerException? [1] is part of Oracle?s update but not in the OpenJDK version. OpenJDK would have it in 11.0.4. Since we have the fix in jdk11u-dev already, we might consider it to be integrated into the CPU. But it might also be fine to have it later in 11.0.4. @andrew(s) please do whatever you think is best ?? Thanks Christoph [0] https://bugs.openjdk.java.net/issues/?filter=36366 [1] https://bugs.openjdk.java.net/browse/JDK-8210739 From shade at redhat.com Wed Apr 10 09:41:02 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 10 Apr 2019 11:41:02 +0200 Subject: [11u] RFR (M) 8217647: JFR: recordings on 32-bit systems unreadable Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8217647 Original fix: http://hg.openjdk.java.net/jdk/jdk/rev/0abec72a3ac2 Patch applies to 12u cleanly, but not to 11u. There are two problems: a) Missing files, I just skipped them: unable to find 'src/hotspot/share/jfr/recorder/repository/jfrChunkRotation.cpp' for patching unable to find 'src/hotspot/share/jfr/recorder/repository/jfrChunkRotation.hpp' for patching b) Conflict in jfrJniMethod.cpp. Patch wants this: NO_TRANSITION(void, jfr_set_file_notification(JNIEnv* env, jobject jvm, jlong threshold)) - JfrChunkRotation::set_threshold((intptr_t)threshold); + JfrChunkRotation::set_threshold(threshold); NO_TRANSITION_END ...but the 11u code is: NO_TRANSITION(void, jfr_set_file_notification(JNIEnv* env, jobject jvm, jlong threshold)) JfrChunkSizeNotifier::set_chunk_size_threshold((size_t)threshold); NO_TRANSITION_END ...and I think it is correct, since it matches the actual JfrChunkSizeNotifier signature in 11u: static void set_chunk_size_threshold(size_t bytes); ...so I skipped that one too. 11u webrev: http://cr.openjdk.java.net/~shade/8217647/webrev.11u.01/ Testing: jdk/jfr on Linux {x86_32, x86_64} -- used to fail in 32 bit, now fully passes -- Thanks, -Aleksey From dms at samersoff.net Wed Apr 10 12:09:49 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Wed, 10 Apr 2019 15:09:49 +0300 Subject: [11u] RFR (M) 8217647: JFR: recordings on 32-bit systems unreadable In-Reply-To: References: Message-ID: Aleksey, The fix looks good to me. -Dmitry On 10.04.2019 12:41, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8217647 > > Original fix: > http://hg.openjdk.java.net/jdk/jdk/rev/0abec72a3ac2 > > Patch applies to 12u cleanly, but not to 11u. There are two problems: > > a) Missing files, I just skipped them: > unable to find 'src/hotspot/share/jfr/recorder/repository/jfrChunkRotation.cpp' for patching > unable to find 'src/hotspot/share/jfr/recorder/repository/jfrChunkRotation.hpp' for patching > > b) Conflict in jfrJniMethod.cpp. Patch wants this: > > NO_TRANSITION(void, jfr_set_file_notification(JNIEnv* env, jobject jvm, jlong threshold)) > - JfrChunkRotation::set_threshold((intptr_t)threshold); > + JfrChunkRotation::set_threshold(threshold); > NO_TRANSITION_END > > ...but the 11u code is: > > NO_TRANSITION(void, jfr_set_file_notification(JNIEnv* env, jobject jvm, jlong threshold)) > JfrChunkSizeNotifier::set_chunk_size_threshold((size_t)threshold); > NO_TRANSITION_END > > ...and I think it is correct, since it matches the actual JfrChunkSizeNotifier signature in 11u: > static void set_chunk_size_threshold(size_t bytes); > > ...so I skipped that one too. > > 11u webrev: > http://cr.openjdk.java.net/~shade/8217647/webrev.11u.01/ > > Testing: jdk/jfr on Linux {x86_32, x86_64} -- used to fail in 32 bit, now fully passes > From goetz.lindenmaier at sap.com Wed Apr 10 12:22:00 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 10 Apr 2019 12:22:00 +0000 Subject: [ping]: Timeline for 11.0.4 development Message-ID: Hi, Any further comments on this? Should we put these dates on the wiki page? http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000866.html to repeate my initial mail: I propose to explicitly state the following dates on https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u As for 11.0.3, I can do the builds, tests and tags proposed here until RC phase. JDK 11.0.4 timeline * March 2019 jdk11u-dev forest open * Tuesday, April 30: Branch jdk11u-dev to jdk11u * Wednesday, Mai 1 2019: Tag 11.0.4+1 * Wendesday, Mai 29 2019: Tag 11.0.4+5 RDP2 * Wednesday June 26 2019: Tag 11.0.4+9 RC phase (code freeze) * Mid July 2019 GA JDK 11.0.5 timeline * Wednesday, Mai 1 2019 Tag 11.0.5+0 in jdk11u-dev, Forest open for development. Best regards, Goetz. > The dates I proposed here: > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/000866.html > seem to have basic consensus. > I took your mail > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/000873.html > as an approval so far. Andrew Hughes and Christoph have agreed, > too, as I understand. > > Could you please, as a project lead, confirm that we > will act upon this schedule? > > Then Christoph will put it on the webpage. > If it's on the webpage, I hope the dates get more visibility. If then > any concerns are raised, we can still update them. > > Best regards, > Goetz. > > > -----Original Message----- > > From: Andrew Haley > > Sent: Mittwoch, 3. April 2019 10:32 > > To: Lindenmaier, Goetz ; 'Andrew John > Hughes' > > ; jdk-updates-dev at openjdk.java.net > > Subject: Re: Timeline for 11.0.4 development > > > > On 4/2/19 10:09 PM, Lindenmaier, Goetz wrote: > > > I proposed the tagging date here, and didn't get any objections: > > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > > February/000648.html > > > > This has happened a couple of times now: people have posted something, > > received no objections, and taken it as consent. That is not how > > things work. We proceed by consensus: that is, we try to reach an > > agreement that a substantial majority of us are happy with. > > > > I realize that getting people to reply can be painful, but that's the > > only way to achieve a consensus. > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Wed Apr 10 15:32:54 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 10 Apr 2019 16:32:54 +0100 Subject: Classify JDK-8219890 and JDK-8208656 as critical in JBS In-Reply-To: References: <4457948b-4bf5-c2ee-0148-4ceb00ea04fd@redhat.com> Message-ID: On 10/04/2019 09:05, Langer, Christoph wrote: snip... > > However, for the public JBS part I'd like to have some tagging to the visible bugs that go into a CPU. I think the "critical" labels would be a good way to do this. This of course will not mean that a change can/will be pushed to the dev codelines in advance such as the Japanese era stuff. But these tags will give the complete picture when comparing the contents of the OpenJDK community release with the Oracle release. As I say, I have no real issue with this either way. And, the information about public bugs being part of a CPU was always visible for Oracle updates via the JBS backport items. Though you could not see the actual fix obviously. Yeah, you're not going to have that in this case as I can't push to jdk8u without rebasing the entire CPU (the CPU patches appear before the Japanese fixes & the imminent performance regression fix) > > Maybe there's some feedback from other people about this? > > Thanks > Christoph > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Thu Apr 11 14:02:57 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 11 Apr 2019 14:02:57 +0000 Subject: RFR(M): jdk11u-dev backport 8205611: Improve the wording of LinkageErrors to include module and class loader information Message-ID: Hi, I would like to backport 8205611. Unfortunately, it does not apply clean, as 8212937, a fix that came after 8205611, was already downported. I needed changes at two places: Deleting obsolete java_lang_ClassLoader::describe_external() does not apply because 8212937 changed in this function. See http://cr.openjdk.java.net/~goetz/wr19/8205611-exMsg_LinkageError/webrev/src/hotspot/share/classfile/javaClasses.cpp.udiff.html Further the exception message in duplicateParentLE/Test.java had to be adapted. New webrev for 11u-dev: http://cr.openjdk.java.net/~goetz/wr19/8205611-exMsg_LinkageError/webrev/ Original change: http://hg.openjdk.java.net/jdk/jdk12/rev/bef02342d179 Original bug: https://bugs.openjdk.java.net/browse/JDK-8205611 The conflicting change in jdk12: http://hg.openjdk.java.net/jdk/jdk12/rev/de25152e5ec4 And downported to jdk11: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8687668b33da https://bugs.openjdk.java.net/browse/JDK-8212937 See also the original review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033325.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-July/033409.html Best regards, Goetz. From patrick at os.amperecomputing.com Fri Apr 12 07:24:14 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Fri, 12 Apr 2019 07:24:14 +0000 Subject: RFR: 8222334: java -Xss0 triggers StackOverflowError Message-ID: Hi, Please review this patch. The problem is that the launcher does a check on the input -Xss and ensure it >=64K for the initial thread, while vm has another function to determine whether the input stack size is big enough to future threads, such as cgc_thread, vm_thread, java_thead etc. However if -Xss0, the initial thread is created with stack size 64K, while others use hotspot/system default sizes, which would trigger StackOverflowError. We could either fine tune the threshold 64K to be a bigger one, or have the initial thread created with system defaults that may be what the user expects. This patch chooses the second solution, to avoid potential side-effect of the first. This can be reproduced with 10, 11, 12 too, so I cc'ed jdk-updates-dev here. More details please refer to the ticket. JBS: https://bugs.openjdk.java.net/browse/JDK-8222334 Webrev: http://cr.openjdk.java.net/~qpzhang/8222334/webrev.01/ Thanks for David's comments in Jira. Regards Patrick From david.holmes at oracle.com Fri Apr 12 07:42:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Apr 2019 17:42:42 +1000 Subject: RFR: 8222334: java -Xss0 triggers StackOverflowError In-Reply-To: References: Message-ID: Hi Patrick, Please takes this to core-libs-dev for review. Thanks, David On 12/04/2019 5:24 pm, Patrick Zhang OS wrote: > Hi, > > Please review this patch. > > The problem is that the launcher does a check on the input -Xss and > ensure it >=64K for the initial thread, while vm has another function to > determine whether the input stack size is big enough to future threads, > such as cgc_thread, vm_thread, java_thead etc. However if -Xss0, the > initial thread is created with stack size 64K, while others use > hotspot/system default sizes, which would trigger StackOverflowError. We > could either fine tune the threshold 64K to be a bigger one, or have the > initial thread created with system defaults that may be what the user > expects. This patch chooses the second solution, to avoid potential > side-effect of the first. > > This can be reproduced with 10, 11, 12 too, so I cc?ed jdk-updates-dev here. > > More details please refer to the ticket. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8222334 > > Webrev: http://cr.openjdk.java.net/~qpzhang/8222334/webrev.01/ > > Thanks for David?s comments in Jira. > > Regards > > Patrick > From gnu.andrew at redhat.com Fri Apr 12 17:05:32 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 12 Apr 2019 18:05:32 +0100 Subject: [11u]: JDK-8210739 Calling JSpinner's setFont with null throws NullPointerException not in 11.0.3 In-Reply-To: References: Message-ID: On 10/04/2019 09:31, Langer, Christoph wrote: > Hi, > > ? > > I want to make you aware of the following: > > ? > > As per the diff filter OpenJDK 11.0.3 vs. Oracle 11.0.3 [0], the issue > JDK-8210739 ?Calling JSpinner's setFont with null throws > NullPointerException? [1] is part of Oracle?s update but not in the > OpenJDK version. OpenJDK would have it in 11.0.4. > > ? > > Since we have the fix in jdk11u-dev already, we might consider it to be > integrated into the CPU. But it might also be fine to have it later in > 11.0.4. @andrew(s) please do whatever you think is best ?? > > ? > > Thanks > > Christoph > > ? > > [0] https://bugs.openjdk.java.net/issues/?filter=36366 > > [1] https://bugs.openjdk.java.net/browse/JDK-8210739 > > ? > This looks like a similar case to what we've just encountered with 8u [0], where it appears in a build after the GA one (or so I assume from the b31 numbering). This has caused a lot of confusion in the past with our customers, where they wonder why it is marked as fixed in a certain release, but not in the build they have. I'm not sure if we generally want to try and mirror this post-GA addition process in OpenJDK or not. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009092.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Fri Apr 12 17:20:57 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Apr 2019 17:20:57 +0000 Subject: RFR(M): jdk11u-dev backport 8205611: Improve the wording of LinkageErrors to include module and class loader information In-Reply-To: References: Message-ID: <2183FC12-27E9-420C-8906-35138923D8CB@amazon.com> Looks good. I applied the patch and the modified tests pass on my osx laptop. Paul ?On 4/11/19, 7:04 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" wrote: Hi, I would like to backport 8205611. Unfortunately, it does not apply clean, as 8212937, a fix that came after 8205611, was already downported. I needed changes at two places: Deleting obsolete java_lang_ClassLoader::describe_external() does not apply because 8212937 changed in this function. See http://cr.openjdk.java.net/~goetz/wr19/8205611-exMsg_LinkageError/webrev/src/hotspot/share/classfile/javaClasses.cpp.udiff.html Further the exception message in duplicateParentLE/Test.java had to be adapted. New webrev for 11u-dev: http://cr.openjdk.java.net/~goetz/wr19/8205611-exMsg_LinkageError/webrev/ Original change: http://hg.openjdk.java.net/jdk/jdk12/rev/bef02342d179 Original bug: https://bugs.openjdk.java.net/browse/JDK-8205611 The conflicting change in jdk12: http://hg.openjdk.java.net/jdk/jdk12/rev/de25152e5ec4 And downported to jdk11: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8687668b33da https://bugs.openjdk.java.net/browse/JDK-8212937 See also the original review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033325.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-July/033409.html Best regards, Goetz. From ivan.gerasimov at oracle.com Fri Apr 12 19:29:33 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 12 Apr 2019 12:29:33 -0700 Subject: [12u] RFR : 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack + JDK-8222078, JDK-8222082, JDK-8222111 Message-ID: <382a5e15-3529-0ffa-95ff-434b58211675@oracle.com> Hello! This is request to review the combined backport for the four listed bugs (the later three are the test fixes). The first fix had to be slightly modified: 1) The spec change was removed from AccessibleObject.java, 2) The method jdk.test.lib.Platform.sharedLibraryPathVariableName(), which is used in the regression test was added (this method was introduced with the fix for JDK-8216265 , which is not feasible to backport). Would you please review and approve? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8221530 WEBREV: http://cr.openjdk.java.net/~igerasim/8221530/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From mandy.chung at oracle.com Sat Apr 13 09:35:38 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 13 Apr 2019 17:35:38 +0800 Subject: [12u] RFR : 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack + JDK-8222078, JDK-8222082, JDK-8222111 In-Reply-To: <382a5e15-3529-0ffa-95ff-434b58211675@oracle.com> References: <382a5e15-3529-0ffa-95ff-434b58211675@oracle.com> Message-ID: <257b5a0f-cf33-2c6a-eb40-1c0cb1a761c6@oracle.com> On 4/13/19 3:29 AM, Ivan Gerasimov wrote: > Hello! > > This is request to review the combined backport for the four listed > bugs (the later three are the test fixes). > > The first fix had to be slightly modified: > 1) The spec change was removed from AccessibleObject.java, > 2) The method jdk.test.lib.Platform.sharedLibraryPathVariableName(), > which is used in the regression test was added (this method was > introduced with the fix for JDK-8216265 > , which is not > feasible to backport). > > Would you please review and approve? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8221530 > WEBREV: http://cr.openjdk.java.net/~igerasim/8221530/00/webrev/ > The backport looks good to me. Mandy From christoph.langer at sap.com Sat Apr 13 09:49:03 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 13 Apr 2019 09:49:03 +0000 Subject: [11u]: JDK-8210739 Calling JSpinner's setFont with null throws NullPointerException not in 11.0.3 In-Reply-To: References: Message-ID: Hi, > -----Original Message----- > From: Andrew John Hughes > Sent: Freitag, 12. April 2019 19:06 > To: Langer, Christoph ; 'jdk-updates- > dev at openjdk.java.net' ; Andrew > Haley > Subject: Re: [11u]: JDK-8210739 Calling JSpinner's setFont with null throws > NullPointerException not in 11.0.3 > > > > On 10/04/2019 09:31, Langer, Christoph wrote: > > Hi, > > > > > > > > I want to make you aware of the following: > > > > > > > > As per the diff filter OpenJDK 11.0.3 vs. Oracle 11.0.3 [0], the issue > > JDK-8210739 ?Calling JSpinner's setFont with null throws > > NullPointerException? [1] is part of Oracle?s update but not in the > > OpenJDK version. OpenJDK would have it in 11.0.4. > > > > > > > > Since we have the fix in jdk11u-dev already, we might consider it to be > > integrated into the CPU. But it might also be fine to have it later in > > 11.0.4. @andrew(s) please do whatever you think is best ?? > > > > > > > > Thanks > > > > Christoph > > > > > > > > [0] https://bugs.openjdk.java.net/issues/?filter=36366 > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8210739 > > > > > > > > This looks like a similar case to what we've just encountered with 8u > [0], where it appears in a build after the GA one (or so I assume from > the b31 numbering). > > This has caused a lot of confusion in the past with our customers, where > they wonder why it is marked as fixed in a certain release, but not in > the build they have. I'm not sure if we generally want to try and mirror > this post-GA addition process in OpenJDK or not. > > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019- > April/009092.html We can push it to jdk11u after jdk-11.0.3+7=jdk-11.0.3-ga and tag it with jdk-11.0.3+8. Shall we? /Christoph From aph at redhat.com Mon Apr 15 10:25:09 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Apr 2019 11:25:09 +0100 Subject: OpenJDK Updates Project Builds Message-ID: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> In the past Oracle provided builds of OpenJDK updates. Now that we're maintaining JDK updates outside Oracle, these are missing. There are many organizations producing OpenJDK builds, Red Hat included, all with subtle variations. As project lead, I believe that our users need pure "vanilla" binaries, fully TCK'd, equivalent to those Oracle builds, for reference and for production use. With the co-operation of AdoptOpenJDK, we now have early access preview Linux and Windows binaries (currently x86-64 only) at https://adoptopenjdk.net/upstream.html These are (for now) built and tested at Red Hat, and signed by me as Update project lead. I thank Red Hat for the use of its build and test infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for their help. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adam.farley at uk.ibm.com Mon Apr 15 10:37:01 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 15 Apr 2019 11:37:01 +0100 Subject: RFR: JDK-8221990: (Backport) Program fails when using JDK addressed by UNC path and using Security Manager Message-ID: Hi All, Sponsor requested, please. PolicyFile jtreg tests have been run, and they don't encounter new failures after the patch. Webrev: http://cr.openjdk.java.net/~afarley/8221990/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221990 Best Regards Adam Farley IBM Runtimes Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From martijnverburg at gmail.com Mon Apr 15 11:32:55 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 15 Apr 2019 12:32:55 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: Hi all, We'll also link to these builds from Adopt's home page starting from today/tomorrow. It should give the extra eyes it deserves for those looking for the unbranded / untouched builds. Cheers, Martijn On Mon, 15 Apr 2019 at 11:25, Andrew Haley wrote: > In the past Oracle provided builds of OpenJDK updates. Now that we're > maintaining JDK updates outside Oracle, these are missing. > > There are many organizations producing OpenJDK builds, Red Hat > included, all with subtle variations. As project lead, I believe that > our users need pure "vanilla" binaries, fully TCK'd, equivalent to > those Oracle builds, for reference and for production use. > > With the co-operation of AdoptOpenJDK, we now have early access > preview Linux and Windows binaries (currently x86-64 only) at > > https://adoptopenjdk.net/upstream.html > > These are (for now) built and tested at Red Hat, and signed by me as > Update project lead. I thank Red Hat for the use of its build and test > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for > their help. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From yamadamn at gmail.com Mon Apr 15 13:34:00 2019 From: yamadamn at gmail.com (Takahiro YAMADA) Date: Mon, 15 Apr 2019 22:34:00 +0900 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: Hi Andrew and Martin, Thank you for all your cooperation. I have waited for these early access builds for LTS release. But I'm afraid that the build number is old for now. e.g. JDK-8221798[1] is resolved in 8u212-b10, but I can download 8u212-b02 from the site[2]. I hope this will improve in the future. Maybe 8u212 from Oracle will release April 16 in GMT. I concern that the build might be different from your builds. Do you have any idea? [1] https://bugs.openjdk.java.net/browse/JDK-8221798 [2] https://adoptopenjdk.net/upstream.html Regards, Takahiro YAMADA 2019?4?15?(?) 20:34 Martijn Verburg : > Hi all, > > We'll also link to these builds from Adopt's home page starting from > today/tomorrow. It should give the extra eyes it deserves for those > looking for the unbranded / untouched builds. > > Cheers, > Martijn > > > On Mon, 15 Apr 2019 at 11:25, Andrew Haley wrote: > > > In the past Oracle provided builds of OpenJDK updates. Now that we're > > maintaining JDK updates outside Oracle, these are missing. > > > > There are many organizations producing OpenJDK builds, Red Hat > > included, all with subtle variations. As project lead, I believe that > > our users need pure "vanilla" binaries, fully TCK'd, equivalent to > > those Oracle builds, for reference and for production use. > > > > With the co-operation of AdoptOpenJDK, we now have early access > > preview Linux and Windows binaries (currently x86-64 only) at > > > > https://adoptopenjdk.net/upstream.html > > > > These are (for now) built and tested at Red Hat, and signed by me as > > Update project lead. I thank Red Hat for the use of its build and test > > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for > > their help. > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > From sgehwolf at redhat.com Mon Apr 15 14:19:39 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 15 Apr 2019 16:19:39 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: Hi, I'm neither Andrew, nor Martijn, but I'll try to answer regardless. On Mon, 2019-04-15 at 22:34 +0900, Takahiro YAMADA wrote: > Hi Andrew and Martin, > > Thank you for all your cooperation. > I have waited for these early access builds for LTS release. > > But I'm afraid that the build number is old for now. > e.g. JDK-8221798[1] is resolved in 8u212-b10, but I can download 8u212-b02 > from the site[2]. This is a bit confusing, I have to admit. Resolved in 8u212-b10 means it's resolved in Oracle JDK's 8u212-b10. You can see that by the "Fix Version/s" field of [1]. It's "8u212", not "openjdk8u212". The latter refers to OpenJDK fixes. There won't be an exact match with regards to build numbers going forward as we won't have any control over what Oracle does downstream. 8u212-b02 is the latest *OpenJDK* tag[i]. As to your question with regards to JDK-8205432, "Replace the placeholder Japanese era name". A backport for JDK 8u[ii] will be part of the upcoming OpenJDK 8u212 *final* release due April 16, 2019. > I hope this will improve in the future. > Maybe 8u212 from Oracle will release April 16 in GMT. > I concern that the build might be different from your builds. > Do you have any idea? We are trying to match Oracle JDK with our OpenJDK releases as much as possible. Hope this helps. Thanks, Severin [i] http://hg.openjdk.java.net/jdk8u/jdk8u/tags [ii] https://bugs.openjdk.java.net/browse/JDK-8222220 > [1] https://bugs.openjdk.java.net/browse/JDK-8221798 > [2] https://adoptopenjdk.net/upstream.html > > Regards, > Takahiro YAMADA > > 2019?4?15?(?) 20:34 Martijn Verburg : > > > Hi all, > > > > We'll also link to these builds from Adopt's home page starting from > > today/tomorrow. It should give the extra eyes it deserves for those > > looking for the unbranded / untouched builds. > > > > Cheers, > > Martijn > > > > > > On Mon, 15 Apr 2019 at 11:25, Andrew Haley wrote: > > > > > In the past Oracle provided builds of OpenJDK updates. Now that we're > > > maintaining JDK updates outside Oracle, these are missing. > > > > > > There are many organizations producing OpenJDK builds, Red Hat > > > included, all with subtle variations. As project lead, I believe that > > > our users need pure "vanilla" binaries, fully TCK'd, equivalent to > > > those Oracle builds, for reference and for production use. > > > > > > With the co-operation of AdoptOpenJDK, we now have early access > > > preview Linux and Windows binaries (currently x86-64 only) at > > > > > > https://adoptopenjdk.net/upstream.html > > > > > > These are (for now) built and tested at Red Hat, and signed by me as > > > Update project lead. I thank Red Hat for the use of its build and test > > > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for > > > their help. > > > > > > -- > > > Andrew Haley > > > Java Platform Lead Engineer > > > Red Hat UK Ltd. > > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > From martijnverburg at gmail.com Mon Apr 15 14:27:45 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 15 Apr 2019 15:27:45 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: Hi Takahiro, The official 8u212 release build (as tagged by Andrew H) will likely appear tomorrow or the day after (assuming it passes all of the testing on Red Hat's servers). Cheers, Martijn On Mon, 15 Apr 2019 at 14:34, Takahiro YAMADA wrote: > Hi Andrew and Martin, > > Thank you for all your cooperation. > I have waited for these early access builds for LTS release. > > But I'm afraid that the build number is old for now. > e.g. JDK-8221798[1] is resolved in 8u212-b10, but I can download 8u212-b02 > from the site[2]. > I hope this will improve in the future. > Maybe 8u212 from Oracle will release April 16 in GMT. > I concern that the build might be different from your builds. > Do you have any idea? > > [1] https://bugs.openjdk.java.net/browse/JDK-8221798 > [2] https://adoptopenjdk.net/upstream.html > > Regards, > Takahiro YAMADA > > 2019?4?15?(?) 20:34 Martijn Verburg : > >> Hi all, >> >> We'll also link to these builds from Adopt's home page starting from >> today/tomorrow. It should give the extra eyes it deserves for those >> looking for the unbranded / untouched builds. >> >> Cheers, >> Martijn >> >> >> On Mon, 15 Apr 2019 at 11:25, Andrew Haley wrote: >> >> > In the past Oracle provided builds of OpenJDK updates. Now that we're >> > maintaining JDK updates outside Oracle, these are missing. >> > >> > There are many organizations producing OpenJDK builds, Red Hat >> > included, all with subtle variations. As project lead, I believe that >> > our users need pure "vanilla" binaries, fully TCK'd, equivalent to >> > those Oracle builds, for reference and for production use. >> > >> > With the co-operation of AdoptOpenJDK, we now have early access >> > preview Linux and Windows binaries (currently x86-64 only) at >> > >> > https://adoptopenjdk.net/upstream.html >> > >> > These are (for now) built and tested at Red Hat, and signed by me as >> > Update project lead. I thank Red Hat for the use of its build and test >> > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for >> > their help. >> > >> > -- >> > Andrew Haley >> > Java Platform Lead Engineer >> > Red Hat UK Ltd. >> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> > >> > From christoph.langer at sap.com Mon Apr 15 15:09:38 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 15 Apr 2019 15:09:38 +0000 Subject: RFR: JDK-8221990: (Backport) Program fails when using JDK addressed by UNC path and using Security Manager In-Reply-To: References: Message-ID: Hi Adam, thanks for doing this 11u patch-request. I will sponsor it for you, once it's approved. I have added your fix request comment from the backport issue (JDK-8221990) to the original bug (JDK-8218618) and set the backport issue to fix version 11-pool. The backport will get resolved by the push. Since the patch applies cleanly (which I've verified myself), it would not have been necessary to post a webrev. Or did you do any changes in the webrev? Furthermore, it's also not necessary to create the backport bug manually. A backport issue will be created when a fix is pushed with a commit message referencing the original issue. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Adam Farley8 > Sent: Montag, 15. April 2019 12:37 > To: jdk-updates-dev at openjdk.java.net > Subject: RFR: JDK-8221990: (Backport) Program fails when using JDK > addressed by UNC path and using Security Manager > > Hi All, > > Sponsor requested, please. > > PolicyFile jtreg tests have been run, and they don't encounter new > failures after the patch. > > Webrev: http://cr.openjdk.java.net/~afarley/8221990/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221990 > > Best Regards > > Adam Farley > IBM Runtimes > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU From adam.farley at uk.ibm.com Mon Apr 15 16:07:40 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 15 Apr 2019 17:07:40 +0100 Subject: RFR: JDK-8221990: (Backport) Program fails when using JDK addressed by UNC path and using Security Manager In-Reply-To: References: Message-ID: Hi Christoph, Thanks for the sponsor offer. Much appreciated. :) No functional changes in the webrev, though I believe some of the line numbers have changed, so I added webrev anyway to avoid complications. Good to know about not needing to create a backport bug. Best Regards Adam Farley IBM Runtimes "Langer, Christoph" wrote on 15/04/2019 16:09:38: > From: "Langer, Christoph" > To: Adam Farley8 , "jdk-updates- > dev at openjdk.java.net" > Date: 15/04/2019 16:12 > Subject: RE: RFR: JDK-8221990: (Backport) Program fails when using > JDK addressed by UNC path and using Security Manager > > Hi Adam, > > thanks for doing this 11u patch-request. I will sponsor it for you, > once it's approved. > > I have added your fix request comment from the backport issue > (JDK-8221990) to the original bug (JDK-8218618) and set the backport > issue to fix version 11-pool. The backport will get resolved by the push. > > Since the patch applies cleanly (which I've verified myself), it > would not have been necessary to post a webrev. Or did you do any > changes in the webrev? Furthermore, it's also not necessary to > create the backport bug manually. A backport issue will be created > when a fix is pushed with a commit message referencing the original issue. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Adam Farley8 > > Sent: Montag, 15. April 2019 12:37 > > To: jdk-updates-dev at openjdk.java.net > > Subject: RFR: JDK-8221990: (Backport) Program fails when using JDK > > addressed by UNC path and using Security Manager > > > > Hi All, > > > > Sponsor requested, please. > > > > PolicyFile jtreg tests have been run, and they don't encounter new > > failures after the patch. > > > > Webrev: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8221990_webrev_&d=DwIFAg&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DPYwXfUdsE94iXgc5DL9SQFY8DwFn4QF4AIAwIGP_1k&s=1OOy5RodAWFWJhjs0b5ZxiWSihAQvWYx- > y3Sz_s2kKg&e= > > > > Bug: https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8221990&d=DwIFAg&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DPYwXfUdsE94iXgc5DL9SQFY8DwFn4QF4AIAwIGP_1k&s=0NeqG3FFSZlkm2V2PXnEQaGSAraBGIQFqH2b_fQ366g&e= > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From gnu.andrew at redhat.com Mon Apr 15 17:01:35 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 15 Apr 2019 18:01:35 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: On 15/04/2019 15:27, Martijn Verburg wrote: > Hi Takahiro, > > The official 8u212 release build (as tagged by Andrew H) will likely appear > tomorrow or the day after (assuming it passes all of the testing on Red > Hat's servers). > > Cheers, > Martijn > It is likely to be pretty late UK time tomorrow when Oracle lift the embargo, so it may be Wednesday for many of us before everything is out there. I'll post webrevs for the updates for 7u, 8u and 11u as soon as I see that Oracle have posted about their release publicly. As to that particular bug, it's always worth following the link back to the main parent bug: https://bugs.openjdk.java.net/browse/JDK-8205432 which shows that the change is in openjdk8u222 & 11.0.4 already. I can confirm it will be part of 7u221, 8u212 & 11.0.3 as well, but arrived too late to be posted before the CPU freeze. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Tue Apr 16 08:02:58 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 16 Apr 2019 08:02:58 +0000 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 Message-ID: Hi, we had already discovered JDK-8210739: Calling JSpinner's setFont with null throws NullPointerException [1], [2] as being fixed in 11.0.3-oracle b31, which is probably a post 11.0.3 GA build of Oracle. Another bug has been brought to our attention that had had been fixed by Oracle in an 11.0.2 post GA build b31: JDK-8210483: AssertionError in DeferredAttr at setOverloadKind caused by JDK-8203679 [3]. The issue with that bug is that it was never pushed to the jdk11u repository. Oracle has only fixed this in their internal repos. Unfortunately, it fell through all the filters because these believed it was already part of the open 11.0.2 code base and hence we didn't include it in OpenJDK 11.0.3. It has, however, been backported to 11.0.4, that is, it was pushed to jdk11u-dev. So, both bugs (JDK-8210739 and JDK-8203679) will be missing in the imminent jdk-11.0.3+7, respectively jdk-11.0.3-ga pushes. I suggest we push both of these fixes (which apply cleanly and are pretty local to their area) to jdk11u after Andrew (Hughes) has pushed the CPU changes and after that add a jdk-11.0.3+8 tag. Then, downstream vendors can chose to create another update based on the new tag if they need to deliver binary versions that include these fixes. I'll also run these fixes through our SAP test system but I don't expect any regressions. Any opinions? I've flagged both bugs with jdk11u-critical-request. If I get maintainer approval by Andrew (Haley), I would do this. Thanks Christoph [1] https://bugs.openjdk.java.net/browse/JDK-8210739 [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000920.html [3] https://bugs.openjdk.java.net/browse/JDK-8210483 From aph at redhat.com Tue Apr 16 08:40:05 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 16 Apr 2019 09:40:05 +0100 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: References: Message-ID: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com> On 4/16/19 9:02 AM, Langer, Christoph wrote: > I suggest we push both of these fixes (which apply cleanly and are > pretty local to their area) to jdk11u after Andrew (Hughes) has > pushed the CPU changes and after that add a jdk-11.0.3+8 tag. Then, > downstream vendors can chose to create another update based on the > new tag if they need to deliver binary versions that include these > fixes. I'll also run these fixes through our SAP test system but I > don't expect any regressions. > > Any opinions? Once the CPU release is out, any suitably qualified person may request pushes from 11u-dev to 11u, and anyone may make a release from 11u. I know of no reason why people should not tag intermediate releases. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Tue Apr 16 08:49:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Apr 2019 10:49:12 +0200 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: References: Message-ID: Hi Christoph, On Tue, 2019-04-16 at 08:02 +0000, Langer, Christoph wrote: > Hi, > > we had already discovered JDK-8210739: Calling JSpinner's setFont > with null throws NullPointerException [1], [2] as being fixed in > 11.0.3-oracle b31, which is probably a post 11.0.3 GA build of > Oracle. > > Another bug has been brought to our attention that had had been fixed > by Oracle in an 11.0.2 post GA build b31: JDK-8210483: AssertionError > in DeferredAttr at setOverloadKind caused by JDK-8203679 [3]. The > issue with that bug is that it was never pushed to the jdk11u > repository. Oracle has only fixed this in their internal repos. > Unfortunately, it fell through all the filters because these believed > it was already part of the open 11.0.2 code base and hence we didn't > include it in OpenJDK 11.0.3. It has, however, been backported to > 11.0.4, that is, it was pushed to jdk11u-dev. > > So, both bugs (JDK-8210739 and JDK-8203679) will be missing in the > imminent jdk-11.0.3+7, respectively jdk-11.0.3-ga pushes. > > I suggest we push both of these fixes (which apply cleanly and are > pretty local to their area) to jdk11u after Andrew (Hughes) has > pushed the CPU changes and after that add a jdk-11.0.3+8 tag. Then, > downstream vendors can chose to create another update based on the > new tag if they need to deliver binary versions that include these > fixes. I'll also run these fixes through our SAP test system but I > don't expect any regressions. > > Any opinions? Here is one :) JDK-8210739: Calling JSpinner's setFont with null throws NullPointerException This bug is present in JDK 9 and better. It's a P3 bug. It's been around for a long time. JDK-8210483: AssertionError in DeferredAttr at setOverloadKind caused by JDK-8203679 This bug is present in JDK 11 ea b18 and onwards. It's a P2 bug, but got filed on September 4, 2018. So it has been around for a while too. I don't see why either of the two would have to be in any asynchronous release upstream. Shipping it with the 11.0.4 release in July should be sufficient for both, IMO. Post the 11.0.3 freeze, regular jdk11u-dev => jdk11u merges will happen, EA builds[i] produced. So if somebody really needs the fix urgently they might go with an EA upstream build. That's my understanding of the upstream situation. Downstream vendors, on the other hand, can pick-and-choose however they like. If they find certain bugs critical enough, they can spin their own releases. So to me this is business as usual. There will always be bugs which will slip releases. With the current Oracle JDK vs OpenJDK situation there cannot be a 100% match between the two no matter how hard we try. It'll be close, sure, but not a 100% match. My $0.02 Thanks, Severin [i] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000933.html > I've flagged both bugs with jdk11u-critical-request. If I get > maintainer approval by Andrew (Haley), I would do this. > > Thanks > Christoph > > [1] https://bugs.openjdk.java.net/browse/JDK-8210739 > [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000920.html > [3] https://bugs.openjdk.java.net/browse/JDK-8210483 > From shade at redhat.com Tue Apr 16 11:38:19 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 16 Apr 2019 13:38:19 +0200 Subject: [11u] RFR 8188133: C2: Static field accesses in clinit can trigger deoptimizations Message-ID: <56a46cfd-14c4-e1c6-c76b-542f6f0c8504@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8188133 Original fix: http://hg.openjdk.java.net/jdk/jdk/rev/d620a4a1d5ed The patch does not apply to 11u cleanly due to a different patch context in bytecodeInfo.cpp. The changed lines in the patch itself seem to be the same as the original. 11u webrev: http://cr.openjdk.java.net/~shade/8188133/wevrev.11u.01/ Testing: benchmark from the bug, tier1 -- Thanks, -Aleksey From martin.doerr at sap.com Tue Apr 16 12:13:38 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 16 Apr 2019 12:13:38 +0000 Subject: [11u] RFR 8188133: C2: Static field accesses in clinit can trigger deoptimizations In-Reply-To: <56a46cfd-14c4-e1c6-c76b-542f6f0c8504@redhat.com> References: <56a46cfd-14c4-e1c6-c76b-542f6f0c8504@redhat.com> Message-ID: Hi Aleksey, this looks good. Thanks for backporting. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev On Behalf Of Aleksey Shipilev Sent: Dienstag, 16. April 2019 13:38 To: hotspot compiler ; jdk-updates-dev at openjdk.java.net Subject: [11u] RFR 8188133: C2: Static field accesses in clinit can trigger deoptimizations Original bug: https://bugs.openjdk.java.net/browse/JDK-8188133 Original fix: http://hg.openjdk.java.net/jdk/jdk/rev/d620a4a1d5ed The patch does not apply to 11u cleanly due to a different patch context in bytecodeInfo.cpp. The changed lines in the patch itself seem to be the same as the original. 11u webrev: http://cr.openjdk.java.net/~shade/8188133/wevrev.11u.01/ Testing: benchmark from the bug, tier1 -- Thanks, -Aleksey From vladimir.kozlov at oracle.com Tue Apr 16 14:19:06 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Apr 2019 07:19:06 -0700 Subject: [11u] RFR 8188133: C2: Static field accesses in clinit can trigger deoptimizations In-Reply-To: <56a46cfd-14c4-e1c6-c76b-542f6f0c8504@redhat.com> References: <56a46cfd-14c4-e1c6-c76b-542f6f0c8504@redhat.com> Message-ID: <45401d25-5b1f-5dc0-0efe-56bee8e520e2@oracle.com> Looks good. Vladimir K On 4/16/19 4:38 AM, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8188133 > > Original fix: > http://hg.openjdk.java.net/jdk/jdk/rev/d620a4a1d5ed > > The patch does not apply to 11u cleanly due to a different patch context in bytecodeInfo.cpp. The > changed lines in the patch itself seem to be the same as the original. > > 11u webrev: > http://cr.openjdk.java.net/~shade/8188133/wevrev.11u.01/ > > Testing: benchmark from the bug, tier1 > From shade at redhat.com Tue Apr 16 16:05:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 16 Apr 2019 18:05:58 +0200 Subject: [11u] RFR 8219974: REDO JDK-8219492: Restore static callsite resolution for the current class Message-ID: <369bf309-c547-f59c-608b-17b872638602@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8219974 Original fix; http://hg.openjdk.java.net/jdk/jdk/rev/77343f5c85cb Patch applies almost cleanly, but the code in 11u misses the rename to "*_unsafe_anonymous*" [1], which means we need to use the older variant of it. 11u webrev: http://cr.openjdk.java.net/~shade/8219974/webrev.11u.01/ Testing: clj -A:user timings (a bit better), tier1 -- Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8209301 From dalibor.topic at oracle.com Tue Apr 16 17:31:07 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 16 Apr 2019 19:31:07 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: <6092753a-f4d0-da63-6b84-5565f652b75e@oracle.com> On 15.04.2019 16:19, Severin Gehwolf wrote: >> I hope this will improve in the future. Maybe 8u212 from Oracle >> will release April 16 in GMT. I concern that the build might be >> different from your builds. Do you have any idea? > > We are trying to match Oracle JDK with our OpenJDK releases as much > as possible. Fwiw, the functional equivalence between Oracle JDK and OpenJDK only started with JDK 11, and holds only for as long as Oracle maintains a particular update series (i.e. at least six months). Once Oracle stops participating, other developers still developing the updates in OpenJDK may and typically will make their own, often different decisions about the timing, scope and suitability of features, enhancements and bug fixes to include in the 'OpenJDK updates' source code going forward, so functional equivalence should not be expected. Historically, once Oracle stops participating in the development of an update release in OpenJDK, it tends to quickly become different from the Oracle JDK releases. There are multiple reasons for that: * OpenJDK 8u source code is available under an open source license, so changes are possible and should be expected. Different organizations will prioritize different changes and work on different schedules. * Considering that feature and bug fix differences already exist between various downstream builds of OpenJDK 8u outside of Oracle, and some of them contain dozens or more additional changes for various reasons, it's not really possible for them not to be different from Oracle JDK releases or from each other. * Different organizations may care about different sets of platforms and functionality. At Oracle, the set of supported platforms for Oracle JDK 8 is documented at https://www.oracle.com/technetwork/java/javase/certconfig-2095354.html . The set of actively supported platforms within OpenJDK 8u may overlap in some ways, miss other platforms available in Oracle JDK, but on the other hand also add additional ones, depending on what the current configuration of contributors is at any given time. For example, as OpenJFX contributors have moved on to newer releases decoupled from the JDK, there are no OpenJDK contributors left willing to maintain OpenJFX 8 further. Relying on OpenJDK 8 updates as a runtime for JavaFX applications could therefore become a challenge going forward. * Different organizations may make different technological evolution choices. For example, a non-trivial part of the effort around updates is keeping HotSpot in great shape from one release to next. If an organization's focus is on reducing the amount of work they spend on backporting changes from later releases it might be appealing for them to move to later versions of HotSpot, adjusting the code in the process to work within the context of the Java SE 8 specification and users' expectations (such as handling removed VM flags, for example). On the other hand, if their priority is to provide a stable HotSpot platform with similar behavioral characteristics between releases, they'll try to minimize the amount of changes. Those two approaches are obviously mutually exclusive. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Apr 16 19:49:14 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 16 Apr 2019 21:49:14 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> On 15.04.2019 12:25, Andrew Haley wrote: > we now have early access > preview Linux and Windows binaries (currently x86-64 only) at > > https://adoptopenjdk.net/upstream.html I would suggest using the version nomenclature per JEP 322, i.e. "A version string is a version number, $VNUM, possibly followed by pre-release, build, and other optional information, one of: $VNUM(-$PRE)?\+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)? where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build number, and $OPT is optional build information." i.e. 11.0.3-ea+6, for example. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From gnu.andrew at redhat.com Tue Apr 16 21:36:37 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 16 Apr 2019 22:36:37 +0100 Subject: OpenJDK 11.0.3 Released Message-ID: We are pleased to announce the release of OpenJDK 11.0.3. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.3+7.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.3+7.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: ed6e40fc3f81e3c2350d445d631e014aef3a411252539a70b85905e9306e8a6e openjdk-11.0.3+7.tar.xz 0d25921b720d28881b5ab3baa8e85040827ac522c34fc0a7eb9ad1f64a12eccb openjdk-11.0.3+7.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.3+7.sha256 What's New? =========== New in OpenJDK 11.0.3: * Security fixes - S8211936, CVE-2019-2602: Better String parsing - S8214809: CDS storage improvements - S8218453, CVE-2019-2698: More dynamic RMI interactions * Other changes - S8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system - S8165675: Trace event for thread park has incorrect unit for timeout - S8172695: (scanner) java/util/Scanner/ScanTest.java fails - S8187364: Unable to enter zero width non-joiner (ZWNJ) symbol in Swing text component - S8197398: (zipfs) Files.walkFileTree walk indefinitelly while processing JAR file with "/" as a directory inside. - S8200109: NMT: diff_malloc_site assert(early->flags() == current->flags(), "Must be the same memory type") - S8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object - S8204142: AWT hang occurs when sequenced events arrive out of sequence in multiple AppContexts - S8205432: Replace the placeholder Japanese era name - S8206120: Add test cases for lenient Japanese era parsing - S8207070: Webstart app popup on wrong screen in a one-screen setup changing to multi-monitor - S8207258: Distrust TLS server certificates anchored by Symantec Root CAs - S8207760: SAXException: Invalid UTF-16 surrogate detected: d83c ? - S8207829: FlightRecorderMXBeanImpl is leaking the first classloader which calls it - S8207849: Allow the addition of more number to the Java version string - S8208275: C2 crash in Node::add_req(Node*) - S8208656: Move java/util/Calendar/CalendarTestScripts tests into OpenJDK - S8209615: ParseError in XMLEventReader on a valid input - S8209758: 2 classes with same name G1PrintCollectionSetClosure cause crash when logging is enabled - S8209960: -Xlog:jfr* doesn't work with the JFR - S8210192: Hsperf counter ParNew::CMS should be ParNew:CMS - S8210394: (zipfs) jdk/nio/zipfs/ZFSTests.java rootdir.zip: The process cannot access the file because it is being used by another process - S8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values - S8210874: Test for JDK-8209615 - S8210974: No extensions debug log for ClientHello - S8210989: RSASSA-PSS certificate cannot be selected for client auth on TLSv1.2 - S8211049: Second parameter of "initialize" method is not used - S8211064: [AArch64] Interpreter and c1 don't correctly handle jboolean results in native calls - S8211100: hotspot C1 issue with comparing long numbers on x86 32-bit - S8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean - S8211267: StackOverflowError happened by TextField.setFont(...) - S8211295: DriverManager.getConnection fails when called from com.sun.rowset.JdbcRowSetImpl - S8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value - S8211382: ISO2022JP and GB18030 NIO converter issues - S8211398: Square character support for the Japanese new era - S8211698: Crash in C2 compiled code during execution of double array heavy processing code - S8211765: JarFile constructor throws undocumented exception - S8211787: javax/net/ssl/TLSCommon/TLSTest.java throws java.net.SocketTimeoutException: Read timed out - S8211821: PrintStringTableStatistics crashes JVM - S8212173: Thread._stack_base/_stack_size initialized too late for new threads - S8212232: Wrong metadata for the configuration of the cutoff for old object sample events - S8212233: javadoc fails on jdk12 with "The code being documented uses modules but the packages defined in $URL are in the unnamed module." - S8212885: TLS 1.3 resumed session does not retain peer certificate chain - S8212941: Support new Japanese era in java.time.chrono.JapaneseEra - S8213183: InputMethod cannot be used after its restarting - S8213202: Possible race condition in TLS 1.3 session resumption - S8213419: C2 may hang in MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1 - S8213421: Line number information for execution samples always 0 - S8213583: Error while opening the JFileChooser when desktop contains shortcuts pointing to deleted files - S8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace - S8213782: NullPointerException in sun.security.ssl.OutputRecord.changeWriteCiphers - S8213829: Remove circular dependency between g1CollectedHeap and g1ConcurrentMark - S8213952: Relax DNSName restriction as per RFC 1123 - S8213966: The ZGC JFR events should be marked as experimental - S8213983: [macosx] Keyboard shortcut ?cmd +`? stops working properly if popup window is displayed - S8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler - S8214100: use of keystore probing results in unnecessary exception thrown - S8214118: HeapRegions marked as archive even if CDS mapping fails - S8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry - S8214129: SSL session resumption/SNI with TLS1.2 causes StackOverflowError - S8214189: test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactLConstantTest.java fails on Windows x64 when run with -XX:-TieredCompilation - S8214206: Fix for JDK-8213419 is broken on 32-bit - S8214339: SSLSocketImpl erroneously wraps SocketException - S8214352: C1: Unnecessary "compilation bailout: block join failed" with JVMTI - S8214451: PPC64/s390: Clean up unused CRC32 prototype and function - S8214513: A PKCS12 keystore from Java 8 using custom PBE parameters cannot be read in Java 11 - S8214688: TLS 1.3 session resumption with hello retry request failed with "illegal_parameter" - S8214827: Incorrect call ClassLoaders.toFileURL("jrt:/java.compiler") - S8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode - S8215175: Inconsistencies in JFR event metadata - S8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails - S8215317: [GRAAL] unit test CheckGraalIntrinsics failed after 8213754 - S8215330: javax.xml.catalog.CatalogResolverImpl: GroupEntry.matchURI fails to match - S8215362: JFR GTest JfrTestNetworkUtilization fails - S8215397: jsig.c missing classpath exception - S8215727: Restore JFR thread sampler loop to old / previous behavior - S8215947: JVM crash with -XX:+DumpSharedSpaces - S8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults - S8215962: Support ThreadPriorityPolicy mode 1 for non-root users on linux/bsd - S8216049: stringTable::intern creates redundant String when looking up existing one - S8216060: [PPC64] Vector CRC implementation should be used by interpreter and be faster for short arrays - S8216280: Allow later Symantec Policy distrust date for two Apple SubCAs - S8216302: StackTraceElement::fill_in can use cached Class.name - S8216308: StackTraceElement::fill_in can use injected Class source-file - S8216350: AArch64: monitor unlock fast path not called - S8216546: Support new Japanese era in java.lang.Character for Java SE 11 - S8216578: Remove unused/obsolete method in JFR code - S8216965: crash in freetypeScaler.c CopyBW2Grey8 - S8217014: Epsilon should not ignore Metadata GC causes - S8217315: Proper units should print more significant digits - S8217321: [TESTBUG] utilities/test_globalDefinitions.cpp should use _LP64, not LP64 - S8217342: Build failed with excluding JFR - S8217378: UseCriticalCMSThreadPriority is broken - S8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails without IPv6 - S8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize - S8217459: [PPC64] Cleanup non-vector version of CRC32 - S8217471: [TESTBUG] gc/epsilon/TestClasses.java fails on some platforms - OOME Metaspace - S8217520: Remove vm.opt.MaxGCPauseMillis == "null" from TestOldGenCollectionUsage.java - S8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883 - S8217597: [TESTBUG] old version docker does not support --cpus - S8217609: New era placeholder not recognized by java.text.SimpleDateFormat - S8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI calls. - S8217657: Move the test for default value of jdk.includeInExceptions into own test - S8217994: os::print_hex_dump should be more resilient against unreadable memory - S8218156: "jcmd VM.metaspace basic" misreports free chunk space - S8218192: Remove copy constructor for MemRegion - S8218915: Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points - S8219251: Langtools tests default memory size needs to be 768m - S8219260: Default number of test jobs needs to be consistently calculated - S8219461: Bump update version for OpenJDK jdk11.0.3 - S8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" - S8219651: compiler/ciReplay/TestServerVM.java is failing on windows - S8219714: [testbug] com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java must pass classpath to subprocess - S8219789: [TESTBUG] TestOptionsWithRanges.java produces hs_err_pidXXXXX.log file for VMThreadStackSize=9007199254740991 - S8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales - S8220283: ZGC fails to build on GCC 4.4.7: ATTRIBUTE_ALIGNED compatibility issue - S8220294: ZGC fails to build on GCC 4.4.7: Type parameter issue - S8221769: Revert JDK-8221767 mistakenly pushed to jdk11u 11.0.3 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Apr 16 21:54:45 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 16 Apr 2019 22:54:45 +0100 Subject: [RFR] [11u] 11.0.3+7 Message-ID: OpenJDK 11.0.3 has been released: http://bitly.com/oj1103 Here are the remaining changes for the jdk11u repository: Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.3/ Changes: - S8205432: Replace the placeholder Japanese era name - S8208656: Move java/util/Calendar/CalendarTestScripts tests into OpenJDK - S8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values - S8211936: Better String parsing - S8214809: CDS storage improvements - S8218453: More dynamic RMI interactions - S8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales The result is tagged 11.0.3+7 and 11.0.3-ga. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Tue Apr 16 22:00:54 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 16 Apr 2019 22:00:54 +0000 Subject: [RFR] [11u] 11.0.3+7 In-Reply-To: References: Message-ID: Hi Andrew, this looks good to me. Thanks for doing this so quickly after unembargo ?? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew John Hughes > Sent: Dienstag, 16. April 2019 23:55 > To: 'jdk-updates-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: [RFR] [11u] 11.0.3+7 > > OpenJDK 11.0.3 has been released: http://bitly.com/oj1103 > > Here are the remaining changes for the jdk11u repository: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.3/ > > Changes: > - S8205432: Replace the placeholder Japanese era name > - S8208656: Move java/util/Calendar/CalendarTestScripts tests into > OpenJDK > - S8210633: Cannot parse JapaneseDate string with > DateTimeFormatterBuilder Mapped-values > - S8211936: Better String parsing > - S8214809: CDS storage improvements > - S8218453: More dynamic RMI interactions > - S8219890: Calendar.getDisplayName() returns empty string for new > Japanese Era on some locales > > The result is tagged 11.0.3+7 and 11.0.3-ga. > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From shade at redhat.com Tue Apr 16 22:02:17 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 17 Apr 2019 00:02:17 +0200 Subject: [RFR] [11u] 11.0.3+7 In-Reply-To: References: Message-ID: <29b4ba0e-ad5b-06df-6cc5-52e636ab48af@redhat.com> On 4/16/19 11:54 PM, Andrew John Hughes wrote: > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.3/ This looks good to me. I spot-checked three CVE fixes against the patches that were pushed to 12u. -Aleksey From gnu.andrew at redhat.com Tue Apr 16 22:21:09 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 16 Apr 2019 23:21:09 +0100 Subject: [RFR] [11u] 11.0.3+7 In-Reply-To: <29b4ba0e-ad5b-06df-6cc5-52e636ab48af@redhat.com> References: <29b4ba0e-ad5b-06df-6cc5-52e636ab48af@redhat.com> Message-ID: <72170161-d635-d539-aea4-5eea81011d47@redhat.com> On 16/04/2019 23:02, Aleksey Shipilev wrote: > On 4/16/19 11:54 PM, Andrew John Hughes wrote: >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.3/ > > This looks good to me. I spot-checked three CVE fixes against the patches that were pushed to 12u. > > -Aleksey > Pushed. Thanks for the quick review, guys. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From philip.m.jones at siemens.com Wed Apr 17 06:54:02 2019 From: philip.m.jones at siemens.com (Jones, Philip) Date: Wed, 17 Apr 2019 06:54:02 +0000 Subject: OpenJDK 11.0.3 Released In-Reply-To: References: Message-ID: <3C3FEEEFE127B940BB0F5FADB28060413C565E30@DEKOMMBX001.net.plm.eds.com> Andrew Can I check the CVEs referenced below? Oracle put out their update a few hours later and the Java items they pulled out refer to two CVEs https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html#AppendixJAVA CVE# Product Component Protocol Remote Exploit without Auth.? CVSS VERSION 3.0 RISK (see Risk Matrix Definitions) Supported Versions Affected Notes Base Score Attack Vector Attack Complex Privs Req'd User Interact Scope Confid- entiality Inte- grity Avail- ability CVE-2019-2602 Java SE, Java SE Embedded Libraries Multiple Yes 7.5 Network Low None None Un- changed None None High Java SE: 7u211, 8u202, 11.0.2, 12; Java SE Embedded: 8u201 See Note 3 CVE-2019-2684 Java SE, Java SE Embedded RMI Multiple Yes 5.9 Network High None None Un- changed None High None Java SE: 7u211, 8u202, 11.0.2, 12; Java SE Embedded: 8u201 See Note 1 and your email refers to 3 security fixes and also has two CVEs New in OpenJDK 11.0.3: * Security fixes - S8211936, CVE-2019-2602: Better String parsing - S8214809: CDS storage improvements - S8218453, CVE-2019-2698: More dynamic RMI interactions The first, CVE-2019-2602, matches up exactly. The second Oracle announced CVE, CVE-2019-2684, does not occur in your email. On https://access.redhat.com/security/cve/cve-2019-2684 there is detail of this and it says: Bugzilla:1700564: CVE-2019-2684 OpenJDK: Incorrect skeleton selection in RMI registry server-side dispatch handling (RMI, 8218453) All that matches up with the third fix you list, so RMI and 8218453 all tie up, but the CVE you refer to is CVE-2019-2698. The detail for that https://access.redhat.com/security/cve/cve-2019-2698 says: Bugzilla:1700447: CVE-2019-2698 OpenJDK: Font layout engine out of bounds access setCurrGlyphID() (2D, 8219022) So is a different issue. Regards Philip -----Original Message----- From: jdk-updates-dev On Behalf Of Andrew John Hughes Sent: 16 April 2019 22:37 To: 'jdk-updates-dev at openjdk.java.net' Subject: OpenJDK 11.0.3 Released ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. From philip.m.jones at siemens.com Wed Apr 17 07:13:20 2019 From: philip.m.jones at siemens.com (Jones, Philip) Date: Wed, 17 Apr 2019 07:13:20 +0000 Subject: OpenJDK 11.0.3 Released In-Reply-To: References: Message-ID: <3C3FEEEFE127B940BB0F5FADB28060413C565E61@DEKOMMBX001.net.plm.eds.com> Sorry, re-formatting to make it readable as plain text Andrew Can I check the CVEs referenced below? Oracle put out their update a few hours later and the Java items they pulled out refer to two CVEs https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html#AppendixJAVA CVE-2019-2602 Java SE, Java SE Embedded Libraries CVE-2019-2684 Java SE, Java SE Embedded RMI and your email refers to 3 security fixes and also has two CVEs New in OpenJDK 11.0.3: * Security fixes - S8211936, CVE-2019-2602: Better String parsing - S8214809: CDS storage improvements - S8218453, CVE-2019-2698: More dynamic RMI interactions The first, CVE-2019-2602, matches up exactly. The second Oracle announced CVE, CVE-2019-2684, does not occur in your email. On https://access.redhat.com/security/cve/cve-2019-2684 there is detail of this and it says: Bugzilla:1700564: CVE-2019-2684 OpenJDK: Incorrect skeleton selection in RMI registry server-side dispatch handling (RMI, 8218453) All that matches up with the third fix you list, so RMI and 8218453 all tie up, but the CVE you refer to is CVE-2019-2698. The detail for that https://access.redhat.com/security/cve/cve-2019-2698 says: Bugzilla:1700447: CVE-2019-2698 OpenJDK: Font layout engine out of bounds access setCurrGlyphID() (2D, 8219022) So is a different issue. Regards Philip ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. From sgehwolf at redhat.com Wed Apr 17 08:40:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 17 Apr 2019 10:40:58 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: On Mon, 2019-04-15 at 11:25 +0100, Andrew Haley wrote: > > https://adoptopenjdk.net/upstream.html > > These are (for now) built and tested at Red Hat, and signed by me as > Update project lead. This page now also has OpenJDK 11.0.3 GA and OpenJDK 8u212 GA binary builds for Linux x64 and Windows x64. Thanks, Severin From adinn at redhat.com Wed Apr 17 09:30:30 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 17 Apr 2019 10:30:30 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: <6092753a-f4d0-da63-6b84-5565f652b75e@oracle.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <6092753a-f4d0-da63-6b84-5565f652b75e@oracle.com> Message-ID: <94c0602c-423f-341d-63c0-fc3889efaf23@redhat.com> On 16/04/2019 18:31, Dalibor Topic wrote: > Fwiw, the functional equivalence between Oracle JDK and OpenJDK only > started with JDK 11, and holds only for as long as Oracle maintains a > particular update series (i.e. at least six months). > > Once Oracle stops participating, other developers still developing the > updates in OpenJDK may and typically will make their own, often > different decisions about the timing, scope and suitability of features, > enhancements and bug fixes to include in the 'OpenJDK updates' source > code going forward, so functional equivalence should not be expected. Just to be clear, can I take it that you are only talking about difference between Oracle's proprietary JDK11u releases and the common feature set used in all subsequent OpenJDK JDK11u update releases? Ditto for JDK8u? I ask that because your comment comes across to me as suggesting that the different JDK11u release providers (Oracle excluded) are in some danger of providing different feature sets in their releases of jdk11u. I have to disagree. I have seen, and expect to continue to see, every intention of avoiding such a state of disarray and disunity on the part of all the providers still involved in working on JDK11u (Oracle being exempt from that group). > Historically, once Oracle stops participating in the development of an > update release in OpenJDK, it tends to quickly become different from the > Oracle JDK releases. It is, of course, Oracle's legitimate choice to introduce such a divergence for their proprietary builds. I think it is unfortunate they would make such a choice rather than work with those still involved in JDK11u to ensure consistency in all releases. > There are multiple reasons for that: > > * OpenJDK 8u source code is available under an open source license, so > changes are possible and should be expected. Different organizations > will prioritize different changes and work on different schedules. Yet, it seems to me that all the organizations still involved in the JDK8u project (Oracle exempted) are striving to avoid differences in their OpenJDK releases and, where differences exist for historical reasons, to upstream a common feature set into the open repos for all to use. This seems to me to be the biggest priority that is driving the jdk8u project, after back-porting security updates (naturally). > * Considering that feature and bug fix differences already exist between > various downstream builds of OpenJDK 8u outside of Oracle, and some of > them contain dozens or more additional changes for various reasons, it's > not really possible for them not to be different from Oracle JDK > releases or from each other. That may or may not be an accurate account of why any difference might still be present. However, in my eyes at least, it does not justify the rather blithe way in which you comtemplate and excuse Oracle introducing /extra/ differences into new proprietary releases. Java is supposed to be about write once run anywhere. By pursuing its own development path in private, proprietary releases I feel that Oracle is prejudicing that very important goal. > * Different organizations may care about different sets of platforms and > functionality. At Oracle, the set of supported platforms for Oracle JDK > 8 is documented at > https://www.oracle.com/technetwork/java/javase/certconfig-2095354.html . > > The set of actively supported platforms within OpenJDK 8u may overlap in > some ways, miss other platforms available in Oracle JDK, but on the > other hand also add additional ones, depending on what the current > configuration of contributors is at any given time. Indeed Oracle has chosen only to address a subset of available platforms and also configurations. As an example of the latter, Oracle, quite legitimately, has chosen not to build the Shenandoah GC into their releases. Given that Oracle's engineers had no part to play in creating, and very little in maintaining, Shenandoah it is understandable that they might wish to avoid incurring the liability of supporting that capability in their releases. However, unfortunate as that is I still suggest there is a difference in kind between that omission and the action of /creating/ divergent behaviour on the same platform for the same configuration and selected feature set. > * Different organizations may make different technological evolution > choices. Indeed. Yet, the important point is that those currently involved in the jdk8u and jdk11u projects are working to minimize the effect of such choices on users. Of course, in all cases the TCK ensures a very large degree of compatibility between Oracle's Java releases and the corresponding OpenJDK releases so we are only talking about minor discrepancies here. However, the continuing OpenJDK JKD11u and JDK8u projects are certainly taking even such minor discrepancies very seriously. > For example, a non-trivial part of the effort around updates is keeping > HotSpot in great shape from one release to next. If an organization's > focus is on reducing the amount of work they spend on backporting > changes from later releases it might be appealing for them to move to > later versions of HotSpot, adjusting the code in the process to work > within the context of the Java SE 8 specification and users' > expectations (such as handling removed VM flags, for example). > On the other hand, if their priority is to provide a stable HotSpot > platform with similar behavioral characteristics between releases, > they'll try to minimize the amount of changes. The cost of backporting is one reason why all those currently involved the JDK11u and JDK8u projects have been working together on the latest releases to ensure we all use common patches for any backports. To me your presentation of the case belies that, suggesting that there is disunity and competition here when in fact there is co-operation and pooling of both resources and gains -- for us and for our users. n.b. I don't claim to speak here on behalf of all those still involved in the JDK11u or JDK8u projects, nor even on behalf of Red Hat. This is just my personal response to things I found to ring false in your post. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From christoph.langer at sap.com Wed Apr 17 13:17:33 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 17 Apr 2019 13:17:33 +0000 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com> References: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com> Message-ID: Hi Andrew, so, the CPU is out. May I please ask you to decide on whether these two additional fixes shall be pushed to jdk11u and an additional jdk-11.0.3+8 tag shall be done. I think the case is similar as with jdk8u212-b04. One could of course also go in the sense of Severin's mail and defer people to the 11.0.4 EA builds. But I guess it's kind of a service to the community to add the two changes on top of 11.0.3 GA since they are part of the Oracle builds as well. Thanks Christoph > -----Original Message----- > From: Andrew Haley > Sent: Dienstag, 16. April 2019 10:40 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; Andrew John Hughes > Cc: Martijn Verburg > Subject: Re: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK- > 8203679 > > On 4/16/19 9:02 AM, Langer, Christoph wrote: > > > I suggest we push both of these fixes (which apply cleanly and are > > pretty local to their area) to jdk11u after Andrew (Hughes) has > > pushed the CPU changes and after that add a jdk-11.0.3+8 tag. Then, > > downstream vendors can chose to create another update based on the > > new tag if they need to deliver binary versions that include these > > fixes. I'll also run these fixes through our SAP test system but I > > don't expect any regressions. > > > > Any opinions? > > Once the CPU release is out, any suitably qualified person may request > pushes from 11u-dev to 11u, and anyone may make a release from 11u. I > know of no reason why people should not tag intermediate releases. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Apr 17 13:49:11 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 17 Apr 2019 14:49:11 +0100 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: References: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com> Message-ID: <0e930597-3da9-429f-e916-1eb5838e8f7f@redhat.com> On 4/17/19 2:17 PM, Langer, Christoph wrote: > May I please ask you to decide on whether these two additional fixes shall be pushed to jdk11u and an additional jdk-11.0.3+8 tag shall be done. I think the case is similar as with jdk8u212-b04. At the moment I'm getting "Unexpected error. Please contact help at openjdk.java.net" from id.openjdk.java.net/console/login. I'll try again later. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gil at azul.com Wed Apr 17 14:52:03 2019 From: gil at azul.com (Gil Tene) Date: Wed, 17 Apr 2019 14:52:03 +0000 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: References: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com>, Message-ID: IMO a release is a release, and should be properly identified and tagged as such. The OpenJDK 11u project releases source code, not binaries. *If* an OpenJDK 11u project *release* is created after the OpenJDK 11.0.3 release and before the OpenJDK 11.0.4 release, it should be identified with an actual version (something better than a build number) which would show on the first line of the java -version output, and that version number should be displayed by any binary that purports to include the contents expected in that version. Changes that go into such a release should be tagged with its version. They clearly should NOT be tagged with 11.0.3, since an 11.0.3 *release* exists that does not contain them, and binary builds of that 11.0.3 release are already out. Tagging a change with a build number is an obvious oxymoron IMO. The ?basic line numbers spacing? approach of tagging with a ?far enough ahead to predict? build number gap that can be skipped to (e.g. b31 for an anticipated BPR) may technically work when binaries are only available from a single source (e.g. Oracle), but it is very hard to maintain coordination of that gap. Using the build number in that way also creates the problem of having multiple ?GA? builds of the same OpenJDK 11u version floating around, with no good way to distinguish released (?GA?ed?) builds from non released builds. E.g. what tells an end user that +7 and +31 are release builds, but +6 and +11 are not? JEP 322 has room for this sort of release-between-Releases thing with the $PATCH element in the version number. The $PATCH element is described in the JEP as ?The emergency patch-release counter, incremented only when it's necessary to produce an emergency release to fix a critical issue.?. I would argue that anything that makes us create an unplanned release of OpenJDK 11u in the 3 months between the planned 11.0.3 date and the planned 11.0.4 date should qualify under that description (as if it does not, it should wait and go into the planned release). IMO the date shown in the first line of the JEP 322 version string should also be updated if such a hypothetical release is made. The same cautionary logic applies to 8u, but there we don?t have a JEP 322 version number structure to use. IMO the proper thing to do for such unplanned releases in 8u (which I hope don?t need to use) would be to use the update number gap between e.g. the April 2019 8u212 and the July 2019 8u222 for an interim update release number (e.g. 8u216). ? Gil. > On Apr 17, 2019, at 6:18 AM, Langer, Christoph wrote: > > Hi Andrew, > > so, the CPU is out. May I please ask you to decide on whether these two additional fixes shall be pushed to jdk11u and an additional jdk-11.0.3+8 tag shall be done. I think the case is similar as with jdk8u212-b04. One could of course also go in the sense of Severin's mail and defer people to the 11.0.4 EA builds. But I guess it's kind of a service to the community to add the two changes on top of 11.0.3 GA since they are part of the Oracle builds as well. > > Thanks > Christoph > > >> -----Original Message----- >> From: Andrew Haley >> Sent: Dienstag, 16. April 2019 10:40 >> To: Langer, Christoph ; jdk-updates- >> dev at openjdk.java.net; Andrew John Hughes >> Cc: Martijn Verburg >> Subject: Re: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK- >> 8203679 >> >>> On 4/16/19 9:02 AM, Langer, Christoph wrote: >>> >>> I suggest we push both of these fixes (which apply cleanly and are >>> pretty local to their area) to jdk11u after Andrew (Hughes) has >>> pushed the CPU changes and after that add a jdk-11.0.3+8 tag. Then, >>> downstream vendors can chose to create another update based on the >>> new tag if they need to deliver binary versions that include these >>> fixes. I'll also run these fixes through our SAP test system but I >>> don't expect any regressions. >>> >>> Any opinions? >> >> Once the CPU release is out, any suitably qualified person may request >> pushes from 11u-dev to 11u, and anyone may make a release from 11u. I >> know of no reason why people should not tag intermediate releases. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Apr 17 16:33:55 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 17 Apr 2019 17:33:55 +0100 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: References: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com> Message-ID: On 4/17/19 3:52 PM, Gil Tene wrote: > IMO a release is a release, and should be properly identified and > tagged as such. The OpenJDK 11u project releases source code, not > binaries. *If* an OpenJDK 11u project *release* is created after > the OpenJDK 11.0.3 release and before the OpenJDK 11.0.4 release, it > should be identified with an actual version (something better than a > build number) which would show on the first line of the java > -version output, and that version number should be displayed by any > binary that purports to include the contents expected in that > version. Certainly. To begin with, I'd like to establish the principle, then we can talk about exactly how we get it done. Everyone makes mistakes from time to time, so it's quite possible that in the future we will need to make a point release from a release branch. So, we must not close off the ability to release (e.g.) 11.0.3.1 if we need to do so. > Changes that go into such a release should be tagged with its > version. They clearly should NOT be tagged with 11.0.3, since an > 11.0.3 *release* exists that does not contain them, and binary > builds of that 11.0.3 release are already out. Yes, that is certainly true. > Tagging a change with a build number is an obvious oxymoron IMO. The > ?basic line numbers spacing? approach of tagging with a ?far enough > ahead to predict? build number gap that can be skipped to (e.g. b31 > for an anticipated BPR) may technically work when binaries are only > available from a single source (e.g. Oracle), but it is very hard to > maintain coordination of that gap. Using the build number in that > way also creates the problem of having multiple ?GA? builds of the > same OpenJDK 11u version floating around, with no good way to > distinguish released (?GA?ed?) builds from non released > builds. E.g. what tells an end user that +7 and +31 are release > builds, but +6 and +11 are not? Agreed. > JEP 322 has room for this sort of release-between-Releases thing > with the $PATCH element in the version number. The $PATCH element is > described in the JEP as ?The emergency patch-release counter, > incremented only when it's necessary to produce an emergency release > to fix a critical issue.?. I would argue that anything that makes us > create an unplanned release of OpenJDK 11u in the 3 months between > the planned 11.0.3 date and the planned 11.0.4 date should qualify > under that description (as if it does not, it should wait and go > into the planned release). That makes very good sense. However, that language rather implies a single source of binaries (if not a single mind) and I don't want to be in the business of arguing whether a particular issue is critical enough. As long as we agree what a particular tag means, even though not all of us might want to make a particular "emergency" release, I think we're good. We have a simple choice between declaring a release branch forever closed, thus forcing people to maintain their own downstream forks (or, worse, patch sets) if they need to make changes or finding a co-ordinated way to do it. > IMO the date shown in the first line of the JEP 322 version string > should also be updated if such a hypothetical release is made. Yes. > The same cautionary logic applies to 8u, but there we don?t > have a JEP 322 version number structure to use. IMO the proper > thing to do for such unplanned releases in 8u (which I hope don?t > need to use) would be to use the update number gap between > e.g. the April 2019 8u212 and the July 2019 8u222 for an interim > update release number (e.g. 8u216). Again, yes. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Wed Apr 17 17:14:12 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 17 Apr 2019 18:14:12 +0100 Subject: OpenJDK 11.0.3 Released In-Reply-To: <3C3FEEEFE127B940BB0F5FADB28060413C565E61@DEKOMMBX001.net.plm.eds.com> References: <3C3FEEEFE127B940BB0F5FADB28060413C565E61@DEKOMMBX001.net.plm.eds.com> Message-ID: <458b398f-7f72-a5b3-441c-2cef28fef8ce@redhat.com> On 17/04/2019 08:13, Jones, Philip wrote: > Sorry, re-formatting to make it readable as plain text > > Andrew > > Can I check the CVEs referenced below? > Oracle put out their update a few hours later and the Java items they pulled out refer to two CVEs > > https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html#AppendixJAVA > > CVE-2019-2602 Java SE, Java SE Embedded Libraries > CVE-2019-2684 Java SE, Java SE Embedded RMI > > and your email refers to 3 security fixes and also has two CVEs > > New in OpenJDK 11.0.3: > * Security fixes > - S8211936, CVE-2019-2602: Better String parsing > - S8214809: CDS storage improvements > - S8218453, CVE-2019-2698: More dynamic RMI interactions > > The first, CVE-2019-2602, matches up exactly. > The second Oracle announced CVE, CVE-2019-2684, does not occur in your email. > > On https://access.redhat.com/security/cve/cve-2019-2684 there is detail of this and it says: > > Bugzilla:1700564: CVE-2019-2684 OpenJDK: Incorrect skeleton selection in RMI registry server-side dispatch handling (RMI, 8218453) > > All that matches up with the third fix you list, so RMI and 8218453 all tie up, but the CVE you refer to is CVE-2019-2698. > > The detail for that https://access.redhat.com/security/cve/cve-2019-2698 says: > > Bugzilla:1700447: CVE-2019-2698 OpenJDK: Font layout engine out of bounds access setCurrGlyphID() (2D, 8219022) > > So is a different issue. > > Regards > > Philip > ----------------- > Siemens Industry Software Limited is a limited company registered in England and Wales. > Registered number: 3476850. > Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. > Sorry, looks like a copy-and-paste error on my part. The correct ones are in the OpenJDK 8u212 release mail: http://bitly.com/oj8u212 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Apr 17 17:15:08 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 17 Apr 2019 18:15:08 +0100 Subject: OpenJDK 11.0.3 Released In-Reply-To: References: Message-ID: On 16/04/2019 22:36, Andrew John Hughes wrote: > We are pleased to announce the release of OpenJDK 11.0.3. > > The source tarball is available from: > > * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.3+7.tar.xz > > The tarball is accompanied by a digital signature available at: > > * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.3+7.tar.xz.sig > > This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): > > PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) > Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F > > SHA256 checksums: > > ed6e40fc3f81e3c2350d445d631e014aef3a411252539a70b85905e9306e8a6e > openjdk-11.0.3+7.tar.xz > 0d25921b720d28881b5ab3baa8e85040827ac522c34fc0a7eb9ad1f64a12eccb > openjdk-11.0.3+7.tar.xz.sig > > The checksums can be downloaded from: > > * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.3+7.sha256 > > What's New? > =========== > New in OpenJDK 11.0.3: > > * Security fixes > - S8211936, CVE-2019-2602: Better String parsing > - S8214809: CDS storage improvements > - S8218453, CVE-2019-2698: More dynamic RMI interactions Should be: S8218453, CVE-2019-2684: More dynamic RMI interactions as it was for 8u212... -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gil at azul.com Wed Apr 17 17:33:07 2019 From: gil at azul.com (Gil Tene) Date: Wed, 17 Apr 2019 17:33:07 +0000 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: References: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com> Message-ID: > On Apr 17, 2019, at 9:33 AM, Andrew Haley wrote: > > On 4/17/19 3:52 PM, Gil Tene wrote: > >> IMO a release is a release, and should be properly identified and >> tagged as such. The OpenJDK 11u project releases source code, not >> binaries. *If* an OpenJDK 11u project *release* is created after >> the OpenJDK 11.0.3 release and before the OpenJDK 11.0.4 release, it >> should be identified with an actual version (something better than a >> build number) which would show on the first line of the java >> -version output, and that version number should be displayed by any >> binary that purports to include the contents expected in that >> version. > > Certainly. To begin with, I'd like to establish the principle, then we > can talk about exactly how we get it done. Everyone makes mistakes > from time to time, so it's quite possible that in the future we will > need to make a point release from a release branch. So, we must not > close off the ability to release (e.g.) 11.0.3.1 if we need to do so. > >> Changes that go into such a release should be tagged with its >> version. They clearly should NOT be tagged with 11.0.3, since an >> 11.0.3 *release* exists that does not contain them, and binary >> builds of that 11.0.3 release are already out. > > Yes, that is certainly true. > >> Tagging a change with a build number is an obvious oxymoron IMO. The >> ?basic line numbers spacing? approach of tagging with a ?far enough >> ahead to predict? build number gap that can be skipped to (e.g. b31 >> for an anticipated BPR) may technically work when binaries are only >> available from a single source (e.g. Oracle), but it is very hard to >> maintain coordination of that gap. Using the build number in that >> way also creates the problem of having multiple ?GA? builds of the >> same OpenJDK 11u version floating around, with no good way to >> distinguish released (?GA?ed?) builds from non released >> builds. E.g. what tells an end user that +7 and +31 are release >> builds, but +6 and +11 are not? > > Agreed. > >> JEP 322 has room for this sort of release-between-Releases thing >> with the $PATCH element in the version number. The $PATCH element is >> described in the JEP as ?The emergency patch-release counter, >> incremented only when it's necessary to produce an emergency release >> to fix a critical issue.?. I would argue that anything that makes us >> create an unplanned release of OpenJDK 11u in the 3 months between >> the planned 11.0.3 date and the planned 11.0.4 date should qualify >> under that description (as if it does not, it should wait and go >> into the planned release). > > That makes very good sense. However, that language rather implies a > single source of binaries (if not a single mind) and I don't want to > be in the business of arguing whether a particular issue is critical > enough. As long as we agree what a particular tag means, even though > not all of us might want to make a particular "emergency" release, I > think we're good. I think that project is the place for us to coordinate and choose the expected contents of releases with specific combinations of the first 4 elements in e.g. 11.0.3.1 . The $PATCH element should be "owned" by the project, and the decision to use it and rev it should be up to the project maintainers (and ultimately the project lead), so we do have that "single mind" that makes those choices. JEP 322 leaves the 5'th element (e.g. 11.0.3.0.X) for downstream-specific identification: "The fifth and later elements of version numbers are reserved for use by downstream consumers of the JDK code base. The fifth element may be used to, e.g., identify implementor-specific patch releases." This gives us a separate place for subjective, binary-distro-specific or vendor specific choices on issuing patches or differences that are not in a project release, but are "based off of" some project release. So e.g. if a specific distro or vendor wanted to make changes after some hypothetical 10.0.3.1 project release, and before 10.0.4, but still wanted to identify their release as "includes everything in 10.0.3.1 but says nothing about 10.0.4"), they would use something like 10.0.3.1.17. I think that the JEP makes it clear that we should not expect the numbers in that 5th element position to have meaning outside of the world of a specific downstream distribution or implementor. So IMO multiple implementors can be free to use the same (and overlapping) numbers in the fifth element without sowing confusion. But we should try to avoid repurposing or using any of the other elements (the 11.0.3.0 part of 11.0.3.0.17) in non-coordinated ways. Our preference (at Azul) has been to only use the 5th element when we actually have a release that falls in between project releases from a contents perspective. E.g. we have an 11.0.2.0.101 release, but we use 11.0.2 and 11.0.3 for the things that are aligned with OpenJDK 11u 11.0.2 and 11.0.3. > > We have a simple choice between declaring a release branch forever > closed, thus forcing people to maintain their own downstream forks > (or, worse, patch sets) if they need to make changes or finding a > co-ordinated way to do it. > >> IMO the date shown in the first line of the JEP 322 version string >> should also be updated if such a hypothetical release is made. > > Yes. > >> The same cautionary logic applies to 8u, but there we don?t >> have a JEP 322 version number structure to use. IMO the proper >> thing to do for such unplanned releases in 8u (which I hope don?t >> need to use) would be to use the update number gap between >> e.g. the April 2019 8u212 and the July 2019 8u222 for an interim >> update release number (e.g. 8u216). > > Again, yes. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rob.mckenna at oracle.com Wed Apr 17 19:43:36 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 17 Apr 2019 20:43:36 +0100 Subject: [Updates Communication] jdk12.0.1 security patches pushed Message-ID: <20190417194336.GA10674@vimes> Apologies for the late notice. Security fixes for 12.0.1 were pushed last night: http://hg.openjdk.java.net/jdk-updates/jdk12u -Rob From goetz.lindenmaier at sap.com Wed Apr 17 20:55:05 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 17 Apr 2019 20:55:05 +0000 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: References: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com> , Message-ID: <9D99C7B5-4ECF-422E-A64B-8B8F2BE97A55@sap.com> Hi, I agree with Severin that these changes are not severe enough to justify a release of their own. I agree with Gil that we should bump a version digit and the date if we do so. My few cents :) Best regards, G?tz @Andrew Hughes: great the changes were pushed this timely! Thanks! > Am 17.04.2019 um 19:34 schrieb Gil Tene : > > > >> On Apr 17, 2019, at 9:33 AM, Andrew Haley wrote: >> >> On 4/17/19 3:52 PM, Gil Tene wrote: >> >>> IMO a release is a release, and should be properly identified and >>> tagged as such. The OpenJDK 11u project releases source code, not >>> binaries. *If* an OpenJDK 11u project *release* is created after >>> the OpenJDK 11.0.3 release and before the OpenJDK 11.0.4 release, it >>> should be identified with an actual version (something better than a >>> build number) which would show on the first line of the java >>> -version output, and that version number should be displayed by any >>> binary that purports to include the contents expected in that >>> version. >> >> Certainly. To begin with, I'd like to establish the principle, then we >> can talk about exactly how we get it done. Everyone makes mistakes >> from time to time, so it's quite possible that in the future we will >> need to make a point release from a release branch. So, we must not >> close off the ability to release (e.g.) 11.0.3.1 if we need to do so. >> >>> Changes that go into such a release should be tagged with its >>> version. They clearly should NOT be tagged with 11.0.3, since an >>> 11.0.3 *release* exists that does not contain them, and binary >>> builds of that 11.0.3 release are already out. >> >> Yes, that is certainly true. >> >>> Tagging a change with a build number is an obvious oxymoron IMO. The >>> ?basic line numbers spacing? approach of tagging with a ?far enough >>> ahead to predict? build number gap that can be skipped to (e.g. b31 >>> for an anticipated BPR) may technically work when binaries are only >>> available from a single source (e.g. Oracle), but it is very hard to >>> maintain coordination of that gap. Using the build number in that >>> way also creates the problem of having multiple ?GA? builds of the >>> same OpenJDK 11u version floating around, with no good way to >>> distinguish released (?GA?ed?) builds from non released >>> builds. E.g. what tells an end user that +7 and +31 are release >>> builds, but +6 and +11 are not? >> >> Agreed. >> >>> JEP 322 has room for this sort of release-between-Releases thing >>> with the $PATCH element in the version number. The $PATCH element is >>> described in the JEP as ?The emergency patch-release counter, >>> incremented only when it's necessary to produce an emergency release >>> to fix a critical issue.?. I would argue that anything that makes us >>> create an unplanned release of OpenJDK 11u in the 3 months between >>> the planned 11.0.3 date and the planned 11.0.4 date should qualify >>> under that description (as if it does not, it should wait and go >>> into the planned release). >> >> That makes very good sense. However, that language rather implies a >> single source of binaries (if not a single mind) and I don't want to >> be in the business of arguing whether a particular issue is critical >> enough. As long as we agree what a particular tag means, even though >> not all of us might want to make a particular "emergency" release, I >> think we're good. > > I think that project is the place for us to coordinate and choose the > expected contents of releases with specific combinations of the > first 4 elements in e.g. 11.0.3.1 . The $PATCH element should be > "owned" by the project, and the decision to use it and rev it should > be up to the project maintainers (and ultimately the project lead), so > we do have that "single mind" that makes those choices. > > JEP 322 leaves the 5'th element (e.g. 11.0.3.0.X) for downstream-specific > identification: > > "The fifth and later elements of version numbers are reserved for use > by downstream consumers of the JDK code base. The fifth element may > be used to, e.g., identify implementor-specific patch releases." > > This gives us a separate place for subjective, binary-distro-specific > or vendor specific choices on issuing patches or differences that are not > in a project release, but are "based off of" some project release. > > So e.g. if a specific distro or vendor wanted to make changes after > some hypothetical 10.0.3.1 project release, and before 10.0.4, but > still wanted to identify their release as "includes everything in 10.0.3.1 > but says nothing about 10.0.4"), they would use something like > 10.0.3.1.17. > > I think that the JEP makes it clear that we should not expect the > numbers in that 5th element position to have meaning outside of > the world of a specific downstream distribution or implementor. > > So IMO multiple implementors can be free to use the same > (and overlapping) numbers in the fifth element without sowing confusion. > But we should try to avoid repurposing or using any of the other > elements (the 11.0.3.0 part of 11.0.3.0.17) in non-coordinated ways. > > Our preference (at Azul) has been to only use the 5th element when > we actually have a release that falls in between project releases from > a contents perspective. E.g. we have an 11.0.2.0.101 release, but > we use 11.0.2 and 11.0.3 for the things that are aligned with > OpenJDK 11u 11.0.2 and 11.0.3. > >> >> We have a simple choice between declaring a release branch forever >> closed, thus forcing people to maintain their own downstream forks >> (or, worse, patch sets) if they need to make changes or finding a >> co-ordinated way to do it. >> >>> IMO the date shown in the first line of the JEP 322 version string >>> should also be updated if such a hypothetical release is made. >> >> Yes. >> >>> The same cautionary logic applies to 8u, but there we don?t >>> have a JEP 322 version number structure to use. IMO the proper >>> thing to do for such unplanned releases in 8u (which I hope don?t >>> need to use) would be to use the update number gap between >>> e.g. the April 2019 8u212 and the July 2019 8u222 for an interim >>> update release number (e.g. 8u216). >> >> Again, yes. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From doko at ubuntu.com Thu Apr 18 01:21:26 2019 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 18 Apr 2019 03:21:26 +0200 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: References: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com> Message-ID: On 17.04.19 19:33, Gil Tene wrote: > JEP 322 leaves the 5'th element (e.g. 11.0.3.0.X) for downstream-specific > identification: > > "The fifth and later elements of version numbers are reserved for use > by downstream consumers of the JDK code base. The fifth element may > be used to, e.g., identify implementor-specific patch releases." > > This gives us a separate place for subjective, binary-distro-specific > or vendor specific choices on issuing patches or differences that are not > in a project release, but are "based off of" some project release. > > So e.g. if a specific distro or vendor wanted to make changes after > some hypothetical 10.0.3.1 project release, and before 10.0.4, but > still wanted to identify their release as "includes everything in 10.0.3.1 > but says nothing about 10.0.4"), they would use something like > 10.0.3.1.17. > > I think that the JEP makes it clear that we should not expect the > numbers in that 5th element position to have meaning outside of > the world of a specific downstream distribution or implementor. > > So IMO multiple implementors can be free to use the same > (and overlapping) numbers in the fifth element without sowing confusion. > But we should try to avoid repurposing or using any of the other > elements (the 11.0.3.0 part of 11.0.3.0.17) in non-coordinated ways. > > Our preference (at Azul) has been to only use the 5th element when > we actually have a release that falls in between project releases from > a contents perspective. E.g. we have an 11.0.2.0.101 release, but > we use 11.0.2 and 11.0.3 for the things that are aligned with > OpenJDK 11u 11.0.2 and 11.0.3. well, I consider this fifth element a bit of nonsense, at least for distro based rpm/deb packages. Usually a package in the distro gets its version from the upstream release, and the packaging revision from the packaging changes. Adding the packaging revision doesn't make a new upstream source. Or you could have separate source versions (including the "build" number, e.g. 11.0.3+b7-2), and binary version (11.0.3.0.2), but then users are a bit confused to track back source versions from binary versions. And even then you would mix native and upstream Debian version numbers which is discouraged by Debian policy. Matthias From gil at azul.com Thu Apr 18 03:03:22 2019 From: gil at azul.com (Gil Tene) Date: Thu, 18 Apr 2019 03:03:22 +0000 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: References: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com> Message-ID: <076EBBF8-737D-4B71-B4F9-768426A0DDE9@azul.com> > On Apr 17, 2019, at 6:21 PM, Matthias Klose wrote: > > On 17.04.19 19:33, Gil Tene wrote: >> JEP 322 leaves the 5'th element (e.g. 11.0.3.0.X) for downstream-specific >> identification: >> >> "The fifth and later elements of version numbers are reserved for use >> by downstream consumers of the JDK code base. The fifth element may >> be used to, e.g., identify implementor-specific patch releases." >> >> This gives us a separate place for subjective, binary-distro-specific >> or vendor specific choices on issuing patches or differences that are not >> in a project release, but are "based off of" some project release. >> >> So e.g. if a specific distro or vendor wanted to make changes after >> some hypothetical 10.0.3.1 project release, and before 10.0.4, but >> still wanted to identify their release as "includes everything in 10.0.3.1 >> but says nothing about 10.0.4"), they would use something like >> 10.0.3.1.17. >> >> I think that the JEP makes it clear that we should not expect the >> numbers in that 5th element position to have meaning outside of >> the world of a specific downstream distribution or implementor. >> >> So IMO multiple implementors can be free to use the same >> (and overlapping) numbers in the fifth element without sowing confusion. >> But we should try to avoid repurposing or using any of the other >> elements (the 11.0.3.0 part of 11.0.3.0.17) in non-coordinated ways. >> >> Our preference (at Azul) has been to only use the 5th element when >> we actually have a release that falls in between project releases from >> a contents perspective. E.g. we have an 11.0.2.0.101 release, but >> we use 11.0.2 and 11.0.3 for the things that are aligned with >> OpenJDK 11u 11.0.2 and 11.0.3. > > well, I consider this fifth element a bit of nonsense, at least for distro based > rpm/deb packages. I have no strong opinions on whether or not the choices made in JEP322 are "good" or bad", "smart" or "nonesense", or even on what the version scheme for OpenJDK 15 might look like. I just have a strong opinion on not revisiting the matter for OpenJDK 11. > Usually a package in the distro gets its version from the > upstream release, and the packaging revision from the packaging changes. Adding > the packaging revision doesn't make a new upstream source. Or you could have > separate source versions (including the "build" number, e.g. 11.0.3+b7-2), and > binary version (11.0.3.0.2), but then users are a bit confused to track back > source versions from binary versions. And even then you would mix native and > upstream Debian version numbers which is discouraged by Debian policy. > > Matthias From christoph.langer at sap.com Thu Apr 18 07:46:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 18 Apr 2019 07:46:10 +0000 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: <9D99C7B5-4ECF-422E-A64B-8B8F2BE97A55@sap.com> References: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com> , <9D99C7B5-4ECF-422E-A64B-8B8F2BE97A55@sap.com> Message-ID: Hi, after catching up with this thread, I think Goetz' mail is a good abstract of the outcome. I would withdraw jdk11u-critical requests from JDK-8210739 and JDK-8203679 then. Unless somebody objects... ?? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Mittwoch, 17. April 2019 22:55 > To: Gil Tene > Cc: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] Re: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and > JDK-8203679 > > Hi, > > I agree with Severin that these changes are not severe enough to justify a > release of their own. > > I agree with Gil that we should bump a version digit and the date if we do so. > > My few cents :) > > Best regards, G?tz > > @Andrew Hughes: great the changes were pushed this timely! Thanks! > > > Am 17.04.2019 um 19:34 schrieb Gil Tene : > > > > > > > >> On Apr 17, 2019, at 9:33 AM, Andrew Haley wrote: > >> > >> On 4/17/19 3:52 PM, Gil Tene wrote: > >> > >>> IMO a release is a release, and should be properly identified and > >>> tagged as such. The OpenJDK 11u project releases source code, not > >>> binaries. *If* an OpenJDK 11u project *release* is created after > >>> the OpenJDK 11.0.3 release and before the OpenJDK 11.0.4 release, it > >>> should be identified with an actual version (something better than a > >>> build number) which would show on the first line of the java > >>> -version output, and that version number should be displayed by any > >>> binary that purports to include the contents expected in that > >>> version. > >> > >> Certainly. To begin with, I'd like to establish the principle, then we > >> can talk about exactly how we get it done. Everyone makes mistakes > >> from time to time, so it's quite possible that in the future we will > >> need to make a point release from a release branch. So, we must not > >> close off the ability to release (e.g.) 11.0.3.1 if we need to do so. > >> > >>> Changes that go into such a release should be tagged with its > >>> version. They clearly should NOT be tagged with 11.0.3, since an > >>> 11.0.3 *release* exists that does not contain them, and binary > >>> builds of that 11.0.3 release are already out. > >> > >> Yes, that is certainly true. > >> > >>> Tagging a change with a build number is an obvious oxymoron IMO. The > >>> ?basic line numbers spacing? approach of tagging with a ?far enough > >>> ahead to predict? build number gap that can be skipped to (e.g. b31 > >>> for an anticipated BPR) may technically work when binaries are only > >>> available from a single source (e.g. Oracle), but it is very hard to > >>> maintain coordination of that gap. Using the build number in that > >>> way also creates the problem of having multiple ?GA? builds of the > >>> same OpenJDK 11u version floating around, with no good way to > >>> distinguish released (?GA?ed?) builds from non released > >>> builds. E.g. what tells an end user that +7 and +31 are release > >>> builds, but +6 and +11 are not? > >> > >> Agreed. > >> > >>> JEP 322 has room for this sort of release-between-Releases thing > >>> with the $PATCH element in the version number. The $PATCH element is > >>> described in the JEP as ?The emergency patch-release counter, > >>> incremented only when it's necessary to produce an emergency release > >>> to fix a critical issue.?. I would argue that anything that makes us > >>> create an unplanned release of OpenJDK 11u in the 3 months between > >>> the planned 11.0.3 date and the planned 11.0.4 date should qualify > >>> under that description (as if it does not, it should wait and go > >>> into the planned release). > >> > >> That makes very good sense. However, that language rather implies a > >> single source of binaries (if not a single mind) and I don't want to > >> be in the business of arguing whether a particular issue is critical > >> enough. As long as we agree what a particular tag means, even though > >> not all of us might want to make a particular "emergency" release, I > >> think we're good. > > > > I think that project is the place for us to coordinate and choose the > > expected contents of releases with specific combinations of the > > first 4 elements in e.g. 11.0.3.1 . The $PATCH element should be > > "owned" by the project, and the decision to use it and rev it should > > be up to the project maintainers (and ultimately the project lead), so > > we do have that "single mind" that makes those choices. > > > > JEP 322 leaves the 5'th element (e.g. 11.0.3.0.X) for downstream-specific > > identification: > > > > "The fifth and later elements of version numbers are reserved for use > > by downstream consumers of the JDK code base. The fifth element may > > be used to, e.g., identify implementor-specific patch releases." > > > > This gives us a separate place for subjective, binary-distro-specific > > or vendor specific choices on issuing patches or differences that are not > > in a project release, but are "based off of" some project release. > > > > So e.g. if a specific distro or vendor wanted to make changes after > > some hypothetical 10.0.3.1 project release, and before 10.0.4, but > > still wanted to identify their release as "includes everything in 10.0.3.1 > > but says nothing about 10.0.4"), they would use something like > > 10.0.3.1.17. > > > > I think that the JEP makes it clear that we should not expect the > > numbers in that 5th element position to have meaning outside of > > the world of a specific downstream distribution or implementor. > > > > So IMO multiple implementors can be free to use the same > > (and overlapping) numbers in the fifth element without sowing confusion. > > But we should try to avoid repurposing or using any of the other > > elements (the 11.0.3.0 part of 11.0.3.0.17) in non-coordinated ways. > > > > Our preference (at Azul) has been to only use the 5th element when > > we actually have a release that falls in between project releases from > > a contents perspective. E.g. we have an 11.0.2.0.101 release, but > > we use 11.0.2 and 11.0.3 for the things that are aligned with > > OpenJDK 11u 11.0.2 and 11.0.3. > > > >> > >> We have a simple choice between declaring a release branch forever > >> closed, thus forcing people to maintain their own downstream forks > >> (or, worse, patch sets) if they need to make changes or finding a > >> co-ordinated way to do it. > >> > >>> IMO the date shown in the first line of the JEP 322 version string > >>> should also be updated if such a hypothetical release is made. > >> > >> Yes. > >> > >>> The same cautionary logic applies to 8u, but there we don?t > >>> have a JEP 322 version number structure to use. IMO the proper > >>> thing to do for such unplanned releases in 8u (which I hope don?t > >>> need to use) would be to use the update number gap between > >>> e.g. the April 2019 8u212 and the July 2019 8u222 for an interim > >>> update release number (e.g. 8u216). > >> > >> Again, yes. > >> > >> -- > >> Andrew Haley > >> Java Platform Lead Engineer > >> Red Hat UK Ltd. > >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From doko at ubuntu.com Thu Apr 18 13:46:28 2019 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 18 Apr 2019 15:46:28 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: <386ee3ee-d30f-d6a4-2ab9-3bc4c826b4b3@ubuntu.com> On 15.04.19 12:25, Andrew Haley wrote: > In the past Oracle provided builds of OpenJDK updates. Now that we're > maintaining JDK updates outside Oracle, these are missing. > > There are many organizations producing OpenJDK builds, Red Hat > included, all with subtle variations. As project lead, I believe that > our users need pure "vanilla" binaries, fully TCK'd, equivalent to > those Oracle builds, for reference and for production use. > > With the co-operation of AdoptOpenJDK, we now have early access > preview Linux and Windows binaries (currently x86-64 only) at > > https://adoptopenjdk.net/upstream.html > > These are (for now) built and tested at Red Hat, and signed by me as > Update project lead. I thank Red Hat for the use of its build and test > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for > their help. Please document how these are configured/built, including the build environment. Or is this information included in the binary packages? From sgehwolf at redhat.com Thu Apr 18 14:18:30 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Apr 2019 16:18:30 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <386ee3ee-d30f-d6a4-2ab9-3bc4c826b4b3@ubuntu.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <386ee3ee-d30f-d6a4-2ab9-3bc4c826b4b3@ubuntu.com> Message-ID: <092487ee78cc136836fcfc838f003ff400d096f4.camel@redhat.com> On Thu, 2019-04-18 at 15:46 +0200, Matthias Klose wrote: > On 15.04.19 12:25, Andrew Haley wrote: > > In the past Oracle provided builds of OpenJDK updates. Now that we're > > maintaining JDK updates outside Oracle, these are missing. > > > > There are many organizations producing OpenJDK builds, Red Hat > > included, all with subtle variations. As project lead, I believe that > > our users need pure "vanilla" binaries, fully TCK'd, equivalent to > > those Oracle builds, for reference and for production use. > > > > With the co-operation of AdoptOpenJDK, we now have early access > > preview Linux and Windows binaries (currently x86-64 only) at > > > > https://adoptopenjdk.net/upstream.html > > > > These are (for now) built and tested at Red Hat, and signed by me as > > Update project lead. I thank Red Hat for the use of its build and test > > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for > > their help. > > Please document how these are configured/built, including the build environment. > Or is this information included in the binary packages? These should have all the info you need (for Linux): https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries Thanks, Severin From hohensee at amazon.com Sat Apr 20 01:32:49 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Sat, 20 Apr 2019 01:32:49 +0000 Subject: [11u-dev] RFA: 8206955: MethodHandleProxies.asInterfaceInstance does not support default methods Message-ID: <676B221B-D062-4A60-9C97-40325EC4DD76@amazon.com> May I please have JDK-8206955 marked jdk11u-fix-yes? It was approved for jdk8u a week ago and pushed there, and needs to go into 11u as well. Thanks, Paul From martinrb at google.com Sun Apr 21 22:20:00 2019 From: martinrb at google.com (Martin Buchholz) Date: Sun, 21 Apr 2019 15:20:00 -0700 Subject: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679 In-Reply-To: References: <5bda8d49-2bca-dd1a-76cf-0c8071be1bfe@redhat.com> Message-ID: On Wed, Apr 17, 2019 at 6:22 PM Matthias Klose wrote: > > well, I consider this fifth element a bit of nonsense, at least for distro > based > rpm/deb packages. Usually a package in the distro gets its version from > the > upstream release, and the packaging revision from the packaging changes. > Adding > the packaging revision doesn't make a new upstream source. Or you could > have > separate source versions (including the "build" number, e.g. 11.0.3+b7-2), > and > binary version (11.0.3.0.2), but then users are a bit confused to track > back > source versions from binary versions. And even then you would mix native > and > upstream Debian version numbers which is discouraged by Debian policy. > Debian/Ubuntu package versions for OpenJDK work well - no reason to change. The 4th or 5th JSR 223 version number may end up being useful to others not working on an OS distro. From shade at redhat.com Mon Apr 22 10:26:34 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 22 Apr 2019 12:26:34 +0200 Subject: 11u approvals Message-ID: <581f4c1e-e7a1-37f3-3a80-694f2a57476e@redhat.com> Hi, It looks to me that 11u approvals got stuck: there are currently 33 issues pending approval [1]. I think it was accumulate during the 11.0.3 release work, but now we should get them going for builds, tests, etc. Andrew, can you please take a look? -- Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8222522?filter=36358 From epeterson at interactivebrokers.com Mon Apr 22 18:18:06 2019 From: epeterson at interactivebrokers.com (Eric Peterson) Date: Mon, 22 Apr 2019 18:18:06 +0000 Subject: OpenJDK - CPU Matrix Message-ID: <5D246673-4A6B-4B2F-A0CB-BC34310E94C7@interactivebrokers.com> Hi all, I'm wondering if there is an equivalent page for OpenJDK that tracks fixed vulnerabilities for the April release, similar to what Oracle posted for their recent CPU: https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html#AppendixJAVA I have hunted around a bit but not found anything so far. --Eric From aph at redhat.com Tue Apr 23 09:35:01 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 23 Apr 2019 10:35:01 +0100 Subject: 11u approvals In-Reply-To: <581f4c1e-e7a1-37f3-3a80-694f2a57476e@redhat.com> References: <581f4c1e-e7a1-37f3-3a80-694f2a57476e@redhat.com> Message-ID: <58a78d50-3b8f-6b9a-2fa9-29e0080f1d5c@redhat.com> On 4/22/19 11:26 AM, Aleksey Shipilev wrote: > It looks to me that 11u approvals got stuck: there are currently 33 issues pending approval [1]. I > think it was accumulate during the 11.0.3 release work, but now we should get them going for builds, > tests, etc. Andrew, can you please take a look? Done. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Tue Apr 23 09:39:17 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Apr 2019 11:39:17 +0200 Subject: 11u approvals In-Reply-To: <58a78d50-3b8f-6b9a-2fa9-29e0080f1d5c@redhat.com> References: <581f4c1e-e7a1-37f3-3a80-694f2a57476e@redhat.com> <58a78d50-3b8f-6b9a-2fa9-29e0080f1d5c@redhat.com> Message-ID: On 4/23/19 11:35 AM, Andrew Haley wrote: > On 4/22/19 11:26 AM, Aleksey Shipilev wrote: >> It looks to me that 11u approvals got stuck: there are currently 33 issues pending approval [1]. I >> think it was accumulate during the 11.0.3 release work, but now we should get them going for builds, >> tests, etc. Andrew, can you please take a look? > > Done. Thanks! -Aleksey From shade at redhat.com Tue Apr 23 09:49:24 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Apr 2019 11:49:24 +0200 Subject: [11u] RFR 8219974: REDO JDK-8219492: Restore static callsite resolution for the current class In-Reply-To: <369bf309-c547-f59c-608b-17b872638602@redhat.com> References: <369bf309-c547-f59c-608b-17b872638602@redhat.com> Message-ID: On 4/16/19 6:05 PM, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8219974 > > Original fix; > http://hg.openjdk.java.net/jdk/jdk/rev/77343f5c85cb > > Patch applies almost cleanly, but the code in 11u misses the rename to "*_unsafe_anonymous*" [1], > which means we need to use the older variant of it. > > 11u webrev: > http://cr.openjdk.java.net/~shade/8219974/webrev.11u.01/ > > Testing: clj -A:user timings (a bit better), tier1 (friendly reminder) -Aleksey From david.holmes at oracle.com Tue Apr 23 10:03:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Apr 2019 20:03:44 +1000 Subject: [11u] RFR 8219974: REDO JDK-8219492: Restore static callsite resolution for the current class In-Reply-To: References: <369bf309-c547-f59c-608b-17b872638602@redhat.com> Message-ID: Hi Aleksey, That looks exactly how I would have done it. ;-) Thanks, David On 23/04/2019 7:49 pm, Aleksey Shipilev wrote: > On 4/16/19 6:05 PM, Aleksey Shipilev wrote: >> Original bug: >> https://bugs.openjdk.java.net/browse/JDK-8219974 >> >> Original fix; >> http://hg.openjdk.java.net/jdk/jdk/rev/77343f5c85cb >> >> Patch applies almost cleanly, but the code in 11u misses the rename to "*_unsafe_anonymous*" [1], >> which means we need to use the older variant of it. >> >> 11u webrev: >> http://cr.openjdk.java.net/~shade/8219974/webrev.11u.01/ >> >> Testing: clj -A:user timings (a bit better), tier1 > > (friendly reminder) > > -Aleksey > From christoph.langer at sap.com Tue Apr 23 10:11:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 23 Apr 2019 10:11:27 +0000 Subject: 8u-critical and 11u-critical request cleanup Message-ID: Hi Andrew, as the April CPUs have been released and the July CPUs were not yet branched to jdk8u and jdk11u, I'd like to ask you to clean up the critical request labels on a few bugs. For OpenJDK 8 updates, please look at this filter: https://bugs.openjdk.java.net/issues/?filter=36564 Both bugs were part of the CPU and should hence be flagged 8u-critical-yes to reflect their actual state. For OpenJDK 11 updates, have a look here: https://bugs.openjdk.java.net/issues/?filter=36559 I think for JDK-8222397 and JDK-8170494, you have accidentally set the 11u-critical flag when approving them this morning for jdk11u-dev. And the other two bugs are Japanese era bugs being part of the April CPU, so should be flagged 11u-critical-yes. Thanks Christoph From hohensee at amazon.com Tue Apr 23 15:57:13 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Apr 2019 15:57:13 +0000 Subject: [11u-dev] RFA: 8206955: MethodHandleProxies.asInterfaceInstance does not support default methods In-Reply-To: <676B221B-D062-4A60-9C97-40325EC4DD76@amazon.com> References: <676B221B-D062-4A60-9C97-40325EC4DD76@amazon.com> Message-ID: Thanks you, Andrew. Pushed. ?On 4/19/19, 6:35 PM, "jdk-updates-dev on behalf of Hohensee, Paul" wrote: May I please have JDK-8206955 marked jdk11u-fix-yes? It was approved for jdk8u a week ago and pushed there, and needs to go into 11u as well. Thanks, Paul From shade at redhat.com Tue Apr 23 15:58:46 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Apr 2019 17:58:46 +0200 Subject: [11u] RFR 8219974: REDO JDK-8219492: Restore static callsite resolution for the current class In-Reply-To: References: <369bf309-c547-f59c-608b-17b872638602@redhat.com> Message-ID: On 4/23/19 12:03 PM, David Holmes wrote: > That looks exactly how I would have done it. ;-) Thanks! The 11u backport is now in queue. -Aleksey From patrick at os.amperecomputing.com Fri Apr 12 07:51:09 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Fri, 12 Apr 2019 07:51:09 +0000 Subject: RFR: 8222334: java -Xss0 triggers StackOverflowError In-Reply-To: References: Message-ID: Moved this to core-libs-dev for review, thanks. Dropped and bcc'ed jdk-dev and jdk-updates-dev. Regards Patrick -----Original Message----- From: David Holmes Sent: Friday, April 12, 2019 3:43 PM To: Patrick Zhang OS ; jdk-dev at openjdk.java.net Cc: jdk-updates-dev at openjdk.java.net Subject: Re: RFR: 8222334: java -Xss0 triggers StackOverflowError Hi Patrick, Please takes this to core-libs-dev for review. Thanks, David On 12/04/2019 5:24 pm, Patrick Zhang OS wrote: > Hi, > > Please review this patch. > > The problem is that the launcher does a check on the input -Xss and > ensure it >=64K for the initial thread, while vm has another function > to determine whether the input stack size is big enough to future > threads, such as cgc_thread, vm_thread, java_thead etc. However if > -Xss0, the initial thread is created with stack size 64K, while others > use hotspot/system default sizes, which would trigger > StackOverflowError. We could either fine tune the threshold 64K to be > a bigger one, or have the initial thread created with system defaults > that may be what the user expects. This patch chooses the second > solution, to avoid potential side-effect of the first. > > This can be reproduced with 10, 11, 12 too, so I cc'ed jdk-updates-dev here. > > More details please refer to the ticket. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8222334 > > Webrev: http://cr.openjdk.java.net/~qpzhang/8222334/webrev.01/ > > Thanks for David's comments in Jira. > > Regards > > Patrick > From ecki at zusammenkunft.net Mon Apr 22 19:28:13 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 22 Apr 2019 19:28:13 +0000 Subject: OpenJDK - CPU Matrix In-Reply-To: <5D246673-4A6B-4B2F-A0CB-BC34310E94C7@interactivebrokers.com> References: <5D246673-4A6B-4B2F-A0CB-BC34310E94C7@interactivebrokers.com> Message-ID: Hello Eric, the fixed CVEs and other security fixes(!) are listed in the release announcements. Not sure if there is an aggregated view on them. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009115.html (BTW it should be same for the other releases) As a personal recommendation I would always look up the associated Bugs or CVE numbers in the RedHat big tracker, in all cases I checked (in the past) it was way less secretive and more detailed (after the embargo) than the Oracle/OpenJDK JIRA. (Also Azul publishes a CVE Map for their releases, I am not sure if that document is public, I received it with subscriber access) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: jdk8u-dev im Auftrag von Eric Peterson Gesendet: Montag, April 22, 2019 8:29 PM An: jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net Betreff: OpenJDK - CPU Matrix Hi all, I'm wondering if there is an equivalent page for OpenJDK that tracks fixed vulnerabilities for the April release, similar to what Oracle posted for their recent CPU: https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html#AppendixJAVA I have hunted around a bit but not found anything so far. --Eric From pavel at azul.com Tue Apr 23 18:54:29 2019 From: pavel at azul.com (Pavel Petroshenko) Date: Tue, 23 Apr 2019 18:54:29 +0000 Subject: OpenJDK - CPU Matrix In-Reply-To: References: <5D246673-4A6B-4B2F-A0CB-BC34310E94C7@interactivebrokers.com> Message-ID: <1438249B-7441-4E26-B54F-720716EA0254@azul.com> Hello Eric, Bernd, A CVE fixes matrix for public Azul Community bundles is publicly available at https://docs.azul.com/zulu/zulurelnotes/index.htm#ZuluReleaseNotes/CA_CVE_Fixes_April19.htm Regards, Pavel On Apr 22, 2019, at 12:28 PM, Bernd Eckenfels > wrote: Hello Eric, the fixed CVEs and other security fixes(!) are listed in the release announcements. Not sure if there is an aggregated view on them. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009115.html (BTW it should be same for the other releases) As a personal recommendation I would always look up the associated Bugs or CVE numbers in the RedHat big tracker, in all cases I checked (in the past) it was way less secretive and more detailed (after the embargo) than the Oracle/OpenJDK JIRA. (Also Azul publishes a CVE Map for their releases, I am not sure if that document is public, I received it with subscriber access) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: jdk8u-dev im Auftrag von Eric Peterson Gesendet: Montag, April 22, 2019 8:29 PM An: jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net Betreff: OpenJDK - CPU Matrix Hi all, I'm wondering if there is an equivalent page for OpenJDK that tracks fixed vulnerabilities for the April release, similar to what Oracle posted for their recent CPU: https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html#AppendixJAVA I have hunted around a bit but not found anything so far. --Eric From aph at redhat.com Wed Apr 24 08:04:23 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Apr 2019 09:04:23 +0100 Subject: [11u] RFR 8188133: C2: Static field accesses in clinit can trigger deoptimizations In-Reply-To: <56a46cfd-14c4-e1c6-c76b-542f6f0c8504@redhat.com> References: <56a46cfd-14c4-e1c6-c76b-542f6f0c8504@redhat.com> Message-ID: <75959e53-e8da-8f26-b48e-51eb99b833f3@redhat.com> On 4/16/19 12:38 PM, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8188133 > > Original fix: > http://hg.openjdk.java.net/jdk/jdk/rev/d620a4a1d5ed > > The patch does not apply to 11u cleanly due to a different patch context in bytecodeInfo.cpp. The > changed lines in the patch itself seem to be the same as the original. > > 11u webrev: > http://cr.openjdk.java.net/~shade/8188133/wevrev.11u.01/ OK, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Wed Apr 24 08:29:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Apr 2019 08:29:16 +0000 Subject: [ping]: Timeline for 11.0.4 development In-Reply-To: References: Message-ID: Hi, since there was no further feedback on this, I'll update the Wiki page accordingly today. I discussed with G?tz to leave out the exact tag numbers but the dates will be as written below. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Mittwoch, 10. April 2019 14:22 > To: 'Andrew Haley' ; 'Andrew John Hughes' > ; 'jdk-updates-dev at openjdk.java.net' updates-dev at openjdk.java.net> > Subject: [CAUTION] [ping]: Timeline for 11.0.4 development > > Hi, > > Any further comments on this? Should we put these dates > on the wiki page? > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/000866.html > > to repeate my initial mail: > > I propose to explicitly state the following dates on > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > As for 11.0.3, I can do the builds, tests and tags proposed here > until RC phase. > JDK 11.0.4 timeline > > * March 2019 jdk11u-dev forest open > * Tuesday, April 30: Branch jdk11u-dev to jdk11u > * Wednesday, Mai 1 2019: Tag 11.0.4+1 > * Wendesday, Mai 29 2019: Tag 11.0.4+5 RDP2 > * Wednesday June 26 2019: Tag 11.0.4+9 RC phase (code freeze) > * Mid July 2019 GA > > JDK 11.0.5 timeline > > * Wednesday, Mai 1 2019 Tag 11.0.5+0 in jdk11u-dev, Forest open for > development. > > Best regards, > Goetz. > > > > > The dates I proposed here: > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > > April/000866.html > > seem to have basic consensus. > > I took your mail > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > > April/000873.html > > as an approval so far. Andrew Hughes and Christoph have agreed, > > too, as I understand. > > > > Could you please, as a project lead, confirm that we > > will act upon this schedule? > > > > Then Christoph will put it on the webpage. > > If it's on the webpage, I hope the dates get more visibility. If then > > any concerns are raised, we can still update them. > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: Andrew Haley > > > Sent: Mittwoch, 3. April 2019 10:32 > > > To: Lindenmaier, Goetz ; 'Andrew John > > Hughes' > > > ; jdk-updates-dev at openjdk.java.net > > > Subject: Re: Timeline for 11.0.4 development > > > > > > On 4/2/19 10:09 PM, Lindenmaier, Goetz wrote: > > > > I proposed the tagging date here, and didn't get any objections: > > > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > > > February/000648.html > > > > > > This has happened a couple of times now: people have posted > something, > > > received no objections, and taken it as consent. That is not how > > > things work. We proceed by consensus: that is, we try to reach an > > > agreement that a substantial majority of us are happy with. > > > > > > I realize that getting people to reply can be painful, but that's the > > > only way to achieve a consensus. > > > > > > -- > > > Andrew Haley > > > Java Platform Lead Engineer > > > Red Hat UK Ltd. > > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Apr 24 09:04:32 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Apr 2019 10:04:32 +0100 Subject: 8u-critical and 11u-critical request cleanup In-Reply-To: References: Message-ID: On 4/23/19 11:11 AM, Langer, Christoph wrote: > For OpenJDK 11 updates, have a look here: > https://bugs.openjdk.java.net/issues/?filter=36559 > > I think for JDK-8222397 and JDK-8170494, you have accidentally set the 11u-critical flag Which 11u-critical flag do you mean? > when approving them this morning for jdk11u-dev. And the other two bugs are Japanese era bugs being part of the April CPU, so should be flagged 11u-critical-yes. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Wed Apr 24 09:15:50 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Apr 2019 09:15:50 +0000 Subject: 8u-critical and 11u-critical request cleanup In-Reply-To: References: Message-ID: > > I think for JDK-8222397 and JDK-8170494, you have accidentally set the 11u- > critical flag > > Which 11u-critical flag do you mean? JDK-8222397 has the labels "jdk11u-critical-request" and "jdk11u-critical-yes", JDK-8170494 has "jdk11u-critical-request". I think all should be removed. As per the activity log, the "jdk11u-critical-request" were set by you yesterday. It looks to me as if it was done inadvertently... /Christoph From aph at redhat.com Wed Apr 24 09:41:44 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Apr 2019 10:41:44 +0100 Subject: 8u-critical and 11u-critical request cleanup In-Reply-To: References: Message-ID: <0a06f5bc-392b-df90-b7ee-a57bd138a04a@redhat.com> On 4/24/19 10:15 AM, Langer, Christoph wrote: > JDK-8222397 has the labels "jdk11u-critical-request" and "jdk11u-critical-yes", JDK-8170494 has "jdk11u-critical-request". I think all should be removed. As per the activity log, the "jdk11u-critical-request" were set by you yesterday. It looks to me as if it was done inadvertently... Oh, I see. OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Wed Apr 24 09:47:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Apr 2019 09:47:47 +0000 Subject: [11u]: 11.0.4 release schedule Message-ID: Hi all, I've now published the following schedule for 11.0.4 on the Wiki [0]: March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) Tuesday, April 30 2019: Branch jdk11u-dev to jdk11u Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) Wednesday, May 29 2019: RDP2 Wednesday June 26 2019: Last tag before code freeze Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) Is everyone in agreement with that? Note: It means that we'll branch next week from jdk11u-dev to jdk11u! Furthermore, I'm questioning myself, whether we want to explicitly have an RDP2 date? Pushes that target the jdk11u repo need to use the "critical" labeling and should meet the stricter rules for release stabilization anyway (see section "Fix Approvals" in the link below). Any opinions on that one? Thanks Christoph [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u From christoph.langer at sap.com Wed Apr 24 09:57:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Apr 2019 09:57:02 +0000 Subject: 8u-critical and 11u-critical request cleanup In-Reply-To: <0a06f5bc-392b-df90-b7ee-a57bd138a04a@redhat.com> References: <0a06f5bc-392b-df90-b7ee-a57bd138a04a@redhat.com> Message-ID: > On 4/24/19 10:15 AM, Langer, Christoph wrote: > > JDK-8222397 has the labels "jdk11u-critical-request" and "jdk11u-critical- > yes", JDK-8170494 has "jdk11u-critical-request". I think all should be > removed. As per the activity log, the "jdk11u-critical-request" were set by > you yesterday. It looks to me as if it was done inadvertently... > > Oh, I see. OK. Thanks, looks good now ?? From shade at redhat.com Wed Apr 24 10:01:07 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Apr 2019 12:01:07 +0200 Subject: [11u]: 11.0.4 release schedule In-Reply-To: References: Message-ID: On 4/24/19 11:47 AM, Langer, Christoph wrote: > I've now published the following schedule for 11.0.4 on the Wiki [0]: > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > Tuesday, April 30 2019: Branch jdk11u-dev to jdk11u > Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) > Wednesday, May 29 2019: RDP2 > Wednesday June 26 2019: Last tag before code freeze > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > > Is everyone in agreement with that? > > Note: It means that we'll branch next week from jdk11u-dev to jdk11u! That also means outstanding 11.0.4-oracle things are better to get to 11u-dev within a week, right? https://bugs.openjdk.java.net/issues/?filter=36409 I have my doubts about having 2.5 months gap between fork and release. That feels too early. Or maybe not, given there is a pending 13 freeze in between, and also summer vacations. > Furthermore, I'm questioning myself, whether we want to explicitly have an RDP2 date? Pushes that target the jdk11u repo need to use the "critical" labeling and should meet the stricter rules for release stabilization anyway (see section "Fix Approvals" in the link below). Any opinions on that one? IMO, if we are not pulling jdk11u-dev -> jdk11u automatically and regularly, then there is little sense in having the formal RDP2. Maintainers would have to judge if change is risky for stabilization forest, every step of the way anyway. -Aleksey From goetz.lindenmaier at sap.com Wed Apr 24 10:55:08 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 24 Apr 2019 10:55:08 +0000 Subject: [11u]: 11.0.4 release schedule In-Reply-To: References: , Message-ID: > Am 24.04.2019 um 12:03 schrieb Aleksey Shipilev : > >> On 4/24/19 11:47 AM, Langer, Christoph wrote: >> I've now published the following schedule for 11.0.4 on the Wiki [0]: >> >> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) >> Tuesday, April 30 2019: Branch jdk11u-dev to jdk11u >> Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) >> Wednesday, May 29 2019: RDP2 >> Wednesday June 26 2019: Last tag before code freeze >> Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) >> >> Is everyone in agreement with that? >> >> Note: It means that we'll branch next week from jdk11u-dev to jdk11u! > > That also means outstanding 11.0.4-oracle things are better to get to 11u-dev within a week, right? > https://bugs.openjdk.java.net/issues/?filter=36409 It?s good if they make -dev, but they can go to jdk11u if we miss the branch. > > I have my doubts about having 2.5 months gap between fork and release. That feels too early. Or > maybe not, given there is a pending 13 freeze in between, and also summer vacations. Actually for the community it?s only eight weeks. After that the repo is frozen. I think this time is needed to bring in the last non-critical changes, build, test, fix bugs, push the bug fixes and re-iterate. > >> Furthermore, I'm questioning myself, whether we want to explicitly have an RDP2 date? Pushes that target the jdk11u repo need to use the "critical" labeling and should meet the stricter rules for release stabilization anyway (see section "Fix Approvals" in the link below). Any opinions on that one? > > IMO, if we are not pulling jdk11u-dev -> jdk11u automatically and regularly, then there is little > sense in having the formal RDP2. We only pull in that direction once per release. The other way is pulled weekly. > Maintainers would have to judge if change is risky for > stabilization forest, every step of the way anyway. This should be expressed by the priority of the bug. Naturally, when allowing a change to jdk11u, Andrew will double check, I assume. Best regards, G?tz > > -Aleksey > From christoph.langer at sap.com Wed Apr 24 12:15:33 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Apr 2019 12:15:33 +0000 Subject: Set new hgupdater versions for jdk8u and jdk11u Message-ID: Hi Andrew, as the April CPU is out of the door and we don't expect any more changes for OpenJDK 8u212 and 11.0.3, I think it's time to ask ops to bump the versions for hgupdater in the release branches: https://hg.openjdk.java.net/jdk8u/ -> openjdk8u222 http://hg.openjdk.java.net/jdk-updates/jdk11u/ -> 11.0.4 The new setting needs to be active before we can merge from dev to release. Thanks Christoph From aph at redhat.com Wed Apr 24 13:06:51 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Apr 2019 14:06:51 +0100 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: References: Message-ID: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> On 4/24/19 1:15 PM, Langer, Christoph wrote: > as the April CPU is out of the door and we don't expect any more changes for OpenJDK 8u212 and 11.0.3, I think it's time to ask ops to bump the versions for hgupdater in the release branches: > > https://hg.openjdk.java.net/jdk8u/ -> openjdk8u222 > http://hg.openjdk.java.net/jdk-updates/jdk11u/ -> 11.0.4 > > The new setting needs to be active before we can merge from dev to release. Yep, was about to. Thanks for the reminder. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Apr 24 13:10:32 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Apr 2019 14:10:32 +0100 Subject: [11u]: 11.0.4 release schedule In-Reply-To: References: Message-ID: On 4/24/19 11:01 AM, Aleksey Shipilev wrote: > On 4/24/19 11:47 AM, Langer, Christoph wrote: >> I've now published the following schedule for 11.0.4 on the Wiki [0]: >> >> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) >> Tuesday, April 30 2019: Branch jdk11u-dev to jdk11u >> Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) >> Wednesday, May 29 2019: RDP2 >> Wednesday June 26 2019: Last tag before code freeze >> Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) >> >> Is everyone in agreement with that? >> >> Note: It means that we'll branch next week from jdk11u-dev to jdk11u! > > That also means outstanding 11.0.4-oracle things are better to get to 11u-dev within a week, right? > https://bugs.openjdk.java.net/issues/?filter=36409 > > I have my doubts about having 2.5 months gap between fork and release. That feels too early. Or > maybe not, given there is a pending 13 freeze in between, and also summer vacations. That feels early to me too. What will happen is a ton of jdk11u-critcial-requests for trivial bugs, simply to get them into the next release. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Wed Apr 24 14:48:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 24 Apr 2019 15:48:36 +0100 Subject: [11u]: 11.0.4 release schedule In-Reply-To: References: Message-ID: <504da13b-4ca4-fa47-b511-b30ec61910b9@redhat.com> On 24/04/2019 14:10, Andrew Haley wrote: > On 4/24/19 11:01 AM, Aleksey Shipilev wrote: >> On 4/24/19 11:47 AM, Langer, Christoph wrote: >>> I've now published the following schedule for 11.0.4 on the Wiki [0]: >>> >>> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) >>> Tuesday, April 30 2019: Branch jdk11u-dev to jdk11u >>> Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) >>> Wednesday, May 29 2019: RDP2 >>> Wednesday June 26 2019: Last tag before code freeze >>> Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) >>> >>> Is everyone in agreement with that? >>> >>> Note: It means that we'll branch next week from jdk11u-dev to jdk11u! >> >> That also means outstanding 11.0.4-oracle things are better to get to 11u-dev within a week, right? >> https://bugs.openjdk.java.net/issues/?filter=36409 >> >> I have my doubts about having 2.5 months gap between fork and release. That feels too early. Or >> maybe not, given there is a pending 13 freeze in between, and also summer vacations. > > That feels early to me too. What will happen is a ton of jdk11u-critcial-requests > for trivial bugs, simply to get them into the next release. > Me three. I thought RDP2 was the branch point. The above schedule suggests pretty much all work on each update is done in a branch. With working on the last releases, I haven't had much time to consider the next ones yet at all. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Wed Apr 24 15:08:50 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Apr 2019 15:08:50 +0000 Subject: [11u]: 11.0.4 release schedule In-Reply-To: References: Message-ID: Hi, > On 4/24/19 11:01 AM, Aleksey Shipilev wrote: > > On 4/24/19 11:47 AM, Langer, Christoph wrote: > >> I've now published the following schedule for 11.0.4 on the Wiki [0]: > >> > >> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > >> Tuesday, April 30 2019: Branch jdk11u-dev to jdk11u > >> Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) > >> Wednesday, May 29 2019: RDP2 > >> Wednesday June 26 2019: Last tag before code freeze > >> Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > >> > >> Is everyone in agreement with that? > >> > >> Note: It means that we'll branch next week from jdk11u-dev to jdk11u! > > > > That also means outstanding 11.0.4-oracle things are better to get to 11u- > dev within a week, right? > > https://bugs.openjdk.java.net/issues/?filter=36409 > > > > I have my doubts about having 2.5 months gap between fork and release. > That feels too early. Or > > maybe not, given there is a pending 13 freeze in between, and also > summer vacations. > > That feels early to me too. What will happen is a ton of jdk11u-critcial- > requests > for trivial bugs, simply to get them into the next release. Well, I had discussions with Goetz about this... I also have/had the feeling, that the proposed date to do the branch is too early. I would also rather propose to do the jdk11u-dev -> jdk11u transport at about the date mentioned as RDP2 above. I think, Goetz' reasoning behind suggesting the early branch is, if there was some late checkin which destabilizes things, there would only be about 4 weeks to get it fixed when branching late. Oracle also has an early branch/RDP2 date for their updates. E.g. 12.0.2 is probably branched about now. But I would be fine with changing the schedule to this: March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) Tuesday, May 28 2019: RDP2, Branch jdk11u-dev to jdk11u Wednesday, May 29 2019: First build (tag: jdk-11.0.4+1) Wednesday June 26 2019: Last tag before code freeze Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) So, I guess we shall wait a bit and collect further comments on this, e.g. from Goetz himself. Depending on the outcome of the discussion I'd update the Wiki at the end of the week. Best regards Christoph From gnu.andrew at redhat.com Wed Apr 24 16:02:49 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 24 Apr 2019 17:02:49 +0100 Subject: [11u]: 11.0.4 release schedule In-Reply-To: References: Message-ID: [Bringing jdk8u-dev into this as well as there's a lot of common material] On 24/04/2019 16:08, Langer, Christoph wrote: > Hi, > >> On 4/24/19 11:01 AM, Aleksey Shipilev wrote: >>> On 4/24/19 11:47 AM, Langer, Christoph wrote: >>>> I've now published the following schedule for 11.0.4 on the Wiki [0]: >>>> >>>> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) >>>> Tuesday, April 30 2019: Branch jdk11u-dev to jdk11u >>>> Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) >>>> Wednesday, May 29 2019: RDP2 >>>> Wednesday June 26 2019: Last tag before code freeze >>>> Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) >>>> >>>> Is everyone in agreement with that? >>>> >>>> Note: It means that we'll branch next week from jdk11u-dev to jdk11u! >>> >>> That also means outstanding 11.0.4-oracle things are better to get to 11u- >> dev within a week, right? >>> https://bugs.openjdk.java.net/issues/?filter=36409 >>> >>> I have my doubts about having 2.5 months gap between fork and release. >> That feels too early. Or >>> maybe not, given there is a pending 13 freeze in between, and also >> summer vacations. >> >> That feels early to me too. What will happen is a ton of jdk11u-critcial- >> requests >> for trivial bugs, simply to get them into the next release. > > Well, I had discussions with Goetz about this... I also have/had the feeling, that the proposed date to do the branch is too early. I would also rather propose to do the jdk11u-dev -> jdk11u transport at about the date mentioned as RDP2 above. > > I think, Goetz' reasoning behind suggesting the early branch is, if there was some late checkin which destabilizes things, there would only be about 4 weeks to get it fixed when branching late. Oracle also has an early branch/RDP2 date for their updates. E.g. 12.0.2 is probably branched about now. > > But I would be fine with changing the schedule to this: > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > Tuesday, May 28 2019: RDP2, Branch jdk11u-dev to jdk11u > Wednesday, May 29 2019: First build (tag: jdk-11.0.4+1) > Wednesday June 26 2019: Last tag before code freeze > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > > So, I guess we shall wait a bit and collect further comments on this, e.g. from Goetz himself. Depending on the outcome of the discussion I'd update the Wiki at the end of the week. > > Best regards > Christoph > This looks better. The addition I'd like to see is to start the weekly promotions earlier, so they also happen in the first stage. That would avoid b01 being so huge. I think that's a good halfway house between proposing entering the critical fix stage next week and not promoting anything until the end of May. That would mean multiple jdk11u-dev->jdk11u & jdk8u-dev->jdk8u merges from next Wednesday 1st of May through to the final one of May 29: March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) ================= RDP1 ===================================== = jdk11u tree gets changes by merge from jdk11u-dev = ============================================================ Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) Wednesday, May 29 2019: Fifth and final RDP1 build (tag: jdk-11.0.4+5) ================= RDP2 ===================================== = jdk11u tree gets changes only by jdk11u-critical-request = ============================================================ Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) Wednesday, June 19, 2019: Third RDP2 build (tag: jdk-11.0.4+8) Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) ================= FREEZE =================================== = jdk11u sees no public changes = ============================================================ Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) This allows regular testing earlier in the cycle, but without restricting the process down to critical fixes early. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Thu Apr 25 06:17:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 06:17:14 +0000 Subject: [11u, 8u] Updated Wiki pages Message-ID: Hi, I have now finished an overhaul of the Wiki pages for OpenJDK 8 [0] and 11 [1] updates. I implemented some feedback that I?ve gotten. The main goal for the entry pages is to have all important information at hand while also helping (new) contributors to get an understanding of what to do if they were to contribute. So I extracted technical/process detail information to separate pages [2], [3] and link to it from the ?General information? section. I enriched the technical/process detail pages with a checklist for things to do in the release cycle of an update release to be used by release engineers. This is still work in progress. I also added a small section about ?Contributing? which points to a more detailed recipe of things to do [4] (suggested by Aleksey). The rest of the information should be pretty up to date. I added a ?Releases? section with links (to source, binaries, filters etc.) for the April releases 8u212 and 11.0.3. Any feedback is welcome. ?? Thanks Christoph [0] https://wiki.openjdk.java.net/display/jdk8u [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u [2] https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Description [3] https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description [4] https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix From christoph.langer at sap.com Thu Apr 25 06:24:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 06:24:56 +0000 Subject: [11u]: 11.0.4 release schedule In-Reply-To: References: Message-ID: Hi, > On 24/04/2019 16:08, Langer, Christoph wrote: > > But I would be fine with changing the schedule to this: > > > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > > Tuesday, May 28 2019: RDP2, Branch jdk11u-dev to jdk11u > > Wednesday, May 29 2019: First build (tag: jdk-11.0.4+1) > > Wednesday June 26 2019: Last tag before code freeze > > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > > > > This looks better. > > The addition I'd like to see is to start the weekly promotions earlier, > so they also happen in the first stage. That would avoid b01 being so > huge. I think that's a good halfway house between proposing entering the > critical fix stage next week and not promoting anything until the end of > May. > > That would mean multiple jdk11u-dev->jdk11u & jdk8u-dev->jdk8u merges > from next Wednesday 1st of May through to the final one of May 29: > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > ================= RDP1 ===================================== > = jdk11u tree gets changes by merge from jdk11u-dev = > ========================================================== > == > Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) > Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) > Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) > Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) > Wednesday, May 29 2019: Fifth and final RDP1 build (tag: jdk-11.0.4+5) > ================= RDP2 ===================================== > = jdk11u tree gets changes only by jdk11u-critical-request = > ========================================================== > == > Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) > Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) > Wednesday, June 19, 2019: Third RDP2 build (tag: jdk-11.0.4+8) > Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) > ================= FREEZE =================================== > = jdk11u sees no public changes = > ========================================================== > == > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) > > This allows regular testing earlier in the cycle, but without > restricting the process down to critical fixes early. Sounds like a good suggestion to me as I can see the need to have EA builds early. I think technically we should then tag in jdk11u-dev/jdk8u-dev until the 29th of May and pull these tags into jdk11u/jdk8u. We'll have to confirm with ops whether this will correctly resolve the bugs in JBS (e.g. with the right build associated). Best regards Christoph From christoph.langer at sap.com Thu Apr 25 06:48:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 06:48:05 +0000 Subject: RFR: JDK-8221990: (Backport) Program fails when using JDK addressed by UNC path and using Security Manager In-Reply-To: References: Message-ID: Hi Adam, I pushed it now: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/ab9db1fbc27f Best regards Christoph From: Adam Farley8 Sent: Montag, 15. April 2019 18:08 To: Langer, Christoph Cc: jdk-updates-dev at openjdk.java.net Subject: RE: RFR: JDK-8221990: (Backport) Program fails when using JDK addressed by UNC path and using Security Manager Hi Christoph, Thanks for the sponsor offer. Much appreciated. :) No functional changes in the webrev, though I believe some of the line numbers have changed, so I added webrev anyway to avoid complications. Good to know about not needing to create a backport bug. Best Regards Adam Farley IBM Runtimes "Langer, Christoph" > wrote on 15/04/2019 16:09:38: > From: "Langer, Christoph" > > To: Adam Farley8 >, "jdk-updates- > dev at openjdk.java.net" > > Date: 15/04/2019 16:12 > Subject: RE: RFR: JDK-8221990: (Backport) Program fails when using > JDK addressed by UNC path and using Security Manager > > Hi Adam, > > thanks for doing this 11u patch-request. I will sponsor it for you, > once it's approved. > > I have added your fix request comment from the backport issue > (JDK-8221990) to the original bug (JDK-8218618) and set the backport > issue to fix version 11-pool. The backport will get resolved by the push. > > Since the patch applies cleanly (which I've verified myself), it > would not have been necessary to post a webrev. Or did you do any > changes in the webrev? Furthermore, it's also not necessary to > create the backport bug manually. A backport issue will be created > when a fix is pushed with a commit message referencing the original issue. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev > On > > Behalf Of Adam Farley8 > > Sent: Montag, 15. April 2019 12:37 > > To: jdk-updates-dev at openjdk.java.net > > Subject: RFR: JDK-8221990: (Backport) Program fails when using JDK > > addressed by UNC path and using Security Manager > > > > Hi All, > > > > Sponsor requested, please. > > > > PolicyFile jtreg tests have been run, and they don't encounter new > > failures after the patch. > > > > Webrev: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8221990_webrev_&d=DwIFAg&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DPYwXfUdsE94iXgc5DL9SQFY8DwFn4QF4AIAwIGP_1k&s=1OOy5RodAWFWJhjs0b5ZxiWSihAQvWYx- > y3Sz_s2kKg&e= > > > > Bug: https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8221990&d=DwIFAg&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DPYwXfUdsE94iXgc5DL9SQFY8DwFn4QF4AIAwIGP_1k&s=0NeqG3FFSZlkm2V2PXnEQaGSAraBGIQFqH2b_fQ366g&e= > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From sgehwolf at redhat.com Thu Apr 25 07:48:51 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 25 Apr 2019 09:48:51 +0200 Subject: [11u]: 11.0.4 release schedule In-Reply-To: References: Message-ID: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> On Thu, 2019-04-25 at 06:24 +0000, Langer, Christoph wrote: > Hi, > > > On 24/04/2019 16:08, Langer, Christoph wrote: > > > > > > But I would be fine with changing the schedule to this: > > > > > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > > > Tuesday, May 28 2019: RDP2, Branch jdk11u-dev to jdk11u > > > Wednesday, May 29 2019: First build (tag: jdk-11.0.4+1) > > > Wednesday June 26 2019: Last tag before code freeze > > > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > > > > > > > This looks better. > > > > The addition I'd like to see is to start the weekly promotions earlier, > > so they also happen in the first stage. That would avoid b01 being so > > huge. I think that's a good halfway house between proposing entering the > > critical fix stage next week and not promoting anything until the end of > > May. > > > > That would mean multiple jdk11u-dev->jdk11u & jdk8u-dev->jdk8u merges > > from next Wednesday 1st of May through to the final one of May 29: > > > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > > ================= RDP1 ===================================== > > = jdk11u tree gets changes by merge from jdk11u-dev = > > ========================================================== > > == > > Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) > > Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) > > Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) > > Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) > > Wednesday, May 29 2019: Fifth and final RDP1 build (tag: jdk-11.0.4+5) > > ================= RDP2 ===================================== > > = jdk11u tree gets changes only by jdk11u-critical-request = > > ========================================================== > > == > > Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) > > Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) > > Wednesday, June 19, 2019: Third RDP2 build (tag: jdk-11.0.4+8) > > Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) > > ================= FREEZE =================================== > > = jdk11u sees no public changes = > > ========================================================== > > == > > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) > > > > This allows regular testing earlier in the cycle, but without > > restricting the process down to critical fixes early. > > Sounds like a good suggestion to me as I can see the need to have EA builds early. > I think technically we should then tag in jdk11u-dev/jdk8u-dev until the 29th of May and pull these tags into jdk11u/jdk8u. > We'll have to confirm with ops whether this will correctly resolve the bugs in JBS (e.g. with the right build associated). +1 Thanks, Severin From sgehwolf at redhat.com Thu Apr 25 08:56:46 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 25 Apr 2019 10:56:46 +0200 Subject: [11u, 8u] Updated Wiki pages In-Reply-To: References: Message-ID: On Thu, 2019-04-25 at 06:17 +0000, Langer, Christoph wrote: > The rest of the information should be pretty up to date. I added a > ?Releases? section with links (to source, binaries, filters etc.) for > the April releases 8u212 and 11.0.3. I think the binary release links should point to: https://adoptopenjdk.net/upstream.html It would remove the need to update yet another page when releases are being cut. Or perhaps we should create a wiki page detailing which build the user is supposed to download for a specific release and explain how to verify the GPG signature. Thoughts? Thanks, Severin From shade at redhat.com Thu Apr 25 10:18:23 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 12:18:23 +0200 Subject: redhat-openjdk labels in JIRA Message-ID: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> Hi, We use our "redhat-openjdk" tag to get issues tracked in our backporting tracking. We used to have it to coordinate work with others, "claiming" the issues for our team to work on. Starting today, we mark _all_ issues of our interest, and it does not necessarily mean we (Red Hat people) are doing the backporting work for it -- so if you see that tag on the issue, you are free to grab it for backports anyway! As we discussed earlier, you might consider putting down the JBS comment that you are doing backports for a given issue, and then replace that comment with the actual Fix Request. Please only grab the issue if you are actually doing the work, not just planning to do it. This apparently scales better and works for non-Red Hat people too :) -- Thanks, -Aleksey From christoph.langer at sap.com Thu Apr 25 10:42:11 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 10:42:11 +0000 Subject: [11u, 8u] Updated Wiki pages In-Reply-To: References: Message-ID: Hi Severin, my thought was to link to the exact release build. As far as I understand, https://adoptopenjdk.net/upstream.html will always show the latest build. When a release is done, the information in the Wiki needs to be updated anyway. Best regards Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 25. April 2019 10:57 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: Re: [11u, 8u] Updated Wiki pages > > On Thu, 2019-04-25 at 06:17 +0000, Langer, Christoph wrote: > > The rest of the information should be pretty up to date. I added a > > ?Releases? section with links (to source, binaries, filters etc.) for > > the April releases 8u212 and 11.0.3. > > I think the binary release links should point to: > https://adoptopenjdk.net/upstream.html > > It would remove the need to update yet another page when releases are > being cut. > > Or perhaps we should create a wiki page detailing which build the user > is supposed to download for a specific release and explain how to > verify the GPG signature. > > Thoughts? > > Thanks, > Severin From gil at azul.com Thu Apr 25 11:31:41 2019 From: gil at azul.com (Gil Tene) Date: Thu, 25 Apr 2019 11:31:41 +0000 Subject: redhat-openjdk labels in JIRA In-Reply-To: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> Message-ID: Why use ?redhat? in a tag name used for overall coordination outside of RedHat personnel? Can we come up with a non-vendor-specific tag that would mean ?issue of interest to the project?, or ?issues of interest for backporting?? E.g. backport-openjdk seems much more appropriate than redhat-openjdk. Or backport-8u and backport-11u (and backport-7u) if we want to specifically identify them per target updates project or version. Sent from my iPad > On Apr 25, 2019, at 3:18 AM, Aleksey Shipilev wrote: > > Hi, > > We use our "redhat-openjdk" tag to get issues tracked in our backporting tracking. We used to have > it to coordinate work with others, "claiming" the issues for our team to work on. Starting today, we > mark _all_ issues of our interest, and it does not necessarily mean we (Red Hat people) are doing > the backporting work for it -- so if you see that tag on the issue, you are free to grab it for > backports anyway! > > As we discussed earlier, you might consider putting down the JBS comment that you are doing > backports for a given issue, and then replace that comment with the actual Fix Request. Please only > grab the issue if you are actually doing the work, not just planning to do it. This apparently > scales better and works for non-Red Hat people too :) > > -- > Thanks, > -Aleksey > From shade at redhat.com Thu Apr 25 11:51:54 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 13:51:54 +0200 Subject: redhat-openjdk labels in JIRA In-Reply-To: References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> Message-ID: <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> On 4/25/19 1:31 PM, Gil Tene wrote: > Why use ?redhat? in a tag name used for overall coordination outside of RedHat personnel? Can we > come up with a non-vendor-specific tag that would mean ?issue of interest to the project?, or > ?issues of interest for backporting?? If you read my note carefully, it says: "We ***used to have it*** to coordinate work with others". This is not a case anymore, and this is just the Red Hat -specific tag on issues for our internal use. With this note, I just notify others that this tag does not mean anything special for others anymore: feel free to take on the backport, regardless of the tag. Earlier discussions suggested we coordinate (avoid duplicate) work by putting the "doing backport" comments when starting the actual work. > E.g. backport-openjdk seems much more appropriate than redhat-openjdk. Or backport-8u and > backport-11u (and backport-7u) if we want to specifically identify them per target updates > project or version. Well, there is no central party that lists all the backports that are needed to be done. I don't think we have to have such a party, and actually having the update release participants tracking on their own brings redundancy to the project (keeps issues from accidentally slipping from everyone's tracking at once!). Everyone chooses the interesting issues for themselves, sometimes sharing the list, sometimes keeping it internally. Christoph has the list of candidates from Oracle [1], and I'm sure SAP has the internal "interest" list of backports too. Oracle also has "8-bp" and "11-bp" tags that are used for that? We have "redhat-openjdk" tag for that, etc. If you are looking for backporting work, you can look through whatever vendor-interest lists there are. The bottom-line is that anyone else can do whatever fits them tracking-wise, and that Feels Right (tm). Also, nobody is required to explain what private tags they use and why; it is just a courtesy to tell others what we are up to, and how could others interpret those tags. -Aleksey [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000654.html From sgehwolf at redhat.com Thu Apr 25 11:52:19 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 25 Apr 2019 13:52:19 +0200 Subject: [11u, 8u] Updated Wiki pages In-Reply-To: References: Message-ID: Hi Christoph, On Thu, 2019-04-25 at 10:42 +0000, Langer, Christoph wrote: > Hi Severin, > > my thought was to link to the exact release build. As far as I > understand, https://adoptopenjdk.net/upstream.html will always show > the latest build. OK, I thought so. It's OK, I guess and seems to work nicely for archived wiki pages too (if that ever happens). > When a release is done, the information in the Wiki needs to be > updated anyway. Fair point. Thanks, Severin > Best regards > Christoph > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Donnerstag, 25. April 2019 10:57 > > To: Langer, Christoph ; jdk-updates- > > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > > Subject: Re: [11u, 8u] Updated Wiki pages > > > > On Thu, 2019-04-25 at 06:17 +0000, Langer, Christoph wrote: > > > The rest of the information should be pretty up to date. I added > > > a > > > ?Releases? section with links (to source, binaries, filters etc.) > > > for > > > the April releases 8u212 and 11.0.3. > > > > I think the binary release links should point to: > > https://adoptopenjdk.net/upstream.html > > > > It would remove the need to update yet another page when releases > > are > > being cut. > > > > Or perhaps we should create a wiki page detailing which build the > > user > > is supposed to download for a specific release and explain how to > > verify the GPG signature. > > > > Thoughts? > > > > Thanks, > > Severin From epeterson at interactivebrokers.com Thu Apr 25 12:35:46 2019 From: epeterson at interactivebrokers.com (Eric Peterson) Date: Thu, 25 Apr 2019 12:35:46 +0000 Subject: [11u, 8u] Updated Wiki pages In-Reply-To: References: Message-ID: As a new member of the community, I found those pages to be very helpful! Thanks Christoph. One thing that would be helpful is a glossary. There are many acronyms floating around and it can sometimes be hard to figure out what they are. For instance: GA - General Availability (?) CPU - Critical Patch Update JBS - JDK Bug System BPR - ? RDP1/2 - ? CSR - ? Perhaps such a thing exists already and I just haven't come across it. Also an explanation of the versioning scheme somewhere would be helpful. Versions 11+ seem to use fairly standard semver, but 8 has a custom scheme that I still don't quite understand. I found a Wikipedia page [0] and Oracle page [1] on the subject, but they don't explain why the update number increments by 10 each quarter (192 => 202 => 212 etc.) Thanks! Eric [0] https://en.wikipedia.org/wiki/Java_version_history#Java_8_updates [1] https://www.oracle.com/technetwork/java/javase/jdk8-naming-2157130.html > On Apr 25, 2019, at 2:17 AM, Langer, Christoph wrote: > > Hi, > > I have now finished an overhaul of the Wiki pages for OpenJDK 8 [0] and 11 [1] updates. I implemented some feedback that I?ve gotten. > > The main goal for the entry pages is to have all important information at hand while also helping (new) contributors to get an understanding of what to do if they were to contribute. > > So I extracted technical/process detail information to separate pages [2], [3] and link to it from the ?General information? section. I enriched the technical/process detail pages with a checklist for things to do in the release cycle of an update release to be used by release engineers. This is still work in progress. > I also added a small section about ?Contributing? which points to a more detailed recipe of things to do [4] (suggested by Aleksey). > > The rest of the information should be pretty up to date. I added a ?Releases? section with links (to source, binaries, filters etc.) for the April releases 8u212 and 11.0.3. > > Any feedback is welcome. ?? > > Thanks > Christoph > > [0] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2Fjdk8u&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=dhkIhode4Wt7KaqACTkaUYf%2Fm%2FX%2BJury9HrbsteThWA%3D&reserved=0 > [1] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2FJDKUpdates%2FJDK11u&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=pJN9xQcKw6TUoD2pYp3c0PhILmELgLJZqi7W%2BGwvnR0%3D&reserved=0 > [2] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2FJDKUpdates%2FDetailed%2BProcess%2BDescription&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=l3efCNHxtOyjTSvz9zqYXE7kk%2BCxOr0i52fYa3K2Fys%3D&reserved=0 > [3] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2Fjdk8u%2FDetailed%2BProcess%2BDescription&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=j2NlAshITRwa%2Fi5B7sQHPLXpS%2F6rB%2FXNwrPLQ0cFoiw%3D&reserved=0 > [4] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2FJDKUpdates%2FHow%2Bto%2Bcontribute%2Ba%2Bfix&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=tIIzUwOhTf9%2FfmGmSPain8y6o%2BctKvesC5g92ERYBWI%3D&reserved=0 > From gil at azul.com Thu Apr 25 12:44:47 2019 From: gil at azul.com (Gil Tene) Date: Thu, 25 Apr 2019 12:44:47 +0000 Subject: redhat-openjdk labels in JIRA In-Reply-To: <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> , <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> Message-ID: Thanks for the clarification Aleksey, on who ?we? is, and about this redhat-openjdk tag indicating RedHat interest in the issue, and not some project-wide identification of interest. Also regarding the meaning, in that the tag itself does not mean ?RedHat doing backport?, so non-RedHat folks wanting to indicate that they are working on a backport can/should feel free to do that regardless of this tag. We (Azul) will start using an azul-openjdk tag in a similar way, to indicate our identified interest in an issue, but not actual ?doing backport?. Using comments to indicate actual ?doing backport? action makes sense. Sent from my iPad > On Apr 25, 2019, at 4:52 AM, Aleksey Shipilev wrote: > >> On 4/25/19 1:31 PM, Gil Tene wrote: >> Why use ?redhat? in a tag name used for overall coordination outside of RedHat personnel? Can we >> come up with a non-vendor-specific tag that would mean ?issue of interest to the project?, or >> ?issues of interest for backporting?? > > If you read my note carefully, it says: "We ***used to have it*** to coordinate work with others". > This is not a case anymore, and this is just the Red Hat -specific tag on issues for our internal > use. With this note, I just notify others that this tag does not mean anything special for others > anymore: feel free to take on the backport, regardless of the tag. Earlier discussions suggested we > coordinate (avoid duplicate) work by putting the "doing backport" comments when starting the actual > work. > >> E.g. backport-openjdk seems much more appropriate than redhat-openjdk. Or backport-8u and >> backport-11u (and backport-7u) if we want to specifically identify them per target updates >> project or version. > > Well, there is no central party that lists all the backports that are needed to be done. I don't > think we have to have such a party, and actually having the update release participants tracking on > their own brings redundancy to the project (keeps issues from accidentally slipping from everyone's > tracking at once!). > > Everyone chooses the interesting issues for themselves, sometimes sharing the list, sometimes > keeping it internally. Christoph has the list of candidates from Oracle [1], and I'm sure SAP has > the internal "interest" list of backports too. Oracle also has "8-bp" and "11-bp" tags that are used > for that? We have "redhat-openjdk" tag for that, etc. If you are looking for backporting work, you > can look through whatever vendor-interest lists there are. > > The bottom-line is that anyone else can do whatever fits them tracking-wise, and that Feels Right > (tm). Also, nobody is required to explain what private tags they use and why; it is just a courtesy > to tell others what we are up to, and how could others interpret those tags. > > -Aleksey > > [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000654.html > From adam.farley at uk.ibm.com Thu Apr 25 12:25:06 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 25 Apr 2019 13:25:06 +0100 Subject: RFR: JDK-8221990: (Backport) Program fails when using JDK addressed by UNC path and using Security Manager In-Reply-To: References: Message-ID: Thank you. :) Best Regards Adam Farley IBM Runtimes "Langer, Christoph" wrote on 25/04/2019 07:48:05: > From: "Langer, Christoph" > To: Adam Farley8 > Cc: "jdk-updates-dev at openjdk.java.net" > Date: 25/04/2019 07:48 > Subject: RE: RFR: JDK-8221990: (Backport) Program fails when using > JDK addressed by UNC path and using Security Manager > > Hi Adam, > > I pushed it now: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/ > rev/ab9db1fbc27f > > Best regards > Christoph > > From: Adam Farley8 > Sent: Montag, 15. April 2019 18:08 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net > Subject: RE: RFR: JDK-8221990: (Backport) Program fails when using > JDK addressed by UNC path and using Security Manager > > Hi Christoph, > > Thanks for the sponsor offer. Much appreciated. :) > > No functional changes in the webrev, though I believe some of the > line numbers have changed, so I added webrev anyway to avoid complications. > > Good to know about not needing to create a backport bug. > > Best Regards > > Adam Farley > IBM Runtimes > > > "Langer, Christoph" wrote on 15/04/2019 16:09:38: > > > From: "Langer, Christoph" > > To: Adam Farley8 , "jdk-updates- > > dev at openjdk.java.net" > > Date: 15/04/2019 16:12 > > Subject: RE: RFR: JDK-8221990: (Backport) Program fails when using > > JDK addressed by UNC path and using Security Manager > > > > Hi Adam, > > > > thanks for doing this 11u patch-request. I will sponsor it for you, > > once it's approved. > > > > I have added your fix request comment from the backport issue > > (JDK-8221990) to the original bug (JDK-8218618) and set the backport > > issue to fix version 11-pool. The backport will get resolved by the push. > > > > Since the patch applies cleanly (which I've verified myself), it > > would not have been necessary to post a webrev. Or did you do any > > changes in the webrev? Furthermore, it's also not necessary to > > create the backport bug manually. A backport issue will be created > > when a fix is pushed with a commit message referencing the original issue. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Adam Farley8 > > > Sent: Montag, 15. April 2019 12:37 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: RFR: JDK-8221990: (Backport) Program fails when using JDK > > > addressed by UNC path and using Security Manager > > > > > > Hi All, > > > > > > Sponsor requested, please. > > > > > > PolicyFile jtreg tests have been run, and they don't encounter new > > > failures after the patch. > > > > > > Webrev: https://urldefense.proofpoint.com/v2/url? > > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8221990_webrev_&d=DwIFAg&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DPYwXfUdsE94iXgc5DL9SQFY8DwFn4QF4AIAwIGP_1k&s=1OOy5RodAWFWJhjs0b5ZxiWSihAQvWYx- > > y3Sz_s2kKg&e= > > > > > > Bug: https://urldefense.proofpoint.com/v2/url? > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8221990&d=DwIFAg&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DPYwXfUdsE94iXgc5DL9SQFY8DwFn4QF4AIAwIGP_1k&s=0NeqG3FFSZlkm2V2PXnEQaGSAraBGIQFqH2b_fQ366g&e= > > > > > > Best Regards > > > > > > Adam Farley > > > IBM Runtimes > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > > 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From christoph.langer at sap.com Thu Apr 25 13:04:20 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 13:04:20 +0000 Subject: [11u, 8u] Updated Wiki pages In-Reply-To: References: Message-ID: Hi Eric, thanks for the feedback. ?? I can understand that something like a glossary would be helpful if you're not into all these abbreviations. I even find myself contemplating about things like "What again does RDP mean?" etc. So, let's see if I can add something like this in a later update. As for the update versioning scheme: I don't know of a link that explains the numbering for JDK8u. I think it's incremented by ten each quarter, such as 802, 812, 822 etc. Oracle also does security-only fixes, known as CPU which end with the digit '1', e.g. 801, 811, 821. But for OpenJDK we decided to combine these and don't ship versions with only security fixes. Regarding Java version 9+: There is a JEP about this topic: https://openjdk.java.net/jeps/223 Best regards Christoph > -----Original Message----- > From: Eric Peterson > Sent: Donnerstag, 25. April 2019 14:36 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: Re: [11u, 8u] Updated Wiki pages > > As a new member of the community, I found those pages to be very helpful! > Thanks Christoph. > > One thing that would be helpful is a glossary. There are many acronyms > floating around and it can sometimes be hard to figure out what they are. For > instance: > GA - General Availability (?) > CPU - Critical Patch Update > JBS - JDK Bug System > BPR - ? > RDP1/2 - ? > CSR - ? > Perhaps such a thing exists already and I just haven't come across it. > > Also an explanation of the versioning scheme somewhere would be helpful. > Versions 11+ seem to use fairly standard semver, but 8 has a custom scheme > that I still don't quite understand. I found a Wikipedia page [0] and Oracle > page [1] on the subject, but they don't explain why the update number > increments by 10 each quarter (192 => 202 => 212 etc.) > > Thanks! > Eric > > [0] https://en.wikipedia.org/wiki/Java_version_history#Java_8_updates > [1] https://www.oracle.com/technetwork/java/javase/jdk8-naming- > 2157130.html > > > > On Apr 25, 2019, at 2:17 AM, Langer, Christoph > wrote: > > > > Hi, > > > > I have now finished an overhaul of the Wiki pages for OpenJDK 8 [0] and 11 > [1] updates. I implemented some feedback that I?ve gotten. > > > > The main goal for the entry pages is to have all important information at > hand while also helping (new) contributors to get an understanding of what > to do if they were to contribute. > > > > So I extracted technical/process detail information to separate pages [2], > [3] and link to it from the ?General information? section. I enriched the > technical/process detail pages with a checklist for things to do in the release > cycle of an update release to be used by release engineers. This is still work > in progress. > > I also added a small section about ?Contributing? which points to a more > detailed recipe of things to do [4] (suggested by Aleksey). > > > > The rest of the information should be pretty up to date. I added a > ?Releases? section with links (to source, binaries, filters etc.) for the April > releases 8u212 and 11.0.3. > > > > Any feedback is welcome. ?? > > > > Thanks > > Christoph > > > > [0] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki. > openjdk.java.net%2Fdisplay%2Fjdk8u&data=01%7C01%7Cepeterson%4 > 0interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04 > ef837d48e69ba869d84f65a110%7C0&sdata=dhkIhode4Wt7KaqACTkaUY > f%2Fm%2FX%2BJury9HrbsteThWA%3D&reserved=0 > > [1] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki. > openjdk.java.net%2Fdisplay%2FJDKUpdates%2FJDK11u&data=01%7C01 > %7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c94 > 5c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=pJN9xQcK > w6TUoD2pYp3c0PhILmELgLJZqi7W%2BGwvnR0%3D&reserved=0 > > [2] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki. > openjdk.java.net%2Fdisplay%2FJDKUpdates%2FDetailed%2BProcess%2BDes > cription&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca > 530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110 > %7C0&sdata=l3efCNHxtOyjTSvz9zqYXE7kk%2BCxOr0i52fYa3K2Fys%3D& > amp;reserved=0 > > [3] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki. > openjdk.java.net%2Fdisplay%2Fjdk8u%2FDetailed%2BProcess%2BDescriptio > n&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff1 > 17d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0& > amp;sdata=j2NlAshITRwa%2Fi5B7sQHPLXpS%2F6rB%2FXNwrPLQ0cFoiw%3D > &reserved=0 > > [4] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki. > openjdk.java.net%2Fdisplay%2FJDKUpdates%2FHow%2Bto%2Bcontribute% > 2Ba%2Bfix&data=01%7C01%7Cepeterson%40interactivebrokers.com%7 > Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a1 > 10%7C0&sdata=tIIzUwOhTf9%2FfmGmSPain8y6o%2BctKvesC5g92ERYB > WI%3D&reserved=0 > > From shade at redhat.com Thu Apr 25 16:56:50 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 18:56:50 +0200 Subject: redhat-openjdk labels in JIRA In-Reply-To: References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> Message-ID: On 4/25/19 2:44 PM, Gil Tene wrote: > We (Azul) will start using an azul-openjdk tag in a similar way, > to indicate our identified interest in an issue, but not actual > ?doing backport?. Using comments to indicate actual > ?doing backport? action makes sense. If we did it today, we'd probably go for "redhat-interest", as it better captures the intent, and also aligns with other -interest flags. -Aleksey From andrew.gross at oracle.com Thu Apr 25 17:00:23 2019 From: andrew.gross at oracle.com (Andrew Gross) Date: Thu, 25 Apr 2019 10:00:23 -0700 Subject: OpenJDK - CPU Matrix In-Reply-To: <5D246673-4A6B-4B2F-A0CB-BC34310E94C7@interactivebrokers.com> References: <5D246673-4A6B-4B2F-A0CB-BC34310E94C7@interactivebrokers.com> Message-ID: <0da7bb95-2503-c7d6-e497-6aa951bd1ed9@oracle.com> Hi Eric, There is nothing currently.? The OpenJDK Vulnerability Group is working on this and plan to post a unified view starting with the July release. Andrew Gross OJVG Lead On 4/22/2019 11:18 AM, Eric Peterson wrote: > Hi all, > > I'm wondering if there is an equivalent page for OpenJDK that tracks fixed vulnerabilities for the April release, similar to what Oracle posted for their recent CPU: > > https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html#AppendixJAVA > > I have hunted around a bit but not found anything so far. > > --Eric From takiguc at linux.vnet.ibm.com Thu Apr 25 17:45:53 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 26 Apr 2019 02:45:53 +0900 Subject: [11u] RDR: backport 8220281 IBM-858 alias name is missing on IBM00858 charset Message-ID: Hello. I got jdk11u-fix-yes for following bug id: JDK-8220281 IBM-858 alias name is missing on IBM00858 charset [1] Changeset 41b79b3e21fb [2] can be applied. I'd like to obtain a sponsor for JDK-8220281. [1] https://bugs.openjdk.java.net/browse/JDK-8220281 [2] http://hg.openjdk.java.net/jdk/jdk/rev/41b79b3e21fb Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From shade at redhat.com Thu Apr 25 17:46:20 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 19:46:20 +0200 Subject: [11u] RDR: backport 8220281 IBM-858 alias name is missing on IBM00858 charset In-Reply-To: References: Message-ID: On 4/25/19 7:45 PM, Ichiroh Takiguchi wrote: > Hello. > > I got jdk11u-fix-yes for following bug id: > JDK-8220281 IBM-858 alias name is missing on IBM00858 charset [1] > Changeset 41b79b3e21fb [2] can be applied. > > I'd like to obtain a sponsor for JDK-8220281. > > [1] https://bugs.openjdk.java.net/browse/JDK-8220281 > [2] http://hg.openjdk.java.net/jdk/jdk/rev/41b79b3e21fb I'll do it for you. -Aleksey From shade at redhat.com Thu Apr 25 17:58:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 19:58:29 +0200 Subject: [11u] RDR: backport 8220281 IBM-858 alias name is missing on IBM00858 charset In-Reply-To: References: Message-ID: On 4/25/19 7:46 PM, Aleksey Shipilev wrote: > On 4/25/19 7:45 PM, Ichiroh Takiguchi wrote: >> I got jdk11u-fix-yes for following bug id: >> JDK-8220281 IBM-858 alias name is missing on IBM00858 charset [1] >> Changeset 41b79b3e21fb [2] can be applied. >> >> I'd like to obtain a sponsor for JDK-8220281. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8220281 >> [2] http://hg.openjdk.java.net/jdk/jdk/rev/41b79b3e21fb > > I'll do it for you. There: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/32cf83827c4e -Aleksey From takiguc at linux.vnet.ibm.com Thu Apr 25 18:18:03 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 26 Apr 2019 03:18:03 +0900 Subject: [11u] RDR: backport JDK-8211300 and JDK-8212678 Message-ID: <4a2e3503bb41c292eb4c6d9587735157@linux.vnet.ibm.com> Hello. I got jdk11u-fix-yes for following bug ids: JDK-8211300 Convert C-style array declarations in JDK client code [1] JDK-8212678 Windows IME related patch [2] Changeset 2e330da7cbf4 [3] and 33b96cbd16f3 [4] can be applied. I'd like to obtain a sponsor for JDK-8211300 and JDK-8212678 [1] https://bugs.openjdk.java.net/browse/JDK-8211300 [2] https://bugs.openjdk.java.net/browse/JDK-8212678 [3] http://hg.openjdk.java.net/jdk/jdk/rev/2e330da7cbf4 [4] http://hg.openjdk.java.net/jdk/jdk/rev/33b96cbd16f3 Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From shade at redhat.com Thu Apr 25 19:46:41 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 21:46:41 +0200 Subject: [11u] RDR: backport JDK-8211300 and JDK-8212678 In-Reply-To: <4a2e3503bb41c292eb4c6d9587735157@linux.vnet.ibm.com> References: <4a2e3503bb41c292eb4c6d9587735157@linux.vnet.ibm.com> Message-ID: <31798457-f327-ce17-5a65-635307eb83ca@redhat.com> On 4/25/19 8:18 PM, Ichiroh Takiguchi wrote: > JDK-8211300 Convert C-style array declarations in JDK client code [1] You don't have jdk11u-fix-yes for this one. > JDK-8212678 Windows IME related patch [2] ...so this cannot be applied too? -Aleksey From GROEGES at uk.ibm.com Fri Apr 26 08:50:08 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 26 Apr 2019 09:50:08 +0100 Subject: RFR: TEST_BUG: 8222027 - java/util/logging/LogManager/TestLoggerNames.java generates intermittent ClassCastException In-Reply-To: <14b3c862-a744-28a8-d40c-652fdc5dadc2@oracle.com> References: <501ff931-c50e-ac82-6ac6-ae71a6da0ffa@oracle.com> <1a9a27e6-d196-3fa1-fda4-9a3a80b327cc@oracle.com> <14b3c862-a744-28a8-d40c-652fdc5dadc2@oracle.com> Message-ID: Hi all, The fix for this bug [1] was made on the jdk repository with this [2] and I have requested that this be backported to jdk11u. The request have been approved but I need someone to sponsor this change and to then merge it into jdk11u-dev. I have tested that the patch installed cleanly on jdk11u and all the tests work. Would be grateful if someone could take a look at this and get it merged for me. [1] https://bugs.openjdk.java.net/browse/JDK-8222027 [2] http://hg.openjdk.java.net/jdk/jdk/rev/e5713cefcf41 Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Daniel Fuchs To: Steve Groeger Cc: OpenJDK Core Libs Developers Date: 08/04/2019 17:57 Subject: Re: RFR: TEST_BUG: 8222027 - java/util/logging/LogManager/TestLoggerNames.java generates intermittent ClassCastException Thanks Steve, I just pushed it: https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_e5713cefcf41&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=NPuRuuPQmKIyeueDfyqjCSPLX8pC2jDZknJJSkghSnk&s=qu6UUeh3WsRz3MbcR-fk9BTLMUeMiCuDJCmxFlYxyEU&e= best regards, -- daniel On 08/04/2019 15:13, Steve Groeger wrote: > Hi Daniel, > > Thanks, have created a new webrev [1] > Once it is merged I will then work on getting it back-ported to jdk11u. > Thanks for all your assistance in getting this done. > > [1] _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8222027_webrev.04_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=NPuRuuPQmKIyeueDfyqjCSPLX8pC2jDZknJJSkghSnk&s=3YXbO9kAFGPVqZYB1YpmAh-17boBEL9sDAQ08Ksa-7E&e= > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From sgehwolf at redhat.com Fri Apr 26 09:02:51 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Apr 2019 11:02:51 +0200 Subject: RFR: TEST_BUG: 8222027 - java/util/logging/LogManager/TestLoggerNames.java generates intermittent ClassCastException In-Reply-To: References: <501ff931-c50e-ac82-6ac6-ae71a6da0ffa@oracle.com> <1a9a27e6-d196-3fa1-fda4-9a3a80b327cc@oracle.com> <14b3c862-a744-28a8-d40c-652fdc5dadc2@oracle.com> Message-ID: <0a0500a3827c2a54fb14c02c8738cd135a189c33.camel@redhat.com> Hi Steve, On Fri, 2019-04-26 at 09:50 +0100, Steve Groeger wrote: > Hi all, > > The fix for this bug [1] was made on the jdk repository with this [2] and > I have requested that this be backported to jdk11u. > The request have been approved but I need someone to sponsor this change > and to then merge it into jdk11u-dev. > I have tested that the patch installed cleanly on jdk11u and all the tests > work. > Would be grateful if someone could take a look at this and get it merged > for me. I'll sponsor this for you. Thanks, Severin > [1] https://bugs.openjdk.java.net/browse/JDK-8222027 > [2] http://hg.openjdk.java.net/jdk/jdk/rev/e5713cefcf41 > > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Daniel Fuchs > To: Steve Groeger > Cc: OpenJDK Core Libs Developers > Date: 08/04/2019 17:57 > Subject: Re: RFR: TEST_BUG: 8222027 - > java/util/logging/LogManager/TestLoggerNames.java generates intermittent > ClassCastException > > > > Thanks Steve, > > I just pushed it: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_e5713cefcf41&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=NPuRuuPQmKIyeueDfyqjCSPLX8pC2jDZknJJSkghSnk&s=qu6UUeh3WsRz3MbcR-fk9BTLMUeMiCuDJCmxFlYxyEU&e= > > > best regards, > > -- daniel > > On 08/04/2019 15:13, Steve Groeger wrote: > > Hi Daniel, > > > > Thanks, have created a new webrev [1] > > Once it is merged I will then work on getting it back-ported to jdk11u. > > Thanks for all your assistance in getting this done. > > > > [1] _ > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8222027_webrev.04_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=NPuRuuPQmKIyeueDfyqjCSPLX8pC2jDZknJJSkghSnk&s=3YXbO9kAFGPVqZYB1YpmAh-17boBEL9sDAQ08Ksa-7E&e= > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From sgehwolf at redhat.com Fri Apr 26 09:37:54 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Apr 2019 11:37:54 +0200 Subject: RFR: TEST_BUG: 8222027 - java/util/logging/LogManager/TestLoggerNames.java generates intermittent ClassCastException In-Reply-To: References: <501ff931-c50e-ac82-6ac6-ae71a6da0ffa@oracle.com> <1a9a27e6-d196-3fa1-fda4-9a3a80b327cc@oracle.com> <14b3c862-a744-28a8-d40c-652fdc5dadc2@oracle.com> Message-ID: <9611d3c0f66f68e46800174c09c81d6771581ca1.camel@redhat.com> Hi Steve, On Fri, 2019-04-26 at 09:50 +0100, Steve Groeger wrote: > Hi all, > > The fix for this bug [1] was made on the jdk repository with this [2] and > I have requested that this be backported to jdk11u. > The request have been approved but I need someone to sponsor this change > and to then merge it into jdk11u-dev. > I have tested that the patch installed cleanly on jdk11u and all the tests > work. > Would be grateful if someone could take a look at this and get it merged > for me. I've pushed the fix: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/b3f7a4c524f2 It'll flow into jdk11u from jdk11u-dev via JDK 11u maintainer merges. As the fix is in JDK 13, but not JDK 12, I'd suggest to also "Fix Request" it for JDK 12u too. Adding the label jdk12u-fix-request should be enough with a similar comment as for the JDK 11 fix request comment, but pertaining to JDK 12. Thanks, Severin > [1] https://bugs.openjdk.java.net/browse/JDK-8222027 > [2] http://hg.openjdk.java.net/jdk/jdk/rev/e5713cefcf41 > > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Daniel Fuchs > To: Steve Groeger > Cc: OpenJDK Core Libs Developers > Date: 08/04/2019 17:57 > Subject: Re: RFR: TEST_BUG: 8222027 - > java/util/logging/LogManager/TestLoggerNames.java generates intermittent > ClassCastException > > > > Thanks Steve, > > I just pushed it: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_e5713cefcf41&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=NPuRuuPQmKIyeueDfyqjCSPLX8pC2jDZknJJSkghSnk&s=qu6UUeh3WsRz3MbcR-fk9BTLMUeMiCuDJCmxFlYxyEU&e= > > > best regards, > > -- daniel > > On 08/04/2019 15:13, Steve Groeger wrote: > > Hi Daniel, > > > > Thanks, have created a new webrev [1] > > Once it is merged I will then work on getting it back-ported to jdk11u. > > Thanks for all your assistance in getting this done. > > > > [1] _ > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8222027_webrev.04_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=NPuRuuPQmKIyeueDfyqjCSPLX8pC2jDZknJJSkghSnk&s=3YXbO9kAFGPVqZYB1YpmAh-17boBEL9sDAQ08Ksa-7E&e= > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From GROEGES at uk.ibm.com Fri Apr 26 10:22:59 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 26 Apr 2019 11:22:59 +0100 Subject: RFR: TEST_BUG: 8222027 - java/util/logging/LogManager/TestLoggerNames.java generates intermittent ClassCastException In-Reply-To: <9611d3c0f66f68e46800174c09c81d6771581ca1.camel@redhat.com> References: <1a9a27e6-d196-3fa1-fda4-9a3a80b327cc@oracle.com> <14b3c862-a744-28a8-d40c-652fdc5dadc2@oracle.com> <9611d3c0f66f68e46800174c09c81d6771581ca1.camel@redhat.com> Message-ID: Hi Severin, Thanks. I have updated the issue with a Fix Request comment and the label for jdk12u-fix-request. Hopefully this will get approved and the fix will then be made into jdk12u. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Severin Gehwolf To: Steve Groeger , jdk-updates-dev at openjdk.java.net Date: 26/04/2019 10:38 Subject: Re: RFR: TEST_BUG: 8222027 - java/util/logging/LogManager/TestLoggerNames.java generates intermittent ClassCastException Hi Steve, On Fri, 2019-04-26 at 09:50 +0100, Steve Groeger wrote: > Hi all, > > The fix for this bug [1] was made on the jdk repository with this [2] and > I have requested that this be backported to jdk11u. > The request have been approved but I need someone to sponsor this change > and to then merge it into jdk11u-dev. > I have tested that the patch installed cleanly on jdk11u and all the tests > work. > Would be grateful if someone could take a look at this and get it merged > for me. I've pushed the fix: https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk-2Dupdates_jdk11u-2Ddev_rev_b3f7a4c524f2&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=UjaAayv2ElbWasFpR01x7goiz8NVVe0zcUiKZ_KfgyU&s=-0cX6FuM_1aZ_o8L0mVyYuAU9dwvH5K3wmyT8lXN-HM&e= It'll flow into jdk11u from jdk11u-dev via JDK 11u maintainer merges. As the fix is in JDK 13, but not JDK 12, I'd suggest to also "Fix Request" it for JDK 12u too. Adding the label jdk12u-fix-request should be enough with a similar comment as for the JDK 11 fix request comment, but pertaining to JDK 12. Thanks, Severin > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8222027&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=UjaAayv2ElbWasFpR01x7goiz8NVVe0zcUiKZ_KfgyU&s=mqvWnEUwL7ljIDeJ6CfBjG1q6D5WajkNL6ICjY9wcEE&e= > [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_e5713cefcf41&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=UjaAayv2ElbWasFpR01x7goiz8NVVe0zcUiKZ_KfgyU&s=Al5CSrp3R_pedrqbEKydQbty2Trhp2wKmiMYCeZfGMc&e= > > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Daniel Fuchs > To: Steve Groeger > Cc: OpenJDK Core Libs Developers > Date: 08/04/2019 17:57 > Subject: Re: RFR: TEST_BUG: 8222027 - > java/util/logging/LogManager/TestLoggerNames.java generates intermittent > ClassCastException > > > > Thanks Steve, > > I just pushed it: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_e5713cefcf41&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=NPuRuuPQmKIyeueDfyqjCSPLX8pC2jDZknJJSkghSnk&s=qu6UUeh3WsRz3MbcR-fk9BTLMUeMiCuDJCmxFlYxyEU&e= > > > best regards, > > -- daniel > > On 08/04/2019 15:13, Steve Groeger wrote: > > Hi Daniel, > > > > Thanks, have created a new webrev [1] > > Once it is merged I will then work on getting it back-ported to jdk11u. > > Thanks for all your assistance in getting this done. > > > > [1] _ > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8222027_webrev.04_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=NPuRuuPQmKIyeueDfyqjCSPLX8pC2jDZknJJSkghSnk&s=3YXbO9kAFGPVqZYB1YpmAh-17boBEL9sDAQ08Ksa-7E&e= > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From dalibor.topic at oracle.com Fri Apr 26 12:11:50 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 26 Apr 2019 14:11:50 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> Message-ID: <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> Hi, the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html are still confusingly versioned on that site, unfortunately. To quote from [0]: "E.g. what tells an end user that +7 and +31 are release builds, but +6 and +11 are not?" cheers, dalibor topic [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000962.html On 16.04.2019 21:49, Dalibor Topic wrote: > On 15.04.2019 12:25, Andrew Haley wrote: >> we now have early access >> preview Linux and Windows binaries (currently x86-64 only) at >> >> https://adoptopenjdk.net/upstream.html > > I would suggest using the version nomenclature per JEP 322, i.e. > > "A version string is a version number, $VNUM, possibly followed by > pre-release, build, and other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build > number, and $OPT is optional build information." > > i.e. 11.0.3-ea+6, for example. > > cheers, > dalibor topic > -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From sgehwolf at redhat.com Fri Apr 26 12:28:11 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Apr 2019 14:28:11 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> Message-ID: <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: > Hi, > > the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html > are still confusingly versioned on that site, unfortunately. To quote > from [0]: > > "E.g. what tells an end user that +7 and +31 are release builds, but +6 > and +11 are not?" I'm not 100% clear what you mean. To answer the question: The filename? "java -version" output? $ ls -1 OpenJDK11U-x64_linux_11.0.3_6_ea.tar.gz OpenJDK11U-x64_linux_11.0.3_7.tar.gz $ ./openjdk-11.0.3+6/bin/java -version openjdk version "11.0.3-ea" 2019-04-16 OpenJDK Runtime Environment 18.9 (build 11.0.3-ea+6) OpenJDK 64-Bit Server VM 18.9 (build 11.0.3-ea+6, mixed mode) $ ./openjdk-11.0.3+7/bin/java -version openjdk version "11.0.3" 2019-04-16 OpenJDK Runtime Environment 18.9 (build 11.0.3+7) OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode) For JDK 8u it won't show up in the version output, but I'm not sure that can be helped. Archive file names still have "ea" in their name and the build numbers show up in version output so as to distinguish them. Thanks, Severin > cheers, > dalibor topic > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000962.html > > On 16.04.2019 21:49, Dalibor Topic wrote: > > On 15.04.2019 12:25, Andrew Haley wrote: > > > we now have early access > > > preview Linux and Windows binaries (currently x86-64 only) at > > > > > > https://adoptopenjdk.net/upstream.html > > > > I would suggest using the version nomenclature per JEP 322, i.e. > > > > "A version string is a version number, $VNUM, possibly followed by > > pre-release, build, and other optional information, one of: > > > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > > $VNUM-$PRE(-$OPT)? > > $VNUM(+-$OPT)? > > > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a > > build > > number, and $OPT is optional build information." > > > > i.e. 11.0.3-ea+6, for example. > > > > cheers, > > dalibor topic > > From dalibor.topic at oracle.com Fri Apr 26 12:54:39 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 26 Apr 2019 14:54:39 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> Message-ID: <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> On 26.04.2019 14:28, Severin Gehwolf wrote: > On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: >> Hi, >> >> the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html >> are still confusingly versioned on that site, unfortunately. [snip] > I'm not 100% clear what you mean. Thanks for your reply, Severin, and apologies for not being precise enough. While the EA build file names contain an 'ea' substring, the HTML anchor tag's text content unfortunately doesn't. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From sgehwolf at redhat.com Fri Apr 26 13:06:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Apr 2019 15:06:12 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> Message-ID: <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> On Fri, 2019-04-26 at 14:54 +0200, Dalibor Topic wrote: > On 26.04.2019 14:28, Severin Gehwolf wrote: > > On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: > > > Hi, > > > > > > the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html > > > are still confusingly versioned on that site, unfortunately. > [snip] > > I'm not 100% clear what you mean. > > Thanks for your reply, Severin, and apologies for not being precise enough. > > While the EA build file names contain an 'ea' substring, the HTML anchor > tag's text content unfortunately doesn't. Fair enough :) There are two separate tables, though. One for the release bits and another for EA. In addition to that, the rows in corresponding tables are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do we really need another "ea" added somewhere? For brevity in the table I'd rather not. That's just my opinion, though. Thanks, Severin From dalibor.topic at oracle.com Fri Apr 26 13:27:04 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 26 Apr 2019 15:27:04 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> Message-ID: <3d864740-027b-60b5-db57-7696f8d71fad@oracle.com> On 26.04.2019 15:06, Severin Gehwolf wrote: > There are two separate tables, though. One for the release bits and > another for EA. In addition to that, the rows in corresponding tables > are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do we really > need another "ea" added somewhere? For brevity in the table I'd rather > not. That's just my opinion, though. My experience has been that some users can get confused if (i.e. in your case: when) there is a build with a 'higher' version than a GA release that's not clearly recognizable as an Early Access build in all possible ways. Basically, not everyone is necessarily an expert at JDK development or its versioning. ;) cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From martijnverburg at gmail.com Fri Apr 26 13:59:04 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 26 Apr 2019 14:59:04 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: <3d864740-027b-60b5-db57-7696f8d71fad@oracle.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> <3d864740-027b-60b5-db57-7696f8d71fad@oracle.com> Message-ID: Bug reports and Pull Requests welcome https://www.github.com/adoptopenjdk/openjdk-website ;-) In all seriousness - closed via https://github.com/AdoptOpenJDK/openjdk-website/pull/471 Cheers, Martijn On Fri, 26 Apr 2019 at 14:27, Dalibor Topic wrote: > On 26.04.2019 15:06, Severin Gehwolf wrote: > > > There are two separate tables, though. One for the release bits and > > another for EA. In addition to that, the rows in corresponding tables > > are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do we really > > need another "ea" added somewhere? For brevity in the table I'd rather > > not. That's just my opinion, though. > > My experience has been that some users can get confused if (i.e. in your > case: when) there is a build with a 'higher' version than a GA release > that's not clearly recognizable as an Early Access build in all possible > ways. > > Basically, not everyone is necessarily an expert at JDK development or > its versioning. ;) > > cheers, > dalibor topic > > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > From gil at azul.com Fri Apr 26 14:47:22 2019 From: gil at azul.com (Gil Tene) Date: Fri, 26 Apr 2019 14:47:22 +0000 Subject: OpenJDK Updates Project Builds In-Reply-To: <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com>, <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> Message-ID: <515BB18C-F37C-44F6-81ED-E71F4DEF5FDF@azul.com> Sent from my iPad On Apr 26, 2019, at 5:28 AM, Severin Gehwolf > wrote: On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: Hi, the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html are still confusingly versioned on that site, unfortunately. To quote from [0]: "E.g. what tells an end user that +7 and +31 are release builds, but +6 and +11 are not?" I'm not 100% clear what you mean. To answer the question: The filename? "java -version" output? $ ls -1 OpenJDK11U-x64_linux_11.0.3_6_ea.tar.gz OpenJDK11U-x64_linux_11.0.3_7.tar.gz $ ./openjdk-11.0.3+6/bin/java -version openjdk version "11.0.3-ea" 2019-04-16 OpenJDK Runtime Environment 18.9 (build 11.0.3-ea+6) OpenJDK 64-Bit Server VM 18.9 (build 11.0.3-ea+6, mixed mode) $ ./openjdk-11.0.3+7/bin/java -version openjdk version "11.0.3" 2019-04-16 OpenJDK Runtime Environment 18.9 (build 11.0.3+7) OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode) For JDK 8u it won't show up in the version output, but I'm not sure that can be helped. Archive file names still have "ea" in their name and the build numbers show up in version output so as to distinguish them. I would highly recommend/request/beg/plead that the -version string of any posed EA builds be modified to clearly identify as EA (like the 11 builds do above). And that all current builds that don?t do that be taken down ASAP to prevent damage. This (EA builds of 8u that show -version numbers that look very much like releases but are not) is a very serious problem. The file name, the web link, and the text in the web page don?t survive installation. And what you have left around then is a ?mystery meat? JDK that made it into the wild. These things can (and do) then end up in places and situations where vast numbers of people end up using unreleased builds, often in production, without knowing it. For a concrete historical example of how bad something like this can (and did) get when you don?t take care to identify EA?ness in the actual version string output: Between Sep. 2014 and March 2015 (I.e. for the ~6 month period before 8u40 was actually released) running ?docker run java:8 -version? reported the version as 8u40, with nothing to indicate the JDK you were running was experimental or EA. This was a result of an unfortunate choice to take the blessed docker java image?s JDK from a Debian unstable release, which was building an unreleased OpenJDK (with the Debian folks probably thinking ?this Debian distro and repo are clearly unstable/experimental, so people would know not to take bits from it to production?). This JDK then ended up in the ?blessed? docker image for java, with nothing to identify it as a non-released JDK. And as a result everyone that read articles like https://blog.giantswarm.io/getting-started-with-java-development-on-docker/ ended up using an 8u40 that wasn?t 8u40 without knowing it, and with no obvious way to tell, even after the real 8 u40 was released. It is likely that millions of people were affected by this. Bottom line: Please please please don?t put up binary builds of non-released JDKs that do not clearly identify them as such in the version actual string output. And if you did, please tear them down ASAP to limit potential damage. Thanks, Severin cheers, dalibor topic [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000962.html On 16.04.2019 21:49, Dalibor Topic wrote: On 15.04.2019 12:25, Andrew Haley wrote: we now have early access preview Linux and Windows binaries (currently x86-64 only) at https://adoptopenjdk.net/upstream.html I would suggest using the version nomenclature per JEP 322, i.e. "A version string is a version number, $VNUM, possibly followed by pre-release, build, and other optional information, one of: $VNUM(-$PRE)?\+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)? where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build number, and $OPT is optional build information." i.e. 11.0.3-ea+6, for example. cheers, dalibor topic From gnu.andrew at redhat.com Fri Apr 26 16:00:13 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Apr 2019 17:00:13 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: On 25/04/2019 08:48, Severin Gehwolf wrote: > On Thu, 2019-04-25 at 06:24 +0000, Langer, Christoph wrote: >> Hi, >> >>> On 24/04/2019 16:08, Langer, Christoph wrote: >> >> >> >>>> But I would be fine with changing the schedule to this: >>>> >>>> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) >>>> Tuesday, May 28 2019: RDP2, Branch jdk11u-dev to jdk11u >>>> Wednesday, May 29 2019: First build (tag: jdk-11.0.4+1) >>>> Wednesday June 26 2019: Last tag before code freeze >>>> Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) >>>> >>> >>> This looks better. >>> >>> The addition I'd like to see is to start the weekly promotions earlier, >>> so they also happen in the first stage. That would avoid b01 being so >>> huge. I think that's a good halfway house between proposing entering the >>> critical fix stage next week and not promoting anything until the end of >>> May. >>> >>> That would mean multiple jdk11u-dev->jdk11u & jdk8u-dev->jdk8u merges >>> from next Wednesday 1st of May through to the final one of May 29: >>> >>> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) >>> ================= RDP1 ===================================== >>> = jdk11u tree gets changes by merge from jdk11u-dev = >>> ========================================================== >>> == >>> Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) >>> Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) >>> Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) >>> Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) >>> Wednesday, May 29 2019: Fifth and final RDP1 build (tag: jdk-11.0.4+5) >>> ================= RDP2 ===================================== >>> = jdk11u tree gets changes only by jdk11u-critical-request = >>> ========================================================== >>> == >>> Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) >>> Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) >>> Wednesday, June 19, 2019: Third RDP2 build (tag: jdk-11.0.4+8) >>> Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) >>> ================= FREEZE =================================== >>> = jdk11u sees no public changes = >>> ========================================================== >>> == >>> Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) >>> >>> This allows regular testing earlier in the cycle, but without >>> restricting the process down to critical fixes early. >> >> Sounds like a good suggestion to me as I can see the need to have EA builds early. >> I think technically we should then tag in jdk11u-dev/jdk8u-dev until the 29th of May and pull these tags into jdk11u/jdk8u. >> We'll have to confirm with ops whether this will correctly resolve the bugs in JBS (e.g. with the right build associated). > > +1 > > Thanks, > Severin > That sounds sensible. My primary concern is that something is available and tagged in 8u/11u for people not necessarily active in development to consume and test, perhaps first integrating into downstream repositories as we do with our Shenandoah repositories. If there are no objections to the above by Tuesday, I suggest we adopt the above schedule for the upcoming 8u222 & 11.0.4 releases. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gil at azul.com Fri Apr 26 16:22:37 2019 From: gil at azul.com (Gil Tene) Date: Fri, 26 Apr 2019 16:22:37 +0000 Subject: OpenJDK Updates Project Builds In-Reply-To: <515BB18C-F37C-44F6-81ED-E71F4DEF5FDF@azul.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> <515BB18C-F37C-44F6-81ED-E71F4DEF5FDF@azul.com> Message-ID: > On Apr 26, 2019, at 7:47 AM, Gil Tene wrote: > > > > Sent from my iPad > > On Apr 26, 2019, at 5:28 AM, Severin Gehwolf > wrote: > > On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: > Hi, > > the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html > are still confusingly versioned on that site, unfortunately. To quote > from [0]: > > "E.g. what tells an end user that +7 and +31 are release builds, but +6 > and +11 are not?" > > I'm not 100% clear what you mean. To answer the question: The filename? > "java -version" output? > > $ ls -1 > OpenJDK11U-x64_linux_11.0.3_6_ea.tar.gz > OpenJDK11U-x64_linux_11.0.3_7.tar.gz > > $ ./openjdk-11.0.3+6/bin/java -version > openjdk version "11.0.3-ea" 2019-04-16 > OpenJDK Runtime Environment 18.9 (build 11.0.3-ea+6) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3-ea+6, mixed mode) > > $ ./openjdk-11.0.3+7/bin/java -version > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment 18.9 (build 11.0.3+7) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode) > > For JDK 8u it won't show up in the version output, but I'm not sure > that can be helped. Archive file names still have "ea" in their name > and the build numbers show up in version output so as to distinguish > them. > > I would highly recommend/request/beg/plead that the -version string of any posed EA builds be modified to clearly identify as EA (like the 11 builds do above). And that all current builds that don?t do that be taken down ASAP to prevent damage. > > This (EA builds of 8u that show -version numbers that look very much like releases but are not) is a very serious problem. The file name, the web link, and the text in the web page don?t survive installation. And what you have left around then is a ?mystery meat? JDK that made it into the wild. These things can (and do) then end up in places and situations where vast numbers of people end up using unreleased builds, often in production, without knowing it. > > For a concrete historical example of how bad something like this can (and did) get when you don?t take care to identify EA?ness in the actual version string output: Between Sep. 2014 and March 2015 (I.e. for the ~6 month period before 8u40 was actually released) running ?docker run java:8 -version? reported the version as 8u40, with nothing to indicate the JDK you were running was experimental or EA. This was a result of an unfortunate choice to take the blessed docker java image?s JDK from a Debian unstable release, which was building an unreleased OpenJDK (with the Debian folks probably thinking ?this Debian distro and repo are clearly unstable/experimental, so people would know not to take bits from it to production?). This JDK then ended up in the ?blessed? docker image for java, with nothing to identify it as a non-released JDK. And as a result everyone that read articles like https://blog.giantswarm.io/getting-started-with-java-development-on-docker/ ended up using an 8u40 that wasn?t 8u40 without knowing it, and with no obvious way to tell, even after the real 8 u40 was released. It is likely that millions of people were affected by this. > > Bottom line: Please please please don?t put up binary builds of non-released JDKs that do not clearly identify them as such in the version actual string output. And if you did, please tear them down ASAP to limit potential damage. for specific reference: If I go to https://adoptopenjdk.net/upstream.html And follow the link labeld "Linux x86_64 8u212-b02-ea" to https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u212-b02/OpenJDK8U-x64_linux_8u212b02_ea.tar.gz And untar it It untar to a directory called openjdk-8u212-b02. If I then come back three months later looking for 8u212, I'll find this nice openjdk-8u212-b02 thing there, and if I run it I would see: gil at ubuntu:~/work/openjdk-8u212-b02$ bin/java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-b02) OpenJDK 64-Bit Server VM (build 25.212-b02, mixed mode) If I were super diligent about checking all build bumbers against konw build numbers of actual releases, I might notice that b02 was never released. But the likelihood of noticing that is very low? A "better named" directory might help a bit, but the only real place to label things is in the -version output. That's the thing all of us look at when we want to find our what a build actually is. > > > Thanks, > Severin > > > > cheers, > dalibor topic > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000962.html > > On 16.04.2019 21:49, Dalibor Topic wrote: > On 15.04.2019 12:25, Andrew Haley wrote: > we now have early access > preview Linux and Windows binaries (currently x86-64 only) at > > https://adoptopenjdk.net/upstream.html > > I would suggest using the version nomenclature per JEP 322, i.e. > > "A version string is a version number, $VNUM, possibly followed by > pre-release, build, and other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a > build > number, and $OPT is optional build information." > > i.e. 11.0.3-ea+6, for example. > > cheers, > dalibor topic From neugens at redhat.com Fri Apr 26 16:29:16 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 26 Apr 2019 18:29:16 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> <515BB18C-F37C-44F6-81ED-E71F4DEF5FDF@azul.com> Message-ID: I tend to agree with Gil here, it's a matter of consistency to have EA builds advertise as EA builds in the most clear way possible, as well as a courtesy. Cheers, Mario On Fri, Apr 26, 2019 at 6:23 PM Gil Tene wrote: > > > > > On Apr 26, 2019, at 7:47 AM, Gil Tene wrote: > > > > > > > > Sent from my iPad > > > > On Apr 26, 2019, at 5:28 AM, Severin Gehwolf > wrote: > > > > On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: > > Hi, > > > > the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html > > are still confusingly versioned on that site, unfortunately. To quote > > from [0]: > > > > "E.g. what tells an end user that +7 and +31 are release builds, but +6 > > and +11 are not?" > > > > I'm not 100% clear what you mean. To answer the question: The filename? > > "java -version" output? > > > > $ ls -1 > > OpenJDK11U-x64_linux_11.0.3_6_ea.tar.gz > > OpenJDK11U-x64_linux_11.0.3_7.tar.gz > > > > $ ./openjdk-11.0.3+6/bin/java -version > > openjdk version "11.0.3-ea" 2019-04-16 > > OpenJDK Runtime Environment 18.9 (build 11.0.3-ea+6) > > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3-ea+6, mixed mode) > > > > $ ./openjdk-11.0.3+7/bin/java -version > > openjdk version "11.0.3" 2019-04-16 > > OpenJDK Runtime Environment 18.9 (build 11.0.3+7) > > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode) > > > > For JDK 8u it won't show up in the version output, but I'm not sure > > that can be helped. Archive file names still have "ea" in their name > > and the build numbers show up in version output so as to distinguish > > them. > > > > I would highly recommend/request/beg/plead that the -version string of any posed EA builds be modified to clearly identify as EA (like the 11 builds do above). And that all current builds that don?t do that be taken down ASAP to prevent damage. > > > > This (EA builds of 8u that show -version numbers that look very much like releases but are not) is a very serious problem. The file name, the web link, and the text in the web page don?t survive installation. And what you have left around then is a ?mystery meat? JDK that made it into the wild. These things can (and do) then end up in places and situations where vast numbers of people end up using unreleased builds, often in production, without knowing it. > > > > For a concrete historical example of how bad something like this can (and did) get when you don?t take care to identify EA?ness in the actual version string output: Between Sep. 2014 and March 2015 (I.e. for the ~6 month period before 8u40 was actually released) running ?docker run java:8 -version? reported the version as 8u40, with nothing to indicate the JDK you were running was experimental or EA. This was a result of an unfortunate choice to take the blessed docker java image?s JDK from a Debian unstable release, which was building an unreleased OpenJDK (with the Debian folks probably thinking ?this Debian distro and repo are clearly unstable/experimental, so people would know not to take bits from it to production?). This JDK then ended up in the ?blessed? docker image for java, with nothing to identify it as a non-released JDK. And as a result everyone that read articles like https://blog.giantswarm.io/getting-started-with-java-development-on-docker/ ended up using an 8u40 that wasn?t 8u40 without knowing it, and with no obvious way to tell, even after the real 8 u40 was released. It is likely that millions of people were affected by this. > > > > Bottom line: Please please please don?t put up binary builds of non-released JDKs that do not clearly identify them as such in the version actual string output. And if you did, please tear them down ASAP to limit potential damage. > > for specific reference: > > If I go to https://adoptopenjdk.net/upstream.html > > And follow the link labeld "Linux x86_64 8u212-b02-ea" to https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u212-b02/OpenJDK8U-x64_linux_8u212b02_ea.tar.gz > > And untar it > > It untar to a directory called openjdk-8u212-b02. > > If I then come back three months later looking for 8u212, I'll find this nice openjdk-8u212-b02 thing there, and if I run it I would see: > > gil at ubuntu:~/work/openjdk-8u212-b02$ bin/java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-b02) > OpenJDK 64-Bit Server VM (build 25.212-b02, mixed mode) > > If I were super diligent about checking all build bumbers against konw build numbers of actual releases, I might notice that b02 was never released. But the likelihood of noticing that is very low? > > A "better named" directory might help a bit, but the only real place to label things is in the -version output. That's the thing all of us look at when we want to find our what a build actually is. > > > > > > > Thanks, > > Severin > > > > > > > > cheers, > > dalibor topic > > > > [0] > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000962.html > > > > On 16.04.2019 21:49, Dalibor Topic wrote: > > On 15.04.2019 12:25, Andrew Haley wrote: > > we now have early access > > preview Linux and Windows binaries (currently x86-64 only) at > > > > https://adoptopenjdk.net/upstream.html > > > > I would suggest using the version nomenclature per JEP 322, i.e. > > > > "A version string is a version number, $VNUM, possibly followed by > > pre-release, build, and other optional information, one of: > > > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > > $VNUM-$PRE(-$OPT)? > > $VNUM(+-$OPT)? > > > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a > > build > > number, and $OPT is optional build information." > > > > i.e. 11.0.3-ea+6, for example. > > > > cheers, > > dalibor topic > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From christoph.langer at sap.com Fri Apr 26 17:10:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Apr 2019 17:10:25 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: Hi Andrew, > >>> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > >>> ================= RDP1 > ===================================== > >>> = jdk11u tree gets changes by merge from jdk11u-dev = > >>> > ========================================================== > >>> == > >>> Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) > >>> Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) > >>> Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) > >>> Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) > >>> Wednesday, May 29 2019: Fifth and final RDP1 build (tag: jdk-11.0.4+5) > >>> ================= RDP2 > ===================================== > >>> = jdk11u tree gets changes only by jdk11u-critical-request = > >>> > ========================================================== > >>> == > >>> Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) > >>> Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) > >>> Wednesday, June 19, 2019: Third RDP2 build (tag: jdk-11.0.4+8) > >>> Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) > >>> ================= FREEZE > =================================== > >>> = jdk11u sees no public changes = > >>> > ========================================================== > >>> == > >>> Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) > >>> > >>> This allows regular testing earlier in the cycle, but without > >>> restricting the process down to critical fixes early. > >> > >> Sounds like a good suggestion to me as I can see the need to have EA > builds early. > >> I think technically we should then tag in jdk11u-dev/jdk8u-dev until the > 29th of May and pull these tags into jdk11u/jdk8u. > >> We'll have to confirm with ops whether this will correctly resolve the bugs > in JBS (e.g. with the right build associated). > > > > +1 > > > > Thanks, > > Severin > > > > That sounds sensible. My primary concern is that something is available > and tagged in 8u/11u for people not necessarily active in development to > consume and test, perhaps first integrating into downstream repositories > as we do with our Shenandoah repositories. I don't fully get your point here... so, are you saying we should also tag in jdk8u/jdk11u vs jdk8u-dev/jdk11u-dev until RDP2? The former has the disadvantage that there's some more merging back and forth and we'll probably see more merge changesets... Or do you mean to say something else? ?? Thanks Christoph From gnu.andrew at redhat.com Fri Apr 26 17:24:57 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Apr 2019 18:24:57 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: On 26/04/2019 18:10, Langer, Christoph wrote: snip.. > > I don't fully get your point here... so, are you saying we should also tag in jdk8u/jdk11u vs jdk8u-dev/jdk11u-dev until RDP2? > > The former has the disadvantage that there's some more merging back and forth and we'll probably see more merge changesets... > > Or do you mean to say something else? ?? > > Thanks > Christoph > I was agreeing with what I interpreted you to be saying, which I believe was: During RDP1: 1. Tag in jdk8u-dev/jdk11u-dev 2. Pull into jdk8u / jdk11u and thus the tag will be in both repositories. In RDP2: 1. Tag in jdk8u / jdk11u 2. Pull into jdk8u-dev / jdk11u-dev with again the end result being that the tag is in both repos. During both stages, someone not involved in development can ignore jdk8u-dev & jdk11u-dev and just pull each new tag from jdk8u & jdk11u for builds & testing. I think that keeps things simpler for downstreams who primarily want to consume the results rather than participate in their production. Hope that's clearer, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Fri Apr 26 18:35:06 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Apr 2019 18:35:06 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: > -----Original Message----- > From: Andrew John Hughes > Sent: Freitag, 26. April 2019 19:25 > To: Langer, Christoph > Cc: Severin Gehwolf ; 'jdk8u- > dev at openjdk.java.net' ; Andrew Haley > ; Aleksey Shipilev ; jdk-updates- > dev at openjdk.java.net; Lindenmaier, Goetz > Subject: Re: [11u]: 8u222 & 11.0.4 release schedule > > > > On 26/04/2019 18:10, Langer, Christoph wrote: > > snip.. > > > > > I don't fully get your point here... so, are you saying we should also tag in > jdk8u/jdk11u vs jdk8u-dev/jdk11u-dev until RDP2? > > > > The former has the disadvantage that there's some more merging back and > forth and we'll probably see more merge changesets... > > > > Or do you mean to say something else? ?? > > > > Thanks > > Christoph > > > > I was agreeing with what I interpreted you to be saying, which I believe > was: > > During RDP1: > > 1. Tag in jdk8u-dev/jdk11u-dev > 2. Pull into jdk8u / jdk11u > > and thus the tag will be in both repositories. > > In RDP2: > > 1. Tag in jdk8u / jdk11u > 2. Pull into jdk8u-dev / jdk11u-dev > > with again the end result being that the tag is in both repos. > > During both stages, someone not involved in development can ignore > jdk8u-dev & jdk11u-dev and just pull each new tag from jdk8u & jdk11u > for builds & testing. > > I think that keeps things simpler for downstreams who primarily want to > consume the results rather than participate in their production. > > Hope that's clearer, Ah, I see. So, yes, we're in full understanding and agreement then. ?? /Christoph From christoph.langer at sap.com Mon Apr 29 07:31:08 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Apr 2019 07:31:08 +0000 Subject: RFR [backport to jdk and 11u]: 8216577: Add GlobalSign's R6 Root certificate Message-ID: Hi, the change to add GlobalSign's R6 Root certificate has only been pushed to jdk12 updates (12.0.1) so far. According to [0], it was an oversight to not have it added to jdk/jdk. I also want to bring it to 11u. Taking the change to both, jdk/jdk and jdk-updates/jdk11u-dev does not apply cleanly. test/jdk/sun/security/lib/cacerts/VerifyCACerts.java fails to resolve because of changed license header and different bug ids in the @bug tag. So, please review the resolved change. It's the same for both repos. Webrev jdk/jdk: http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk/ Webrev jdk11u-dev: http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk11u-dev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8216577 Please review. @Rajan Halade: please let me know whether I shall push it to jdk/jdk or feel free to do it yourself. Thanks & Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019766.html From dalibor.topic at oracle.com Mon Apr 29 09:44:10 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 29 Apr 2019 11:44:10 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> <3d864740-027b-60b5-db57-7696f8d71fad@oracle.com> Message-ID: Thank you, Martijn. As I pointed out in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009113.html the JEP 322 version nomenclature is "A version string is a version number, $VNUM, possibly followed by pre-release, build, and other optional information, one of: $VNUM(-$PRE)?\+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)? where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build number, and $OPT is optional build information." i.e. the anchor text should be 11.0.3-ea+6, for example, rather than 11.0.3+6-ea. The component after the build number, $OPT, is used to denote a series of releases for which an implementor offers long-term support e.g., 11.0.2+13-LTS, rather than Early Access status of individual builds. cheers, dalibor topic On 26.04.2019 15:59, Martijn Verburg wrote: > Bug reports and Pull Requests welcome > https://www.github.com/adoptopenjdk/openjdk-website ;-) > > In all seriousness - closed via > https://github.com/AdoptOpenJDK/openjdk-website/pull/471 > > Cheers, > Martijn > > > On Fri, 26 Apr 2019 at 14:27, Dalibor Topic > wrote: > > On 26.04.2019 15:06, Severin Gehwolf wrote: > > > There are two separate tables, though. One for the release bits and > > another for EA. In addition to that, the rows in corresponding tables > > are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do we really > > need another "ea" added somewhere? For brevity in the table I'd > rather > > not. That's just my opinion, though. > > My experience has been that some users can get confused if (i.e. in > your > case: when) there is a build with a 'higher' version than a GA release > that's not clearly recognizable as an Early Access build in all > possible > ways. > > Basically, not everyone is necessarily an expert at JDK development or > its versioning. ;) > > cheers, > dalibor topic > > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From martijnverburg at gmail.com Mon Apr 29 09:52:53 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 29 Apr 2019 10:52:53 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> <3d864740-027b-60b5-db57-7696f8d71fad@oracle.com> Message-ID: Hi Dalibor, Sure thing, I'll pick that up in my next sweep. Cheers, Martijn On Mon, 29 Apr 2019 at 10:44, Dalibor Topic wrote: > Thank you, Martijn. > > As I pointed out in > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009113.html > the JEP 322 version nomenclature is > > "A version string is a version number, $VNUM, possibly followed by > pre-release, build, and other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build > number, and $OPT is optional build information." > > i.e. the anchor text should be 11.0.3-ea+6, for example, rather than > 11.0.3+6-ea. > > The component after the build number, $OPT, is used to denote a series > of releases for which an implementor offers long-term support e.g., > 11.0.2+13-LTS, rather than Early Access status of individual builds. > > cheers, > dalibor topic > > On 26.04.2019 15:59, Martijn Verburg wrote: > > Bug reports and Pull Requests welcome > > https://www.github.com/adoptopenjdk/openjdk-website ;-) > > > > In all seriousness - closed via > > https://github.com/AdoptOpenJDK/openjdk-website/pull/471 > > > > Cheers, > > Martijn > > > > > > On Fri, 26 Apr 2019 at 14:27, Dalibor Topic > > wrote: > > > > On 26.04.2019 15:06, Severin Gehwolf wrote: > > > > > There are two separate tables, though. One for the release bits > and > > > another for EA. In addition to that, the rows in corresponding > tables > > > are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do we > really > > > need another "ea" added somewhere? For brevity in the table I'd > > rather > > > not. That's just my opinion, though. > > > > My experience has been that some users can get confused if (i.e. in > > your > > case: when) there is a build with a 'higher' version than a GA > release > > that's not clearly recognizable as an Early Access build in all > > possible > > ways. > > > > Basically, not everyone is necessarily an expert at JDK development > or > > its versioning. ;) > > > > cheers, > > dalibor topic > > > > -- > > Oracle > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > Green Oracle Oracle is committed > to > > developing practices and products that help protect the environment > > > > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > From goetz.lindenmaier at sap.com Mon Apr 29 09:54:08 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Apr 2019 09:54:08 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: Hi, OK, as the majority seems to agree, let's push the split between jdk11u-dev and jdk11u to 28.5.2018. > During RDP1: > 1. Tag in jdk8u-dev/jdk11u-dev > 2. Pull into jdk8u / jdk11u I would like to express this differently though. I would not announce that we tag in jdk11u-dev and later in jdk11u. This can be confusing. I would phrase this differently: "From 1.5 to 28.5 merges from jdk11u-dev to jdk11u will be done weekly before tagging jdk11u." Or better: "Before RDP2, merges from jdk11u-dev to jdk11u will be done weekly before tagging jdk11u." Then, tags are always done in jdk11u, and then merged to jdk11u-dev. Also, we need to state that jdk11.0.5 development only starts on 29.5.2019. Else, it would have started 2.5.2019. And, do I understand correctly, you want to enforce RDP1 restrictions on both repos starting 1.5.2019? That would mean you can not push enhancements to jdk11u at all for four weeks! https://openjdk.java.net/jeps/3 Best regards, Goetz. > -----Original Message----- > From: Andrew John Hughes > Sent: Freitag, 26. April 2019 19:25 > To: Langer, Christoph > Cc: Severin Gehwolf ; 'jdk8u-dev at openjdk.java.net' > ; Andrew Haley ; Aleksey > Shipilev ; jdk-updates-dev at openjdk.java.net; > Lindenmaier, Goetz > Subject: Re: [11u]: 8u222 & 11.0.4 release schedule > > > > On 26/04/2019 18:10, Langer, Christoph wrote: > > snip.. > > > > > I don't fully get your point here... so, are you saying we should also tag in > jdk8u/jdk11u vs jdk8u-dev/jdk11u-dev until RDP2? > > > > The former has the disadvantage that there's some more merging back and > forth and we'll probably see more merge changesets... > > > > Or do you mean to say something else? ?? > > > > Thanks > > Christoph > > > > I was agreeing with what I interpreted you to be saying, which I believe > was: > > > and thus the tag will be in both repositories. > > In RDP2: > > 1. Tag in jdk8u / jdk11u > 2. Pull into jdk8u-dev / jdk11u-dev > > with again the end result being that the tag is in both repos. > > During both stages, someone not involved in development can ignore > jdk8u-dev & jdk11u-dev and just pull each new tag from jdk8u & jdk11u > for builds & testing. > > I think that keeps things simpler for downstreams who primarily want to > consume the results rather than participate in their production. > > Hope that's clearer, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From dalibor.topic at oracle.com Mon Apr 29 10:52:01 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 29 Apr 2019 12:52:01 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> <3d864740-027b-60b5-db57-7696f8d71fad@oracle.com> Message-ID: <9c930903-83ee-23db-594d-7035cdff7610@oracle.com> Thank you very much, Martijn. cheers, dalibor topic On 29.04.2019 11:52, Martijn Verburg wrote: > Hi Dalibor, > > Sure thing, I'll pick that up in my next sweep. > > Cheers, > Martijn > > > On Mon, 29 Apr 2019 at 10:44, Dalibor Topic > wrote: > > Thank you, Martijn. > > As I pointed out in > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009113.html > > the JEP 322 version nomenclature is > > "A version string is a version number, $VNUM, possibly followed by > pre-release, build, and other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build > number, and $OPT is optional build information." > > i.e. the anchor text should be 11.0.3-ea+6, for example, rather than > 11.0.3+6-ea. > > The component after the build number, $OPT, is used to denote a series > of releases for which an implementor offers long-term support e.g., > 11.0.2+13-LTS, rather than Early Access status of individual builds. > > cheers, > dalibor topic > > On 26.04.2019 15:59, Martijn Verburg wrote: > > Bug reports and Pull Requests welcome > > https://www.github.com/adoptopenjdk/openjdk-website ;-) > > > > In all seriousness - closed via > > https://github.com/AdoptOpenJDK/openjdk-website/pull/471 > > > > Cheers, > > Martijn > > > > > > On Fri, 26 Apr 2019 at 14:27, Dalibor Topic > > > >> wrote: > > > >? ? ?On 26.04.2019 15:06, Severin Gehwolf wrote: > > > >? ? ? > There are two separate tables, though. One for the release > bits and > >? ? ? > another for EA. In addition to that, the rows in > corresponding tables > >? ? ? > are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do > we really > >? ? ? > need another "ea" added somewhere? For brevity in the > table I'd > >? ? ?rather > >? ? ? > not. That's just my opinion, though. > > > >? ? ?My experience has been that some users can get confused if > (i.e. in > >? ? ?your > >? ? ?case: when) there is a build with a 'higher' version than a > GA release > >? ? ?that's not clearly recognizable as an Early Access build in all > >? ? ?possible > >? ? ?ways. > > > >? ? ?Basically, not everyone is necessarily an expert at JDK > development or > >? ? ?its versioning. ;) > > > >? ? ?cheers, > >? ? ?dalibor topic > > > >? ? ?-- > >? ? ?Oracle > >? ? ?Dalibor Topic | Principal Product Manager > >? ? ?Phone: +494089091214 | Mobile: +491737185961 > >? ? ? > > > >? ? ?ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg > > > >? ? ?ORACLE Deutschland B.V. & Co. KG > >? ? ?Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > >? ? ?Registergericht: Amtsgericht M?nchen, HRA 95603 > > > >? ? ?Komplement?rin: ORACLE Deutschland Verwaltung B.V. > >? ? ?Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > >? ? ?Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > >? ? ?Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val > Maher > > > >? ? ?Green Oracle Oracle is > committed to > >? ? ?developing practices and products that help protect the > environment > > > > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From gnu.andrew at redhat.com Mon Apr 29 14:03:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 15:03:46 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> On 29/04/2019 10:54, Lindenmaier, Goetz wrote: > Hi, > > OK, as the majority seems to agree, let's push the > split between jdk11u-dev and jdk11u to 28.5.2018. > This is my latest proposal [0]: March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) ================= RDP1 ===================================== = jdk11u tree gets changes by merge from jdk11u-dev = ============================================================ Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) Wednesday, May 29 2019: Fifth and final RDP1 build (tag: jdk-11.0.4+5) ================= RDP2 ===================================== = jdk11u tree gets changes only by jdk11u-critical-request = ============================================================ Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) Wednesday, June 19, 2019: Third RDP2 build (tag: jdk-11.0.4+8) Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) ================= FREEZE =================================== = jdk11u sees no public changes = ============================================================ Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) So yes, the split would be 2019-05-28 (which I presume is what you meant, not 2018 :) ) but the first merge to jdk11u would be this Wednesday. [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/001005.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Mon Apr 29 14:22:28 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Apr 2019 14:22:28 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: Hi Andrew, yes, this is the same as what I tried to phrase. Just one thing: you are mentioning RDP1. How do you want to handle this? Will we announce that only P1-P3 bugs (no P4,P5, no enhancements of priority P1-P5) may be pushed to jdk11u-dev starting tomorrow? This is what https://openjdk.java.net/jeps/3 is saying and how jdk development is handled. Or should we just say jdk11u-dev is open for development, i.e., any changes, until RDP2? And leave out mentioning RDP1. Best regards, Goetz. > -----Original Message----- > From: Andrew John Hughes > Sent: Montag, 29. April 2019 16:04 > To: Lindenmaier, Goetz ; Langer, Christoph > > Cc: Severin Gehwolf ; 'jdk8u-dev at openjdk.java.net' > ; Andrew Haley ; Aleksey > Shipilev ; jdk-updates-dev at openjdk.java.net > Subject: Re: [11u]: 8u222 & 11.0.4 release schedule > > > > On 29/04/2019 10:54, Lindenmaier, Goetz wrote: > > Hi, > > > > OK, as the majority seems to agree, let's push the > > split between jdk11u-dev and jdk11u to 28.5.2018. > > > > This is my latest proposal [0]: > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > ================= RDP1 ===================================== > = jdk11u tree gets changes by merge from jdk11u-dev = > ============================================================ > Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) > Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) > Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) > Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) > Wednesday, May 29 2019: Fifth and final RDP1 build (tag: jdk-11.0.4+5) > ================= RDP2 ===================================== > = jdk11u tree gets changes only by jdk11u-critical-request = > ============================================================ > Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) > Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) > Wednesday, June 19, 2019: Third RDP2 build (tag: jdk-11.0.4+8) > Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) > ================= FREEZE =================================== > = jdk11u sees no public changes = > ============================================================ > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) > > So yes, the split would be 2019-05-28 (which I presume is what you > meant, not 2018 :) ) but the first merge to jdk11u would be this Wednesday. > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/001005.html > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Mon Apr 29 14:50:54 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Apr 2019 14:50:54 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: Hi, To put this into concrete steps, is it ok if I do the following?: In jdk11u: Tuesday between 12:00 and 18:00 CE(S)T hg pull hg tag; run tests and build Wednesday between 12:00 and 18:00 (after tests completed): hg pull/hg merge if necessary. hg push --> publishes the tag to 11u hg pull jdk11u-dev --> this is skipped after 2019-05-28 hg merge hg push --> brings the latest changes from 11u-dev to 11u They can be tested 6 days in 11u. In jdk11u-dev: Wednesday before 18:00 CE(S)T hg pull hg pull jdk11u hg merge run tests and build Thursday after tests completed: hg pull/hg merge if necessary. hg push --> brings the latest changes and the tag from 11u to 11u-dev Best regards, Goetz. I would pick a change in jdk11u-dev before Tuesday 18:00 CET and run tests on this, and push it to jdk11u on Wednesday including the tag if all went fine. This would continue the same > -----Original Message----- > From: Andrew John Hughes > Sent: Montag, 29. April 2019 16:04 > To: Lindenmaier, Goetz ; Langer, Christoph > > Cc: Severin Gehwolf ; 'jdk8u-dev at openjdk.java.net' > ; Andrew Haley ; Aleksey > Shipilev ; jdk-updates-dev at openjdk.java.net > Subject: Re: [11u]: 8u222 & 11.0.4 release schedule > > > > On 29/04/2019 10:54, Lindenmaier, Goetz wrote: > > Hi, > > > > OK, as the majority seems to agree, let's push the > > split between jdk11u-dev and jdk11u to 28.5.2018. > > > > This is my latest proposal [0]: > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > ================= RDP1 ===================================== > = jdk11u tree gets changes by merge from jdk11u-dev = > ============================================================ > Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) > Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) > Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) > Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) > Wednesday, May 29 2019: Fifth and final RDP1 build (tag: jdk-11.0.4+5) > ================= RDP2 ===================================== > = jdk11u tree gets changes only by jdk11u-critical-request = > ============================================================ > Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) > Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) > Wednesday, June 19, 2019: Third RDP2 build (tag: jdk-11.0.4+8) > Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) > ================= FREEZE =================================== > = jdk11u sees no public changes = > ============================================================ > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) > > So yes, the split would be 2019-05-28 (which I presume is what you > meant, not 2018 :) ) but the first merge to jdk11u would be this Wednesday. > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/001005.html > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Apr 29 17:24:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 18:24:46 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> On 29/04/2019 15:22, Lindenmaier, Goetz wrote: > Hi Andrew, > > yes, this is the same as what I tried to phrase. > > Just one thing: you are mentioning RDP1. > How do you want to handle this? > Will we announce that only P1-P3 bugs (no P4,P5, > no enhancements of priority P1-P5) may be pushed > to jdk11u-dev starting tomorrow? > This is what https://openjdk.java.net/jeps/3 is saying > and how jdk development is handled. > > Or should we just say jdk11u-dev is open for development, > i.e., any changes, until RDP2? And leave out mentioning > RDP1. > > Best regards, > Goetz. > > > That's a good point and a case of bad terminology on my side :( I used "RDP1" because we were already talking about RDP2, without really thinking of the implication. Because I've been focused on the last release until the last week or so, I'm still very much of the frame of mind that we are still relatively early in the next releases and it wasn't my intention to suggest we'd be locking things down so soon. The update projects differ from the main JDK project in a number of ways: they have half the life span (three months rather than six), all changes require explicit approval as well as review, and the very nature of an update release means that it isn't the place for major new features. Hence, I'm not sure the priority matrix in JEP3 really makes much sense in our context, as a maintainer can choose to block a particular fix anyway, and, in many cases, the original priority will have been determined by someone other than the backporter. Hence, I would prefer a simpler three stage structure - development, rampdown and freeze - which is what was in my mind when I wrote the previous schedule (if not the terminology). So, for clarity: March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) =============== 11.0.3 Released ============================ = jdk11u tree gets changes by merge from jdk11u-dev = ============================================================ Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) Wednesday, May 29 2019: Fifth and final dev build (tag: jdk-11.0.4+5) ================= Rampdown ================================= = jdk11u tree gets changes only by jdk11u-critical-request = ============================================================ Wednesday, June 5, 2019: First rampdown build (tag: jdk-11.0.4+6) Wednesday, June 12, 2019: Second rampdown build (tag: jdk-11.0.4+7) Wednesday, June 19, 2019: Third rampdown build (tag: jdk-11.0.4+8) Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) ================= FREEZE =================================== = jdk11u sees no public changes = ============================================================ Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) So, we could probably start the post-release stage a week earlier in future i.e. the Wednesday of the week after the CPU, if we're happy with the same stable process. Best regards, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Apr 29 17:45:29 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 18:45:29 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: On 29/04/2019 15:50, Lindenmaier, Goetz wrote: > Hi, > > To put this into concrete steps, is it ok if I do the following?: > > In jdk11u: > Tuesday between 12:00 and 18:00 CE(S)T > hg pull > hg tag; > run tests and build > Wednesday between 12:00 and 18:00 (after tests completed): > hg pull/hg merge if necessary. > hg push --> publishes the tag to 11u As it stands, this is going to mean testing and tagging nothing, because jdk11u is at 11.0.3-ga. > hg pull jdk11u-dev --> this is skipped after 2019-05-28 > hg merge > hg push --> brings the latest changes from 11u-dev to 11u > They can be tested 6 days in 11u. > Whereas the jdk11u-dev changes are not being tested. > In jdk11u-dev: > Wednesday before 18:00 CE(S)T > hg pull > hg pull jdk11u > hg merge > run tests and build > Thursday after tests completed: > hg pull/hg merge if necessary. > hg push --> brings the latest changes and the tag from 11u to 11u-dev > > Best regards, > Goetz. > > > This was my thinking (and thus my plan for 8u): Development stage (2019-05-01 to 2019-05-29): jdk11u-dev: $ hg pull If all good: $ hg tag jdk-11.0.4+x $ hg push jdk11u: $ hg pull $ hg pull jdk11u-dev $ hg merge (if necessary) I don't think a merge should be necessary as jdk11u-dev is a superset of jdk11u and that merge has already been performed in pulling jdk-11.0.3-ga into jdk11u-dev. At rampdown: jdk11u-dev is tagged jdk-11.0.5+0 Rampdown stage (2019-06-05 to 2019-06-26): jdk11u: $ hg pull If all good: $ hg tag jdk-11.0.4+y $ hg push jdk11u-dev: $ hg pull $ hg pull jdk11u $ hg merge Merging will be necessary as jdk11u will contain 11.0.5 changes by this point. In other words, the same process takes place in both stages, but the repositories switch roles; in the development stage, jdk11u-dev is the master receiving changes and is merged into jdk11u, while in the rampdown stage, jdk11u is now receiving changes for that release and is merged into jdk11u-dev. What testing do you do? And what would be regarded as a showstopper? One of my aims this time around is to do more frequent downstream merges so I can test each tag on a wider range of architectures, and not be caught out by arch-specific build failures late in the cycle. Best regards, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Mon Apr 29 18:53:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Apr 2019 18:53:25 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> Message-ID: > -----Original Message----- > From: Andrew John Hughes > Sent: Montag, 29. April 2019 19:25 > To: Lindenmaier, Goetz ; Langer, Christoph > > Cc: Severin Gehwolf ; 'jdk8u- > dev at openjdk.java.net' ; Andrew Haley > ; Aleksey Shipilev ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u]: 8u222 & 11.0.4 release schedule > > > > On 29/04/2019 15:22, Lindenmaier, Goetz wrote: > > Hi Andrew, > > > > yes, this is the same as what I tried to phrase. > > > > Just one thing: you are mentioning RDP1. > > How do you want to handle this? > > Will we announce that only P1-P3 bugs (no P4,P5, > > no enhancements of priority P1-P5) may be pushed > > to jdk11u-dev starting tomorrow? > > This is what https://openjdk.java.net/jeps/3 is saying > > and how jdk development is handled. > > > > Or should we just say jdk11u-dev is open for development, > > i.e., any changes, until RDP2? And leave out mentioning > > RDP1. > > > > Best regards, > > Goetz. > > > > > > > > That's a good point and a case of bad terminology on my side :( > I used "RDP1" because we were already talking about RDP2, without really > thinking of the implication. Because I've been focused on the last > release until the last week or so, I'm still very much of the frame of > mind that we are still relatively early in the next releases and it > wasn't my intention to suggest we'd be locking things down so soon. > > The update projects differ from the main JDK project in a number of > ways: they have half the life span (three months rather than six), all > changes require explicit approval as well as review, and the very nature > of an update release means that it isn't the place for major new > features. Hence, I'm not sure the priority matrix in JEP3 really makes > much sense in our context, as a maintainer can choose to block a > particular fix anyway, and, in many cases, the original priority will > have been determined by someone other than the backporter. > > Hence, I would prefer a simpler three stage structure - development, > rampdown and freeze - which is what was in my mind when I wrote the > previous schedule (if not the terminology). +1 to what you are saying here. I think JEP 3 applies to upstream jdk release development. But for the update projects it only applies in parts. We'll have to define our own stages and fix criteria. I like this thinking of three stages: development, rampdown and freeze. I already tried to spell out the fix criteria for ramp down in the Wiki like this: ...The maintainers will only consider fixes that Oracle have brought to their corresponding JDK 11 update release, fixes for high priority issues or important test fixes at this point... Once we agree on this, I can change the description in the Wiki in that sense. > > So, for clarity: > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > =============== 11.0.3 Released ============================ > = jdk11u tree gets changes by merge from jdk11u-dev = > ========================================================== > == > Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) > Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) > Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) > Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) > Wednesday, May 29 2019: Fifth and final dev build (tag: jdk-11.0.4+5) > ================= Rampdown > ================================= > = jdk11u tree gets changes only by jdk11u-critical-request = > ========================================================== > == > Wednesday, June 5, 2019: First rampdown build (tag: jdk-11.0.4+6) > Wednesday, June 12, 2019: Second rampdown build (tag: jdk-11.0.4+7) > Wednesday, June 19, 2019: Third rampdown build (tag: jdk-11.0.4+8) > Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) > ================= FREEZE =================================== > = jdk11u sees no public changes = > ========================================================== > == > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) > > So, we could probably start the post-release stage a week earlier in > future i.e. the Wednesday of the week after the CPU, if we're happy with > the same stable process. Sounds good. A schedule to publish on the Wiki could be this (I wouldn't explicitly mention build tags there): OpenJDK 11.0.4 March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) Tuesday, May 28 2019, 12:00 CEST: Rampdown phase start, last merge jdk11u-dev->jdk11u Tuesday, June 25 2019, 12:00 CEST: Code freeze, jdk11u closed Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) Thoughts? Best regards Christoph From christoph.langer at sap.com Mon Apr 29 18:55:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Apr 2019 18:55:10 +0000 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> References: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> Message-ID: Hi Andrew, any news (from ops) on that one? Before we merge anything into jdk11u or jdk8u (later this week hopefully), this needs to be set up correctly. Otherwise, we'll blow the JBS history for 11.0.3... Thanks Christoph > -----Original Message----- > From: Andrew Haley > Sent: Mittwoch, 24. April 2019 15:07 > To: Langer, Christoph > Cc: 'jdk8u-dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net; 'Andrew John Hughes' > > Subject: Re: Set new hgupdater versions for jdk8u and jdk11u > > On 4/24/19 1:15 PM, Langer, Christoph wrote: > > as the April CPU is out of the door and we don't expect any more changes > for OpenJDK 8u212 and 11.0.3, I think it's time to ask ops to bump the > versions for hgupdater in the release branches: > > > > https://hg.openjdk.java.net/jdk8u/ -> openjdk8u222 > > http://hg.openjdk.java.net/jdk-updates/jdk11u/ -> 11.0.4 > > > > The new setting needs to be active before we can merge from dev to > release. > > Yep, was about to. Thanks for the reminder. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon Apr 29 19:01:42 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 20:01:42 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> Message-ID: snip... > > A schedule to publish on the Wiki could be this (I wouldn't explicitly mention build tags there): > > OpenJDK 11.0.4 > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) > Tuesday, May 28 2019, 12:00 CEST: Rampdown phase start, last merge jdk11u-dev->jdk11u > Tuesday, June 25 2019, 12:00 CEST: Code freeze, jdk11u closed > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > > Thoughts? > > Best regards > Christoph > Looks good to me. The date & times of the phases are helpful, because those are the cut-offs for actual changes going in, rather than the Wednesday dates when tags are pushed. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Apr 29 20:00:53 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 21:00:53 +0100 Subject: RFR [backport to jdk and 11u]: 8216577: Add GlobalSign's R6 Root certificate In-Reply-To: References: Message-ID: <899b9135-3970-ea73-737c-5165dfec8e49@redhat.com> On 29/04/2019 08:31, Langer, Christoph wrote: > Hi, > > the change to add GlobalSign's R6 Root certificate has only been pushed to jdk12 updates (12.0.1) so far. According to [0], it was an oversight to not have it added to jdk/jdk. I also want to bring it to 11u. > > Taking the change to both, jdk/jdk and jdk-updates/jdk11u-dev does not apply cleanly. test/jdk/sun/security/lib/cacerts/VerifyCACerts.java fails to resolve because of changed license header and different bug ids in the @bug tag. So, please review the resolved change. It's the same for both repos. > > Webrev jdk/jdk: http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk/ > Webrev jdk11u-dev: http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk11u-dev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8216577 > > Please review. > > @Rajan Halade: please let me know whether I shall push it to jdk/jdk or feel free to do it yourself. > > Thanks & Best regards > Christoph > > [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019766.html > 11u change looks fine to me. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Mon Apr 29 20:55:35 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Apr 2019 20:55:35 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: Hi Andrew, at the end of last week I was thinking the same as you with regards on how we should do the pulling, merging and tagging. However, today Goetz came back from vacation and we discussed this a bit in more and came up with the approach he suggested in his mail. I actually think the approach as outlined by Goetz will help to have higher quality in the tags and we also don't ever need to flip repositories. The only change in week-to-week process would be to stop the integration from jdk11u-dev to jdk11u on the Wednesday when we reach ramp down. During the development stage, we'll pull each Wednesday from jdk11u-dev and will then have 6 days until the following Wednesday to fix high priority issues such as build failures or whatever exceptional thing we can think of (which will hopefully all be rather seldom though). Find below some comments on your remarks: > On 29/04/2019 15:50, Lindenmaier, Goetz wrote: > > Hi, > > > > To put this into concrete steps, is it ok if I do the following?: > > > > In jdk11u: > > Tuesday between 12:00 and 18:00 CE(S)T > > hg pull > > hg tag; > > run tests and build > > Wednesday between 12:00 and 18:00 (after tests completed): > > hg pull/hg merge if necessary. > > hg push --> publishes the tag to 11u > > As it stands, this is going to mean testing and tagging nothing, because > jdk11u is at 11.0.3-ga. Obviously, before we do a first tag in jdk11u we have to pull something from jdk11u-dev. Otherwise we would tag nothing. So, for this week I think we should pull jdk11u-dev on Wednesday and tag 11.0.3+1 next Tuesday. As of now, we must not pull anything over to jdk11u anyway, since there's no indication that hgupdater has been updated on jdk11u to account for 11.0.4. Probably, after we have word by ops that hgupdater is up to date, we should pull one test patch first to see if everything really works correctly. The good thing if we were to tag the first build only next week is that we have a few more days to have ops complete their work. > > hg pull jdk11u-dev --> this is skipped after 2019-05-28 > > hg merge > > hg push --> brings the latest changes from 11u-dev to 11u > > They can be tested 6 days in 11u. > > > > Whereas the jdk11u-dev changes are not being tested. See my comment above. ?? > > In jdk11u-dev: > > Wednesday before 18:00 CE(S)T > > hg pull > > hg pull jdk11u > > hg merge > > run tests and build > > Thursday after tests completed: > > hg pull/hg merge if necessary. > > hg push --> brings the latest changes and the tag from 11u to 11u-dev > > > What testing do you do? And what would be regarded as a showstopper? As for our testing: Goetz had enumerated it here a while ago: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html Showstoppers for tags would merely be build errors, I guess. Probably also very severe regressions compared to the last tag... Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html From christoph.langer at sap.com Mon Apr 29 20:57:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Apr 2019 20:57:53 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> Message-ID: If we were to do the process suggested by Goetz, I'd have to make one change to the timeline (since we'd pull jdk11u-dev -> jdk11u on Wednesday): Wednesday, May 29 2019, 12:00 CEST: Rampdown phase start, last merge jdk11u-dev->jdk11u > > A schedule to publish on the Wiki could be this (I wouldn't explicitly > mention build tags there): > > > > OpenJDK 11.0.4 > > > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > > Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) > > Tuesday, May 28 2019, 12:00 CEST: Rampdown phase start, last merge jdk11u-dev->jdk11u > > Tuesday, June 25 2019, 12:00 CEST: Code freeze, jdk11u closed > > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > > > > Thoughts? > > > > Best regards > > Christoph > > > > Looks good to me. > > The date & times of the phases are helpful, because those are the > cut-offs for actual changes going in, rather than the Wednesday dates > when tags are pushed. > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Apr 30 02:34:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 30 Apr 2019 03:34:14 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: <78f11d5f-dd4d-3bb8-4baf-bf3bf8f899e4@redhat.com> On 29/04/2019 21:55, Langer, Christoph wrote: > Hi Andrew, > > at the end of last week I was thinking the same as you with regards on how we should do the pulling, merging and tagging. However, today Goetz came back from vacation and we discussed this a bit in more and came up with the approach he suggested in his mail. I actually think the approach as outlined by Goetz will help to have higher quality in the tags and we also don't ever need to flip repositories. The only change in week-to-week process would be to stop the integration from jdk11u-dev to jdk11u on the Wednesday when we reach ramp down. During the development stage, we'll pull each Wednesday from jdk11u-dev and will then have 6 days until the following Wednesday to fix high priority issues such as build failures or whatever exceptional thing we can think of (which will hopefully all be rather seldom though). > > Find below some comments on your remarks: > >> On 29/04/2019 15:50, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> To put this into concrete steps, is it ok if I do the following?: >>> >>> In jdk11u: >>> Tuesday between 12:00 and 18:00 CE(S)T >>> hg pull >>> hg tag; >>> run tests and build >>> Wednesday between 12:00 and 18:00 (after tests completed): >>> hg pull/hg merge if necessary. >>> hg push --> publishes the tag to 11u >> >> As it stands, this is going to mean testing and tagging nothing, because >> jdk11u is at 11.0.3-ga. > > Obviously, before we do a first tag in jdk11u we have to pull something from jdk11u-dev. Otherwise we would tag nothing. So, for this week I think we should pull jdk11u-dev on Wednesday and tag 11.0.3+1 next Tuesday. > > As of now, we must not pull anything over to jdk11u anyway, since there's no indication that hgupdater has been updated on jdk11u to account for 11.0.4. Probably, after we have word by ops that hgupdater is up to date, we should pull one test patch first to see if everything really works correctly. The good thing if we were to tag the first build only next week is that we have a few more days to have ops complete their work. > >>> hg pull jdk11u-dev --> this is skipped after 2019-05-28 >>> hg merge >>> hg push --> brings the latest changes from 11u-dev to 11u >>> They can be tested 6 days in 11u. >>> >> >> Whereas the jdk11u-dev changes are not being tested. > > See my comment above. ?? > >>> In jdk11u-dev: >>> Wednesday before 18:00 CE(S)T >>> hg pull >>> hg pull jdk11u >>> hg merge >>> run tests and build >>> Thursday after tests completed: >>> hg pull/hg merge if necessary. >>> hg push --> brings the latest changes and the tag from 11u to 11u-dev >>> > > > > >> What testing do you do? And what would be regarded as a showstopper? > > As for our testing: Goetz had enumerated it here a while ago: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html > Showstoppers for tags would merely be build errors, I guess. Probably also very severe regressions compared to the last tag... > > Best regards > Christoph > > [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html > I find this very confusing. You may not have to change things over in the different stages, but you instead have this odd situation where you essentially run a week behind, and tag a bunch of changes that are, by then, a week old. I think what I suggested is a lot clearer. I spent a good five minutes reading over this and still not sure I have it right. I'm not sure how this leads to "higher quality" as you're still tagging the same thing. The issue with hgupdater is easily resolved in my scenario by just not touching jdk11u until it's ready. The tags will be still added in jdk11u-dev. The pull in jdk11u is simply delayed. It's not clear to me what happens in your case. Do you push the changes to jdk11u but not tag them? Or is it all just kept locally for a week? Best regards, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Tue Apr 30 07:37:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 30 Apr 2019 07:37:46 +0000 Subject: RFR: TEST_BUG: 8222027 - java/util/logging/LogManager/TestLoggerNames.java generates intermittent ClassCastException In-Reply-To: References: <1a9a27e6-d196-3fa1-fda4-9a3a80b327cc@oracle.com> <14b3c862-a744-28a8-d40c-652fdc5dadc2@oracle.com> <9611d3c0f66f68e46800174c09c81d6771581ca1.camel@redhat.com> Message-ID: Hi Steve, the fix has been approved for 12u and I've just pushed it there. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Steve Groeger > Sent: Freitag, 26. April 2019 12:23 > To: Severin Gehwolf > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: RFR: TEST_BUG: 8222027 - > java/util/logging/LogManager/TestLoggerNames.java generates intermittent > ClassCastException > > Hi Severin, > > Thanks. I have updated the issue with a Fix Request comment and the label > for jdk12u-fix-request. > Hopefully this will get approved and the fix will then be made into > jdk12u. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > From: Severin Gehwolf > To: Steve Groeger , > jdk-updates-dev at openjdk.java.net > Date: 26/04/2019 10:38 > Subject: Re: RFR: TEST_BUG: 8222027 - > java/util/logging/LogManager/TestLoggerNames.java generates intermittent > ClassCastException > > > > Hi Steve, > > On Fri, 2019-04-26 at 09:50 +0100, Steve Groeger wrote: > > Hi all, > > > > The fix for this bug [1] was made on the jdk repository with this [2] > and > > I have requested that this be backported to jdk11u. > > The request have been approved but I need someone to sponsor this > change > > > and to then merge it into jdk11u-dev. > > I have tested that the patch installed cleanly on jdk11u and all the > tests > > work. > > Would be grateful if someone could take a look at this and get it merged > > > for me. > > I've pushed the fix: > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__hg.openjdk.java.net_jdk-2Dupdates_jdk11u- > 2Ddev_rev_b3f7a4c524f2&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=UjaAayv2ElbWasFpR01x7goiz8NVVe0zcUiKZ > _KfgyU&s=-0cX6FuM_1aZ_o8L0mVyYuAU9dwvH5K3wmyT8lXN-HM&e= > > > It'll flow into jdk11u from jdk11u-dev via JDK 11u maintainer merges. > > As the fix is in JDK 13, but not JDK 12, I'd suggest to also "Fix > Request" it for JDK 12u too. Adding the label jdk12u-fix-request should > be enough with a similar comment as for the JDK 11 fix request comment, > but pertaining to JDK 12. > > Thanks, > Severin > > > [1] > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__bugs.openjdk.java.net_browse_JDK- > 2D8222027&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=UjaAayv2ElbWasFpR01x7goiz8NVVe0zcUiKZ > _KfgyU&s=mqvWnEUwL7ljIDeJ6CfBjG1q6D5WajkNL6ICjY9wcEE&e= > > > [2] > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__hg.openjdk.java.net_jdk_jdk_rev_e5713cefcf41&d=DwICaQ&c=jf_iaSH > vJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=UjaAayv2ElbWasFpR01x7goiz8NVVe0zcUiKZ > _KfgyU&s=Al5CSrp3R_pedrqbEKydQbty2Trhp2wKmiMYCeZfGMc&e= > > > > > > > Thanks > > Steve Groeger > > IBM Runtime Technologies > > Hursley, Winchester > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > > > > > From: Daniel Fuchs > > To: Steve Groeger > > Cc: OpenJDK Core Libs Developers > > Date: 08/04/2019 17:57 > > Subject: Re: RFR: TEST_BUG: 8222027 - > > java/util/logging/LogManager/TestLoggerNames.java generates > intermittent > > > ClassCastException > > > > > > > > Thanks Steve, > > > > I just pushed it: > > > > > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__hg.openjdk.java.net_jdk_jdk_rev_e5713cefcf41&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=NPuRuuPQmKIyeueDfyqjCSPLX8pC2jDZknJJ > SkghSnk&s=qu6UUeh3WsRz3MbcR-fk9BTLMUeMiCuDJCmxFlYxyEU&e= > > > > > > > best regards, > > > > -- daniel > > > > On 08/04/2019 15:13, Steve Groeger wrote: > > > Hi Daniel, > > > > > > Thanks, have created a new webrev [1] > > > Once it is merged I will then work on getting it back-ported to > jdk11u. > > > Thanks for all your assistance in getting this done. > > > > > > [1] _ > > > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__cr.openjdk.java.net_-7Esgroeger_8222027_webrev.04_-5F&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=NPuRuuPQmKIyeueDfyqjCSPLX8pC2jDZknJJ > SkghSnk&s=3YXbO9kAFGPVqZYB1YpmAh-17boBEL9sDAQ08Ksa-7E&e= > > > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU From christoph.langer at sap.com Tue Apr 30 09:26:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 30 Apr 2019 09:26:25 +0000 Subject: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 Message-ID: Hi, please help reviewing the backport of JDK-8210782: Upgrade HarfBuzz to the latest 2.3.1. This has been backported to 11.0.4-oracle already. I took the large change down to 11u-dev. It applies quite nicely, apart from a little issue in make/lib/Awt2dLibraries.gmk: --- Awt2dLibraries.gmk +++ Awt2dLibraries.gmk @@ -613,8 +614,7 @@ type-limits missing-field-initializers implicit-fallthrough \ strict-aliasing undef unused-function, \ DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ - maybe-uninitialized \ - missing-attributes class-memaccess, \ + maybe-uninitialized class-memaccess, \ DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \ tautological-constant-out-of-range-compare int-to-pointer-cast \ sign-compare undef missing-field-initializers, \ The original change would remove the disabling of the "missing-attributes" warnings, but since this warning type is not disabled in jdk11u-dev currently, I would just skip that diff. With that change, most platforms did build fine, except for Solaris (where we use Oracle Studio 12u4 in jdk11u-dev vs Oracle Studio 12u6 in jdk/jdk) and AIX (xlc12 vs. xlc16). To keep support for Oracle Studio 12u4 for Solaris, I had to remove the warning flag "refmemnoconstr_aggr" from line 622 (as opposed to the original change). Seems that it is not yet supported in OS12u4. Furthermore, a code tweak had to be done (Thanks, Matthias, for your help here): --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-subset-cff-common.hh Fri Mar 01 16:59:19 2019 -0800 +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-subset-cff-common.hh Mon Apr 29 16:26:41 2019 +0200 @@ -280,6 +280,10 @@ { str_buff_t &flatStr; bool drop_hints; + + // Solaris: OS12u4 complains about "A class with a reference member lacks a user-defined constructor" + // so provide the constructor + flatten_param_t(str_buff_t& sbt, bool dh) : flatStr(sbt), drop_hints(dh) {} }; template @@ -305,7 +309,9 @@ return false; cs_interpreter_t interp; interp.env.init (str, acc, fd); - flatten_param_t param = { flat_charstrings[i], drop_hints }; + // Solaris: OS12u4 does not like the C++11 style init + // flatten_param_t param = { flat_charstrings[i], drop_hints }; + flatten_param_t param(flat_charstrings[i], drop_hints); if (unlikely (!interp.interpret (param))) return false; } For AIX, this tweak had to be added (credit goes to Matthias as well): diff -r 2b3dbedfbfb9 src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh Fri Mar 01 16:59:19 2019 -0800 +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh Mon Apr 29 16:26:41 2019 +0200 @@ -83,7 +83,9 @@ template struct _hb_assign -{ static inline void value (T &o, const V v) { o = v; } }; +// add cast to please AIX xlc12.1 +//{ static inline void value (T &o, const V v) { o = v; } }; +{ static inline void value (T &o, const V v) { o = (T&) v; } }; template struct _hb_assign > { static inline void value (T &o, const V v) { o.set (v); } }; Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/7c11a7cc7c1d Review discussion for jdk/jdk: https://mail.openjdk.java.net/pipermail/2d-dev/2019-March/009914.html New Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8210782.jdk11u/ Thanks & Best regards Christoph From goetz.lindenmaier at sap.com Tue Apr 30 12:40:55 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 30 Apr 2019 12:40:55 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: Hi Andrew, > > To put this into concrete steps, is it ok if I do the following?: > > > > In jdk11u: > > Tuesday between 12:00 and 18:00 CE(S)T > > hg pull > > hg tag; > > run tests and build > > Wednesday between 12:00 and 18:00 (after tests completed): > > hg pull/hg merge if necessary. > > hg push --> publishes the tag to 11u > As it stands, this is going to mean testing and tagging nothing, because > jdk11u is at 11.0.3-ga. Well, obviously this is only the initial case. I could have pulled from jdk11u-dev last week if I had known. Exceptionally, I could pull right now. I tried to run this discussion 4 weeks ago, but did not get much feedback. The hg-updater issue is blocking us, anyways. If we now pull to jdk11u, it will all be tagged as going to 11.0.3. > > hg pull jdk11u-dev --> this is skipped after 2019-05-28 > > hg merge > > hg push --> brings the latest changes from 11u-dev to 11u > > They can be tested 6 days in 11u. > > > Whereas the jdk11u-dev changes are not being tested. They would be tested from there on in jdk11u. Who keeps us from doing fixes in jdk11u in those 6 days? > > In jdk11u-dev: > > Wednesday before 18:00 CE(S)T > > hg pull > > hg pull jdk11u > > hg merge > > run tests and build > > Thursday after tests completed: > > hg pull/hg merge if necessary. > > hg push --> brings the latest changes and the tag from 11u to 11u-dev > > > > This was my thinking (and thus my plan for 8u): > > Development stage (2019-05-01 to 2019-05-29): > > jdk11u-dev: > > $ hg pull > > If all good: > > $ hg tag jdk-11.0.4+x > $ hg push > > jdk11u: > > $ hg pull > $ hg pull jdk11u-dev > $ hg merge (if necessary) > > I don't think a merge should be necessary as jdk11u-dev is a superset of > jdk11u and that merge has already been performed in pulling > jdk-11.0.3-ga into jdk11u-dev. > > At rampdown: jdk11u-dev is tagged jdk-11.0.5+0 > > Rampdown stage (2019-06-05 to 2019-06-26): > > jdk11u: > > $ hg pull > > If all good: > > $ hg tag jdk-11.0.4+y > $ hg push > > jdk11u-dev: > > $ hg pull > $ hg pull jdk11u > $ hg merge > > Merging will be necessary as jdk11u will contain 11.0.5 changes by this > point. > > In other words, the same process takes place in both stages, but the > repositories switch roles; in the development stage, jdk11u-dev is the > master receiving changes and is merged into jdk11u, while in the > rampdown stage, jdk11u is now receiving changes for that release and is > merged into jdk11u-dev. I think we should not concentrate on reducing the hg commands on our side. We should try to build a process that is easy to communicate and understand for those that are not as involved as we are. If we always tag in jdk11u, we can say: "jdk11u is the consolidation repository for the next release" Now the message is: up to this day we do work in jdk11u-dev, from that on in jdk11u. And it raises the question: why is it merged to jdk11u? It's the same anyways! Thus, following your approach, I would propose to skip merging to jdk11u until start of the rampdown. > What testing do you do? We build and test jdk11u-dev and jdk11u as Christoph pointed out announced here https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html on a daily basis. This is all automated and backed by a database where we can see test failures about half a year back. We still add new tests, recently we added jtreg tests nashorn, jaxp and langtools. (Adding test always means to fix a lot of test bugs and setup issues.) The builds of jdk11u-dev include a mercurial patch queue with the changes we are working on. Therefore the test results are not that reliable ... well, it is a dev code line :) Further tests are done in our SapMachine infrastructure. The SapMachine build is only triggered if a tag arrives in the jdk11u code line. Finally we distribute prerelease builds to departments in our company that use it for testing. As there only is a window of four weeks from RDP2 to the code freeze, feedback from these will probably go directly to SapMachine and then to the next OpenJDK 11u release. But we will share issues and try to get fixes into the current OpenJDK release. These tests with real applications often show incompatibilities in the jdk changes ... > And what would be regarded as a showstopper? If we have 6 days in jdk11u before the tag, we could push an urgent fix directly to jdk11u before adding the tag. I.e., we could hopefully avoid showstoppers. I think we should only skip or delay a tag in very rare cases, as downstream work depends on the tags. Instead, we should open bugs and refer to the tag that shows the bug. > One of my aims this time around is to do more frequent downstream merges > so I can test each tag on a wider range of architectures, and not be > caught out by arch-specific build failures late in the cycle. That would be great :) Best regards, Goetz. > > Best regards, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Tue Apr 30 12:43:08 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 30 Apr 2019 12:43:08 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> Message-ID: Hi Andrew, ... sorry for all these long mails :) ... but I think it's important to get to a common understanding of all the motivations behind these things. So here I go: > That's a good point and a case of bad terminology on my side :( > I used "RDP1" because we were already talking about RDP2, without really > thinking of the implication. Because I've been focused on the last > release until the last week or so, I'm still very much of the frame of > mind that we are still relatively early in the next releases and it > wasn't my intention to suggest we'd be locking things down so soon. Ok. > The update projects differ from the main JDK project in a number of > ways: they have half the life span (three months rather than six), all > changes require explicit approval as well as review, and the very nature > of an update release means that it isn't the place for major new > features. Hence, I'm not sure the priority matrix in JEP3 really makes > much sense in our context, as a maintainer can choose to block a > particular fix anyway, and, in many cases, > the original priority will > have been determined by someone other than the backporter. It's not a priority that expresses how urgent to work on it. It is a rating at how severe the bug is. It is not well documented: https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report but this at least helps a bit. In the end, it is the assessment of the persons that worked on the bug, who are experts on the issue. Thus I think it well applies to an updates project. And yes, the changes brought to the updates project are more stable/smaller than in a new release. But on the other side introducing a regression is much more severe. The security updates go to productive systems with much less testing than for new releases. Finally I think all the people in the OpenJDK community are familiar with the OpenJDK development process. To make the jdk11u process easy to understand, we should use as much of the terminology etc. that is also used in the development of new releases, documented on all the wiki pages, and known to the developers. Again, this is not about me, you, Christoph, Aleksey or Andrew Haley, it's all about the other contributors. It must be simple to understand for them. What I would like is: jdk11u-dev: push anything, no tags, jdk11u-fix-request. jdk11u: rampdown of next release. push according to rules. tagged. jdk11u-critical-request. 4 weeks RDP2 4 weeks RDP1 3 weeks RC / frozen (Always open to all changes downported by Oracle). Or maybe 3+3+2 weeks ... This gives three months 'free' development for a release in 11u-dev plus 11 weeks of rampdown in 11u. (The 4 additional merges 11u-dev->11u shorten this by 4 weeks rampdown and pushes the start of n+1 development back 4 weeks.) But I already gave up on this simple thing with longer rampdown :). Which is fine... and also the reason we have our own build (SapMachine) where we can do quick fixes and releases on our own. > Hence, I would prefer a simpler three stage structure - development, > rampdown and freeze - which is what was in my mind when I wrote the > previous schedule (if not the terminology). > > So, for clarity: > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > =============== 11.0.3 Released ============================ > = jdk11u tree gets changes by merge from jdk11u-dev = > ============================================================ > Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) > Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) > Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) > Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) > Wednesday, May 29 2019: Fifth and final dev build (tag: jdk-11.0.4+5) > ================= Rampdown ================================= > = jdk11u tree gets changes only by jdk11u-critical-request = Could you give a specification of what changes qualify to be pushed in this phase? I think we need to document this for the 11u project if we don't reuse the established terms. E.g., a contributor needs to know whether to hurry to catch the deadline of the start of the rampdown phase. Also, If I want to downport a bug, I want to have some way to determine which repo to target with it. > ============================================================ > Wednesday, June 5, 2019: First rampdown build (tag: jdk-11.0.4+6) > Wednesday, June 12, 2019: Second rampdown build (tag: jdk-11.0.4+7) > Wednesday, June 19, 2019: Third rampdown build (tag: jdk-11.0.4+8) > Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) > ================= FREEZE =================================== > = jdk11u sees no public changes = > ============================================================ > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) > > So, we could probably start the post-release stage a week earlier in > future i.e. the Wednesday of the week after the CPU, if we're happy with > the same stable process. Maybe we should even start regular tagging in jdk11u-dev right after we bumped the version to 11.0.5 ... there seems to be a need of tagged development versions, as the downstream builds are triggered by tags. Best regards, Goetz. > > Best regards, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Tue Apr 30 12:48:15 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 30 Apr 2019 12:48:15 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> Message-ID: Hi everybody, According to below schedule, I will tag SAPs nightbuild of jdk11u-dev of Tuesday evening on Wednesday after testing and push the tag to jdk11u-dev. Best regards, Goetz. > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > =============== 11.0.3 Released ============================ > = jdk11u tree gets changes by merge from jdk11u-dev = > ============================================================ > Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) > Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) > Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) > Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) > Wednesday, May 29 2019: Fifth and final dev build (tag: jdk-11.0.4+5) > ================= Rampdown ================================= > = jdk11u tree gets changes only by jdk11u-critical-request = > ============================================================ > Wednesday, June 5, 2019: First rampdown build (tag: jdk-11.0.4+6) > Wednesday, June 12, 2019: Second rampdown build (tag: jdk-11.0.4+7) > Wednesday, June 19, 2019: Third rampdown build (tag: jdk-11.0.4+8) > Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) > ================= FREEZE =================================== > = jdk11u sees no public changes = > ============================================================ > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) > > So, we could probably start the post-release stage a week earlier in > future i.e. the Wednesday of the week after the CPU, if we're happy with > the same stable process. > > Best regards, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From takiguc at linux.vnet.ibm.com Tue Apr 30 13:18:10 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 30 Apr 2019 22:18:10 +0900 Subject: [11u] RDR: backport JDK-8211300 and JDK-8212678 In-Reply-To: <31798457-f327-ce17-5a65-635307eb83ca@redhat.com> References: <4a2e3503bb41c292eb4c6d9587735157@linux.vnet.ibm.com> <31798457-f327-ce17-5a65-635307eb83ca@redhat.com> Message-ID: Hello Aleksey. I'm sorry, I might see different bugid... Do I have to wait for approval for JDK-8211300 ? Or, should I rewrite JDK-8212678's fix ? Thanks, Ichiroh Takiguchi On 2019-04-26 04:46, Aleksey Shipilev wrote: > On 4/25/19 8:18 PM, Ichiroh Takiguchi wrote: >> JDK-8211300 Convert C-style array declarations in JDK client code [1] > > You don't have jdk11u-fix-yes for this one. > >> JDK-8212678 Windows IME related patch [2] > > ...so this cannot be applied too? > > -Aleksey From aph at redhat.com Tue Apr 30 14:09:27 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 30 Apr 2019 15:09:27 +0100 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: References: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> Message-ID: On 4/29/19 7:55 PM, Langer, Christoph wrote: > Hi Andrew, > > any news (from ops) on that one? > > Before we merge anything into jdk11u or jdk8u (later this week hopefully), this needs to be set up correctly. Otherwise, we'll blow the JBS history for 11.0.3... Yes. There was some confusion because we have to set 8u and 8u-dev to the same version. I have confirmed. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue Apr 30 14:14:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 30 Apr 2019 14:14:01 +0000 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: References: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> Message-ID: > > Hi Andrew, > > > > any news (from ops) on that one? > > > > Before we merge anything into jdk11u or jdk8u (later this week hopefully), > this needs to be set up correctly. Otherwise, we'll blow the JBS history for > 11.0.3... > > Yes. There was some confusion because we have to set 8u and 8u-dev to the > same version. > I have confirmed. Hm, what exactly do you mean? You have confirmation from ops that the change should be done from their end? We can proceed merging stuff into jdk8u and jdk11u? Thanks Christoph From aph at redhat.com Tue Apr 30 14:56:00 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 30 Apr 2019 15:56:00 +0100 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: References: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> Message-ID: <0aaa1010-6287-fc64-9316-2a1625d038a7@redhat.com> On 4/30/19 3:14 PM, Langer, Christoph wrote: > Hm, what exactly do you mean? You have confirmation from ops that the change should be done from their end? We can proceed merging stuff into jdk8u and jdk11u? I made the request. Ops asked me to confirm what I wanted. I have done so. No, the change isn't done yet. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue Apr 30 14:57:59 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 30 Apr 2019 14:57:59 +0000 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: <0aaa1010-6287-fc64-9316-2a1625d038a7@redhat.com> References: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> <0aaa1010-6287-fc64-9316-2a1625d038a7@redhat.com> Message-ID: > > Hm, what exactly do you mean? You have confirmation from ops that the > change should be done from their end? We can proceed merging stuff into > jdk8u and jdk11u? > > I made the request. Ops asked me to confirm what I wanted. I have > done so. No, the change isn't done yet. Understood. Thanks ?? From shade at redhat.com Tue Apr 30 16:32:04 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Apr 2019 18:32:04 +0200 Subject: [11u] RDR: backport JDK-8211300 and JDK-8212678 In-Reply-To: References: <4a2e3503bb41c292eb4c6d9587735157@linux.vnet.ibm.com> <31798457-f327-ce17-5a65-635307eb83ca@redhat.com> Message-ID: On 4/30/19 3:18 PM, Ichiroh Takiguchi wrote: > Do I have to wait for approval for JDK-8211300 ? 339 files changed, 1645 insertions(+), 1645 deletions(-) [+] I would not count on it :) I am surprised there is no jdk11u-fix-no on that patch! > Or, should I rewrite JDK-8212678's fix ? Yes, why would you need the JDK-8211300 cleanup for this to apply? I just tried to apply this to jdk-updates/jdk11u-dev, and it has a single reject here: --- WInputMethod.java +++ WInputMethod.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it It does not make sense to pull in 3 KLOC cleanup change just to avoid this conflict. -Aleksey From rajan.halade at oracle.com Tue Apr 30 18:08:25 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 30 Apr 2019 11:08:25 -0700 Subject: RFR [backport to jdk and 11u]: 8216577: Add GlobalSign's R6 Root certificate In-Reply-To: References: Message-ID: <1ed9610c-8a81-9c5d-f261-2056f617003b@oracle.com> Thanks Christoph for this. I have pushed fix to jdk/jdk repository. - Rajan On 4/29/19 12:31 AM, Langer, Christoph wrote: > > Hi, > > the change to add GlobalSign's R6 Root certificate has only been > pushed to jdk12 updates (12.0.1) so far. According to [0], it was an > oversight to not have it added to jdk/jdk. I also want to bring it to 11u. > > Taking the change to both, jdk/jdk and jdk-updates/jdk11u-dev does not > apply cleanly. test/jdk/sun/security/lib/cacerts/VerifyCACerts.java > fails to resolve because of changed license header and different bug > ids in the @bug tag. So, please review the resolved change. It's the > same for both repos. > > Webrev jdk/jdk: > http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk/ > > > Webrev jdk11u-dev: > http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk11u-dev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216577 > > > Please review. > > @Rajan Halade : please let me know > whether I shall push it to jdk/jdk or feel free to do it yourself. > > Thanks & Best regards > > Christoph > > [0] > https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019766.html > >