From gnu.andrew at redhat.com Wed May 1 06:50:05 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 1 May 2019 07:50:05 +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 30/04/2019 13:40, Lindenmaier, Goetz wrote: > 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. Many of us were very busy with the last release. > 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. Indeed. This seems like a reason to do it in jdk11u-dev. > >>> 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? What do you mean by "doing fixes"? Work should go on in jdk11u-dev, not jdk11. > >>> 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. That's not my aim. > We should try to build a process that is easy to communicate We should. I'm sorry, but I don't find yours to be so. 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. No, it isn't. I'm not sure who the 'we' is here, but maybe this is the confusion here. The message is work is always done in the development tree, jdk11u-dev. Work in the jdk11u-dev tree is always work on the development stage of a release. Explicitly moving the focus for release x from the development tree to the master tree at rampdown is designed to shift development focus to the next release, x+1. If an issue is found in working on x+1, or in testing x, that is a showstopper for release x, then that may be flagged as jdk8u-critical-request to get it into the upcoming release. But otherwise, the intent here is for people to start aiming their work at the next release at rampdown. Patches being pushed to jdk11u should be rare. > 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. Because jdk11u and jdk11u-dev are aimed at different audiences. The master tree (jdk11u) is snapshots for people to test and integrate downstream, leading up to the final release. The development tree (jdk11u-dev) is for developers to work on the release. I don't see how that's any different to your scenario which, I believe, also updates both. I don't expect developers working on jdk8u development to have to care much about the master tree, unless they is a critical issue with the upcoming release. I don't expect consumers to care about the development tree at all; they should consume solely from jdk11. As I said before, merging to jdk11u earlier is intended to provide for earlier testing of a smaller number of changes. It's an attempt to meet your call for earlier testing without locking everything down before many people have even had time to work on the release. > >> 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. Which is why I suggest starting such builds over the next week or so. My plan for 8u is to integrate the build downstream and do our usual builds and testing as much as possible for each tag. > -- 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 GROEGES at uk.ibm.com Wed May 1 07:04:59 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 1 May 2019 08:04:59 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Message-ID: Hi all, The following issue [1] has been raised and the associated webrev [2] has been approved and the code merged into jdk/jdk [3] I am now requesting this fix to be back-ported to jdk8u, jdk11u and jdk12u. The patch imports and works correctly on jdk8u and jdk12u but not quite on jdk8u due to difference in the test framework. I have created a separate webrev for the jdk8u changes [4]. I am therefore requesting someone to review these changes and to sponsor these updates to jdk8u, jdk11u and jdk12u. [1] https://bugs.openjdk.java.net/browse/JDK-8218152 [2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.04/ [3] http://hg.openjdk.java.net/jdk/jdk/rev/d9208a660094 [4] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.04/ 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 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 Wed May 1 13:09:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 1 May 2019 13:09:53 +0000 Subject: RFR [backport to jdk and 11u]: 8216577: Add GlobalSign's R6 Root certificate In-Reply-To: <1ed9610c-8a81-9c5d-f261-2056f617003b@oracle.com> References: <1ed9610c-8a81-9c5d-f261-2056f617003b@oracle.com> Message-ID: Thank you, Rajan. From: Rajan Halade Sent: Dienstag, 30. April 2019 20:08 To: Langer, Christoph Cc: security-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; Sean Mullan Subject: Re: RFR [backport to jdk and 11u]: 8216577: Add GlobalSign's R6 Root certificate 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 From takiguc at linux.vnet.ibm.com Wed May 1 13:26:38 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 01 May 2019 22:26:38 +0900 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: Hello Aleksey. I'd like to request jdk11u-fix-no against JDK-8211300. I created new fix against JDK-8212678. Change: https://cr.openjdk.java.net/~itakiguchi/8212678/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212678 Could you review the fix ? I used changeset 33b96cbd16f3, I just changed Copyright year. Could you push it ? Please let me know if I need to do something more. Thanks, Ichiroh Takiguchi On 2019-05-01 01:32, Aleksey Shipilev wrote: > 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 goetz.lindenmaier at sap.com Wed May 1 13:33:55 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 1 May 2019 13:33:55 +0000 Subject: Tagged 11.0.4+1 in jdk11u-dev. Sharing test failures. Message-ID: Hi, I tagged jdk11.0.4+1 in jdk11u-dev. below I list the jtreg tests we see failing as of jdk11.0.4+1. This includes all tests I see failing, without ruling out setup issues and the like. These tests were not failing in our 11.0.3 builds, nor in 12 or 13 except if explicitly stated. The fact they are failing on a certain platform does not mean the bug is platform dependent. Sometimes it's just the dependency to the OS variant. We test on a wide variety of different machines, OSes etc. In the next days I will have a closer look at the failures and open JBS issues if adequate. If someone jumps in and adresses one of these issues he is more than welcome. If so, I'm happy to share more details about the failures. Best regards, Goetz. all java/util/Calendar/NarrowNamesTest.sh java.lang.RuntimeException: test failed at NarrowNamesTest.main(NarrowNamesTest.java:134) I see this on various VMs today, also 11.0.3 and 8. But not consistently over all builds. For 11.0.4 only solaris sparc failed. Some kind of Japanese Era problem? all ppc platforms vmTestbase/vm/mlvm/meth/stress/gc/createLotsOfMHConsts/Test.java sporadic timeouts ### TRACE 1: RNG seed = -7264363496160763377 (0x9b2fcbe37405e20f) Timeout refired 720 times aix ppc64 java/nio/file/Files/DeleteOnClose.java JavaTest Message: Test threw exception: java.lang.RuntimeException: IOException expected java/nio/file/Files/SBC.java java.lang.RuntimeException at SBC.noFollowLinksTests(SBC.java:238) linux ppc64le runtime/ErrorHandling/ErrorHandler.java Gustavo java/awt/FontMetrics/MaxAdvanceIsMax.java FAILED: getMaxAdvance is not max for font: java.awt.Font linux s390x java/lang/management/MemoryMXBean/LowMemoryTest2.sh Exception in thread "Thread-0" java.lang.OutOfMemoryError: Compressed class space linux x86_64 and mac security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status Maybe an infrastructure problem. mac x86_64 java/net/MulticastSocket/Promiscuous.java java.lang.RuntimeException: Expected message not received, Receive timed out java/net/MulticastSocket/SetOutgoingIf.java java.net.SocketTimeoutException: Receive timed out solaris sparc Tier 1!! compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Not enough space in non-nmethod code heap to run VM: 20480K < 21475K windows x86_64 vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch002/TestDescription.java vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch004/TestDescription.java vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch010/TestDescription.java Error: Could not find or load main class nsk.jvmti.AddToBootstrapClassLoaderSearch.bootclssearch002 Caused by: java.lang.NoClassDefFoundError: nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch002p java/net/httpclient/SmokeTest.java timeout > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Tuesday, April 30, 2019 2:48 PM > To: Andrew John Hughes ; 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 > > 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 shade at redhat.com Wed May 1 13:49:15 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 May 2019 15:49:15 +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: <6ba2d15c-d7f0-69e8-1c2c-d35301e475db@redhat.com> On 5/1/19 3:26 PM, Ichiroh Takiguchi wrote: > I created new fix against JDK-8212678. > > Change: https://cr.openjdk.java.net/~itakiguchi/8212678/webrev.02/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212678 > > Could you review the fix ? > I used changeset 33b96cbd16f3, > I just changed Copyright year. Looks good. This is similar to what I have after resolving the conflict in copyright year. > Could you push it ? Yes, I would sponsor. jdk11u-fix-yes is set there, so we are clear to push. -Aleksey From shade at redhat.com Wed May 1 14:54:04 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 May 2019 16:54:04 +0200 Subject: [11u] RDR: backport JDK-8211300 and JDK-8212678 In-Reply-To: <6ba2d15c-d7f0-69e8-1c2c-d35301e475db@redhat.com> References: <4a2e3503bb41c292eb4c6d9587735157@linux.vnet.ibm.com> <31798457-f327-ce17-5a65-635307eb83ca@redhat.com> <6ba2d15c-d7f0-69e8-1c2c-d35301e475db@redhat.com> Message-ID: <8c05a0ce-5566-49c5-11fb-bdad9b410ee8@redhat.com> On 5/1/19 3:49 PM, Aleksey Shipilev wrote: > On 5/1/19 3:26 PM, Ichiroh Takiguchi wrote: >> I created new fix against JDK-8212678. >> >> Change: https://cr.openjdk.java.net/~itakiguchi/8212678/webrev.02/ >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212678 >> >> Could you review the fix ? >> I used changeset 33b96cbd16f3, >> I just changed Copyright year. > > Looks good. This is similar to what I have after resolving the conflict in copyright year. > >> Could you push it ? > > Yes, I would sponsor. jdk11u-fix-yes is set there, so we are clear to push. Here: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/7bb488236ac9 -Aleksey From gnu.andrew at redhat.com Wed May 1 15:58:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 1 May 2019 16:58:14 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: [CCing jdk8u-dev for 8u review] On 01/05/2019 08:04, Steve Groeger wrote: > Hi all, > > The following issue [1] has been raised and the associated webrev [2] has > been approved and the code merged into jdk/jdk [3] > I am now requesting this fix to be back-ported to jdk8u, jdk11u and > jdk12u. > The patch imports and works correctly on jdk8u and jdk12u but not quite on > jdk8u due to difference in the test framework. > I have created a separate webrev for the jdk8u changes [4]. > I am therefore requesting someone to review these changes and to sponsor > these updates to jdk8u, jdk11u and jdk12u. > > [1] https://bugs.openjdk.java.net/browse/JDK-8218152 > [2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.04/ > [3] http://hg.openjdk.java.net/jdk/jdk/rev/d9208a660094 > [4] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.04/ > > 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 > 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 > Regarding the 8u webrev, the two additions for hasNext() and next() in JavacProcessingEnvironment.java seem to have been flipped. Was this intentional? Comparing patched jdk8u with the jdk/jdk version: --- src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 16:50:40.409545256 +0100 +++ ../../jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 03:00 public boolean hasNext() { try { - return iterator.hasNext(); + return internalHasNext(); } catch(ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); + } catch (UnsupportedClassVersionError ucve) { + log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); + throw new Abort(ucve); + } catch (ClassFormatError cfe) { + log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); + throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } ... public Processor next() { try { - return iterator.next(); + return internalNext(); } catch (ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); - } catch (UnsupportedClassVersionError ucve) { - log.error("proc.cant.load.class", ucve.getLocalizedMessage()); - throw new Abort(ucve); - } catch (ClassFormatError cfe) { - log.error("proc.cant.load.class", cfe.getLocalizedMessage()); - throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } The test changes look ok and I assume they pass. Long term, we may want to look at backporting https://bugs.openjdk.java.net/browse/JDK-8050429 to avoid this work for every test. 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 GROEGES at uk.ibm.com Thu May 2 08:41:57 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 2 May 2019 09:41:57 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: Hi Andrew, Thanks for taking a look at this. > Regarding the 8u webrev, the two additions for hasNext() and next() in > JavacProcessingEnvironment.java seem to have been flipped. Was this > intentional? Comparing patched jdk8u with the jdk/jdk version: Yes, this was intentional. When I investigated this issue I did initially add the changes to hasNext() in the jdk8u code but that didn't resolve the issue. Having then looked at a generated stack trace it showed that the code was going thru the next() method and failing there rather than in hasNext(). Hence the reason the changes were put in the next() method for jdk8u and in the hasNext() for jdk11 and above. Seems the JavacProcessingEnvoronment.java class has changed since jdk8. > The test changes look ok and I assume they pass. Yes, the tests do pass when run on my local environment for all releases jdk8u, jdk11u and jdk12u. > Long term, we may want to look at backporting > https://bugs.openjdk.java.net/browse/JDK-8050429 > to avoid this work for every test. I agree that we need to back-port this at some point. It gets quite time consuming having to change tests that are created on jdk11u+ and need to be back-ported to jdk8u. Is there anything else I need to do in order to get these back-ports merged. If so, please let me know. 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: Andrew John Hughes To: jdk-updates-dev at openjdk.java.net, "'jdk8u-dev at openjdk.java.net'" Date: 01/05/2019 17:00 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Sent by: "jdk-updates-dev" [CCing jdk8u-dev for 8u review] On 01/05/2019 08:04, Steve Groeger wrote: > Hi all, > > The following issue [1] has been raised and the associated webrev [2] has > been approved and the code merged into jdk/jdk [3] > I am now requesting this fix to be back-ported to jdk8u, jdk11u and > jdk12u. > The patch imports and works correctly on jdk8u and jdk12u but not quite on > jdk8u due to difference in the test framework. > I have created a separate webrev for the jdk8u changes [4]. > I am therefore requesting someone to review these changes and to sponsor > these updates to jdk8u, jdk11u and jdk12u. > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=qupvoIE2b9o6H2gvzu3EdQUSjE0HvDBZeDXycoIlg4w&e= > [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.04_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=Lx2f4bK7_yW6MWLgQYj-Y8GzL5NbAH95L7X_ptB9SBk&e= > [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_d9208a660094&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=4I9emNaREfISeASbo-TDQVJ3x6_pTiKFtlFPK8K2hTk&e= > [4] https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.04_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=ByHXRWAiDbkm9dsfgHchCQR4FMQiZc_ge0LYlRQkYD8&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 > 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 > Regarding the 8u webrev, the two additions for hasNext() and next() in JavacProcessingEnvironment.java seem to have been flipped. Was this intentional? Comparing patched jdk8u with the jdk/jdk version: --- src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 16:50:40.409545256 +0100 +++ ../../jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 03:00 public boolean hasNext() { try { - return iterator.hasNext(); + return internalHasNext(); } catch(ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); + } catch (UnsupportedClassVersionError ucve) { + log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); + throw new Abort(ucve); + } catch (ClassFormatError cfe) { + log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); + throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } ... public Processor next() { try { - return iterator.next(); + return internalNext(); } catch (ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); - } catch (UnsupportedClassVersionError ucve) { - log.error("proc.cant.load.class", ucve.getLocalizedMessage()); - throw new Abort(ucve); - } catch (ClassFormatError cfe) { - log.error("proc.cant.load.class", cfe.getLocalizedMessage()); - throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } The test changes look ok and I assume they pass. Long term, we may want to look at backporting https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8050429&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=q-BAu0YUQlwQmBEoesgfjRpVLy_wpTd8b1UZ7CZ_Akk&e= to avoid this work for every test. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. ( https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redhat.com&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=IXk7fITakTIJN8xZ0a-S80B5oFOvfv5yzV1wdICi7hA&e= ) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://urldefense.proofpoint.com/v2/url?u=https-3A__keybase.io_gnu-5Fandrew&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=iHeIglNN6XbY2FUKnkzs8A3gd7i9W_jO428tjpYD-Q0&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 jkang at redhat.com Thu May 2 17:27:53 2019 From: jkang at redhat.com (Jie Kang) Date: Thu, 2 May 2019 13:27:53 -0400 Subject: [11u] Questions re. CSR && Backport of JDK-8205516: JFR tool Message-ID: Hi all, I am interested in doing the backport work for JDK-8205516: JFR tool [1] to openjdk 11u. A CSR was filed for the original bug so I believe I will need to file a CSR for the backport bug [2] as well. However, I am not an author or a committer; is this something someone can do in my stead? Also: why should the JFR tool be backported to 11? JFR is now in openjdk 11+. In order to extract information from flight recordings, one would need to write a parser, maybe using existing java libraries like jmc-core, download a separate tool (if any exist), or use JMC, a full fledged GUI application. A CLI tool that is part of the JDK is a very good alternative and I think it makes sense for the JFR tool to be available in JDKs that support flight recordings, including 11. Regards, [1] https://bugs.openjdk.java.net/browse/JDK-8205516 [2] https://bugs.openjdk.java.net/browse/JDK-8222896 From neugens.limasoftware at gmail.com Thu May 2 17:52:35 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 2 May 2019 19:52:35 +0200 Subject: [11u] Questions re. CSR && Backport of JDK-8205516: JFR tool In-Reply-To: References: Message-ID: Since we?re backporting JFR to 8, perhaps makes sense to do that for 8 as well ;) I can help you with the bug and the CSR request, I?ll give a look at it and let you know. Cheers, Mario On Thu 2. May 2019 at 19:28, Jie Kang wrote: > Hi all, > > I am interested in doing the backport work for JDK-8205516: JFR tool > [1] to openjdk 11u. A CSR was filed for the original bug so I believe > I will need to file a CSR for the backport bug [2] as well. However, I > am not an author or a committer; is this something someone can do in > my stead? > > Also: why should the JFR tool be backported to 11? > > JFR is now in openjdk 11+. In order to extract information from flight > recordings, one would need to write a parser, maybe using existing > java libraries like jmc-core, download a separate tool (if any exist), > or use JMC, a full fledged GUI application. A CLI tool that is part of > the JDK is a very good alternative and I think it makes sense for the > JFR tool to be available in JDKs that support flight recordings, > including 11. > > > Regards, > > [1] https://bugs.openjdk.java.net/browse/JDK-8205516 > [2] https://bugs.openjdk.java.net/browse/JDK-8222896 > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From christoph.langer at sap.com Thu May 2 20:43:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 2 May 2019 20:43:10 +0000 Subject: [11u] Questions re. CSR && Backport of JDK-8205516: JFR tool In-Reply-To: References: Message-ID: Hi Jie, Mario, we already ran through backporting an issue with an attached CSR, so I can give you some advice: Generally, you should create a backport JBS item for the issue with target 11-pool. From that one, you'll have to create a CSR, also with version set to 11-pool. In that CSR you can largely paste the original CSR data (as it applies). For your case, I see that there already exists an 11-pool backport item, assigned to Fairoz Matte: https://bugs.openjdk.java.net/browse/JDK-8222896. Maybe you and the colleagues from Oracle could cooperate on this item, at least for JDK11...? Hence, cc-ing hotspot-jfr-dev and Erik and Fairoz. Best regards, Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Mario Torre > Sent: Donnerstag, 2. Mai 2019 19:53 > To: Jie Kang > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] Questions re. CSR && Backport of JDK-8205516: JFR tool > > Since we?re backporting JFR to 8, perhaps makes sense to do that for 8 as > well ;) > > I can help you with the bug and the CSR request, I?ll give a look at it and > let you know. > > Cheers, > Mario > > On Thu 2. May 2019 at 19:28, Jie Kang wrote: > > > Hi all, > > > > I am interested in doing the backport work for JDK-8205516: JFR tool > > [1] to openjdk 11u. A CSR was filed for the original bug so I believe > > I will need to file a CSR for the backport bug [2] as well. However, I > > am not an author or a committer; is this something someone can do in > > my stead? > > > > Also: why should the JFR tool be backported to 11? > > > > JFR is now in openjdk 11+. In order to extract information from flight > > recordings, one would need to write a parser, maybe using existing > > java libraries like jmc-core, download a separate tool (if any exist), > > or use JMC, a full fledged GUI application. A CLI tool that is part of > > the JDK is a very good alternative and I think it makes sense for the > > JFR tool to be available in JDKs that support flight recordings, > > including 11. > > > > > > Regards, > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8205516 > > [2] https://bugs.openjdk.java.net/browse/JDK-8222896 > > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From gromero at linux.vnet.ibm.com Thu May 2 22:40:42 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 2 May 2019 19:40:42 -0300 Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization Message-ID: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> Hi, Could the following small change be reviewed please? Bug : https://bugs.openjdk.java.net/browse/JDK-8223266 Webrev: http://cr.openjdk.java.net/~gromero/8223266/v1/ It fixes the JVM signal handler on Linux / PPC64 to catch properly a SIGSEGV due to a branch to an invalid address (not mapped/not executable) on 11u. A similar fix [0] was already downported to 11u but it's not sufficient to cover that case because UseMemBar feature is not obsoleted on 11u and additional code exists for checking memory serialization in the signal handler, hence before calling is_memory_serialization() it's necessary to check if the SIGSEGV is not caused due to a branch to an invalid address and then only (in case SIGSEGV is not caused due to a branch to an invalid address) call is_memory_serialization(). Thank you. Best regards, Gustavo [0] https://bugs.openjdk.java.net/browse/JDK-8221834 From neugens at redhat.com Fri May 3 08:26:18 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 3 May 2019 10:26:18 +0200 Subject: [11u] Questions re. CSR && Backport of JDK-8205516: JFR tool In-Reply-To: References: Message-ID: Hi Christoph, Thanks for the input! Erik, Fairoz, could you please share with us the progress on this? Cheers, Mario On Thu, May 2, 2019 at 10:43 PM Langer, Christoph wrote: > > Hi Jie, Mario, > > we already ran through backporting an issue with an attached CSR, so I can give you some advice: > > Generally, you should create a backport JBS item for the issue with target 11-pool. From that one, you'll have to create a CSR, also with version set to 11-pool. In that CSR you can largely paste the original CSR data (as it applies). > > For your case, I see that there already exists an 11-pool backport item, assigned to Fairoz Matte: https://bugs.openjdk.java.net/browse/JDK-8222896. > > Maybe you and the colleagues from Oracle could cooperate on this item, at least for JDK11...? Hence, cc-ing hotspot-jfr-dev and Erik and Fairoz. > > Best regards, > Christoph > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Mario Torre > > Sent: Donnerstag, 2. Mai 2019 19:53 > > To: Jie Kang > > Cc: jdk-updates-dev at openjdk.java.net > > Subject: Re: [11u] Questions re. CSR && Backport of JDK-8205516: JFR tool > > > > Since we?re backporting JFR to 8, perhaps makes sense to do that for 8 as > > well ;) > > > > I can help you with the bug and the CSR request, I?ll give a look at it and > > let you know. > > > > Cheers, > > Mario > > > > On Thu 2. May 2019 at 19:28, Jie Kang wrote: > > > > > Hi all, > > > > > > I am interested in doing the backport work for JDK-8205516: JFR tool > > > [1] to openjdk 11u. A CSR was filed for the original bug so I believe > > > I will need to file a CSR for the backport bug [2] as well. However, I > > > am not an author or a committer; is this something someone can do in > > > my stead? > > > > > > Also: why should the JFR tool be backported to 11? > > > > > > JFR is now in openjdk 11+. In order to extract information from flight > > > recordings, one would need to write a parser, maybe using existing > > > java libraries like jmc-core, download a separate tool (if any exist), > > > or use JMC, a full fledged GUI application. A CLI tool that is part of > > > the JDK is a very good alternative and I think it makes sense for the > > > JFR tool to be available in JDKs that support flight recordings, > > > including 11. > > > > > > > > > Regards, > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8205516 > > > [2] https://bugs.openjdk.java.net/browse/JDK-8222896 > > > > > -- > > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > > Proud GNU Classpath developer: http://www.classpath.org/ > > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > > > Please, support open standards: > > http://endsoftpatents.org/ -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From goetz.lindenmaier at sap.com Fri May 3 09:30:28 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 3 May 2019 09:30:28 +0000 Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization In-Reply-To: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> References: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> Message-ID: Hi Gustavo, thanks for fixing this issue this quickly. I put the patch into our testing. You please need to flag the bug as jdk11u-fix-request and add the correspornding 'Fix Request' comment referring to this review thread. Looking at the issue: actually the current VM would think the signal is a memory serialization and return true, while it is a real crash? (Or a simulated one as in the test?) Best regards, Goetz. > -----Original Message----- > From: Gustavo Romero > Sent: Freitag, 3. Mai 2019 00:41 > To: jdk-updates-dev at openjdk.java.net; Lindenmaier, Goetz > > Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address > before checking for mem serialization > Importance: High > > Hi, > > Could the following small change be reviewed please? > > Bug : https://bugs.openjdk.java.net/browse/JDK-8223266 > Webrev: http://cr.openjdk.java.net/~gromero/8223266/v1/ > > It fixes the JVM signal handler on Linux / PPC64 to > catch properly a SIGSEGV due to a branch to an invalid address (not > mapped/not > executable) on 11u. > > A similar fix [0] was already downported to 11u but it's not sufficient to cover > that case because UseMemBar feature is not obsoleted on 11u and additional > code > exists for checking memory serialization in the signal handler, hence before > calling is_memory_serialization() it's necessary to check if the SIGSEGV is not > caused due to a branch to an invalid address and then only (in case SIGSEGV is > not caused due to a branch to an invalid address) call > is_memory_serialization(). > > Thank you. > > Best regards, > Gustavo > > [0] https://bugs.openjdk.java.net/browse/JDK-8221834 From shade at redhat.com Fri May 3 10:17:51 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 May 2019 12:17:51 +0200 Subject: Extraneous tags for JDK-8222137 backports Message-ID: <6b9ad8ef-1aa7-ec54-f006-1f81c2bce441@redhat.com> Hi Sean, I think you put jdk11u-fix-request by mistake to the "*-pool" backports for this issue: https://bugs.openjdk.java.net/browse/JDK-8222137 You only need to put it on the parent issue. These are the backport issues that have the jdk11u-fix-request today, please consider fixing the tags: https://bugs.openjdk.java.net/browse/JDK-8223200 https://bugs.openjdk.java.net/browse/JDK-8223201 https://bugs.openjdk.java.net/browse/JDK-8223202 https://bugs.openjdk.java.net/browse/JDK-8223203 (I separately wonder if "CPU19_07-critical-watch" should also be on parent issue only) -- Thanks, -Aleksey From sean.coffey at oracle.com Fri May 3 10:26:20 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 3 May 2019 11:26:20 +0100 Subject: Extraneous tags for JDK-8222137 backports In-Reply-To: <6b9ad8ef-1aa7-ec54-f006-1f81c2bce441@redhat.com> References: <6b9ad8ef-1aa7-ec54-f006-1f81c2bce441@redhat.com> Message-ID: <53627404-66e9-ade1-9580-c54b49474a04@oracle.com> Aleksey, Christoph added the jdk11u-fix-request label to the master bug report. That gets copied to the sibling records when backports are created. (side effect of JBS which I'd like to see changed) I only added the jdk12u-fix-request label and that's only on the master bug report. I'll fix up the backport records now. Regards, Sean. On 03/05/19 11:17, Aleksey Shipilev wrote: > Hi Sean, > > I think you put jdk11u-fix-request by mistake to the "*-pool" backports for this issue: > https://bugs.openjdk.java.net/browse/JDK-8222137 > > You only need to put it on the parent issue. These are the backport issues that have the > jdk11u-fix-request today, please consider fixing the tags: > https://bugs.openjdk.java.net/browse/JDK-8223200 > https://bugs.openjdk.java.net/browse/JDK-8223201 > https://bugs.openjdk.java.net/browse/JDK-8223202 > https://bugs.openjdk.java.net/browse/JDK-8223203 > > (I separately wonder if "CPU19_07-critical-watch" should also be on parent issue only) > From shade at redhat.com Fri May 3 10:27:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 May 2019 12:27:38 +0200 Subject: Extraneous tags for JDK-8222137 backports In-Reply-To: <53627404-66e9-ade1-9580-c54b49474a04@oracle.com> References: <6b9ad8ef-1aa7-ec54-f006-1f81c2bce441@redhat.com> <53627404-66e9-ade1-9580-c54b49474a04@oracle.com> Message-ID: <23e35018-4469-0fbd-5e12-8098e490fe23@redhat.com> On 5/3/19 12:26 PM, Se?n Coffey wrote: > Christoph added the jdk11u-fix-request label to the master bug report. That gets copied to the > sibling records when backports are created. (side effect of JBS which I'd like to see changed) > > I only added the jdk12u-fix-request label and that's only on the master bug report. I'll fix up the > backport records now. Ah, that explains it. Yes, please remove the extra tags from backports issues. Cheers, -Aleksey From sgehwolf at redhat.com Fri May 3 12:56:16 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 03 May 2019 14:56:16 +0200 Subject: [11u] RFR: 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode Message-ID: Hi, Could I please get reviews for this JDK 11 backport? The JDK 12 change does not apply cleanly unfortunately. One hunk in ProblemList.txt didn't apply because of changed context lines. That's the only difference. Bug: https://bugs.openjdk.java.net/browse/JDK-8204308 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8204308/01/webrev/ Testing: New regression test, tier1 tests on Linux x86_64 Thanks, Severin From martin.doerr at sap.com Fri May 3 13:06:21 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 3 May 2019 13:06:21 +0000 Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization In-Reply-To: References: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> Message-ID: Hi Gustavo, thanks for addressing this issue. The fix looks good to me. I'd appreciate if you could use a term in the comment like quoted "Data Storage Interrupt" such that somebody reading the code has a change to find a description of these bits. Also, please update copyrights before pushing. I don't need for a new webrev for that. I think it can get pushed once G?tz' testing has completed. Best regards, Martin -----Original Message----- From: jdk-updates-dev On Behalf Of Lindenmaier, Goetz Sent: Freitag, 3. Mai 2019 11:30 To: Gustavo Romero ; jdk-updates-dev at openjdk.java.net Subject: [CAUTION] RE: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization Hi Gustavo, thanks for fixing this issue this quickly. I put the patch into our testing. You please need to flag the bug as jdk11u-fix-request and add the correspornding 'Fix Request' comment referring to this review thread. Looking at the issue: actually the current VM would think the signal is a memory serialization and return true, while it is a real crash? (Or a simulated one as in the test?) Best regards, Goetz. > -----Original Message----- > From: Gustavo Romero > Sent: Freitag, 3. Mai 2019 00:41 > To: jdk-updates-dev at openjdk.java.net; Lindenmaier, Goetz > > Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address > before checking for mem serialization > Importance: High > > Hi, > > Could the following small change be reviewed please? > > Bug : https://bugs.openjdk.java.net/browse/JDK-8223266 > Webrev: http://cr.openjdk.java.net/~gromero/8223266/v1/ > > It fixes the JVM signal handler on Linux / PPC64 to > catch properly a SIGSEGV due to a branch to an invalid address (not > mapped/not > executable) on 11u. > > A similar fix [0] was already downported to 11u but it's not sufficient to cover > that case because UseMemBar feature is not obsoleted on 11u and additional > code > exists for checking memory serialization in the signal handler, hence before > calling is_memory_serialization() it's necessary to check if the SIGSEGV is not > caused due to a branch to an invalid address and then only (in case SIGSEGV is > not caused due to a branch to an invalid address) call > is_memory_serialization(). > > Thank you. > > Best regards, > Gustavo > > [0] https://bugs.openjdk.java.net/browse/JDK-8221834 From goetz.lindenmaier at sap.com Fri May 3 13:15:43 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 3 May 2019 13:15:43 +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, > > 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. > Indeed. This seems like a reason to do it in jdk11u-dev. Please distinguish one-time contraints from general process setup. > What do you mean by "doing fixes"? Work should go on in jdk11u-dev, not > jdk11. Who keeps us from pushing to jdk11u? We could do so. > Explicitly moving the focus for release x from the development tree to > the master tree at rampdown is designed to shift development focus to > the next release, x+1. Yes. > If an issue is found in working on x+1, or in testing x, that is a > showstopper for release x, then that may be flagged as > jdk8u-critical-request to get it into the upcoming release. I think the name 'critical' is bad, it is misleading. The second tag is needed because we have two codelines, and want to distinguish for which the downport request is made. > But otherwise, the intent here is for people to start aiming their work > at the next release at rampdown. Patches being pushed to jdk11u should > be rare. I think we should use jdk11u only for rampdown. So patches pushed to jdk11u should be limited and well restricted, but not necessarily rare. But yes, definitely less than pushed to jdk11u-dev. > > 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. > Because jdk11u and jdk11u-dev are aimed at different audiences. If they are interested in a decent stable version, they should only get the repo at rampdown. I think it's rather because people have certain processes set up, and jdk11u-dev is new. That again is a bad trigger for basic process decisions. > The master tree (jdk11u) is snapshots for people to test and integrate > downstream, leading up to the final release. No. The jdk11u is a repository used for rampdown so that development can be continued in another repository, here jdk11u-dev. It is not a convenience for testers, it is to allow parallel work with two different intentions: development <--> stabilization. > The development tree (jdk11u-dev) is for developers to work on the release. > > I don't see how that's any different to your scenario which, I believe, > also updates both. Yes it updates both because others want it that way, but I tried to assure at least some stabilization before tagging. > I don't expect developers working on jdk8u development to have to care > much about the master tree, unless they is a critical issue with the > upcoming release. I don't expect consumers to care about the development > tree at all; they should consume solely from jdk11. Yes, the audience pushing to jdk11u should be smaller than that pushing to jdk11u-dev. > As I said before, merging to jdk11u earlier is intended to provide for > earlier testing of a smaller number of changes. It's an attempt to meet > your call for earlier testing without locking everything down before > many people have even had time to work on the release. People should test jdk11u-dev if they want to test more early. Then they know they are testing an arbitrary development state and nothing in consolidation. > Which is why I suggest starting such builds over the next week or so. > > My plan for 8u is to integrate the build downstream and do our usual > builds and testing as much as possible for each tag. By the way, what is your "downstream"? Is it a repo that differs from OpenJDK (kind of as our SapMachine)? Or is it just a repo that feeds your build/test infrastructure? Best regards, Goetz. > > > > > -- > 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 gromero at linux.vnet.ibm.com Fri May 3 13:58:23 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 3 May 2019 10:58:23 -0300 Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization In-Reply-To: References: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> Message-ID: <35c86770-bba3-8af2-aac3-69fdf4660270@linux.vnet.ibm.com> On 05/03/2019 06:30 AM, Lindenmaier, Goetz wrote: > thanks for fixing this issue this quickly. > I put the patch into our testing. Thanks a lot for reporting and testing it, Goetz. > You please need to flag the bug as jdk11u-fix-request and > add the correspornding 'Fix Request' comment referring to > this review thread. oh, sure. I'll do. > Looking at the issue: > actually the current VM would think the signal is a > memory serialization and return true, while it is > a real crash? (Or a simulated one as in the test?) is_memory_serialization() never returns, so the VM never knows if it's indeed a memory serialization case or not. Because the issue on some old kernels forbids us to rely on 'si_addr' we are inspecting the instruction at 'pc' to extract the registers used in the instruction to determine the actual faulty address before calling os::is_memory_serialize_page(), similarly to what we do to dertermine the faulty address in get_stack_bang_address(). In doing it's assumed that SIGSEGV can only be caused due to a load/store (Data Storage Interrupt), because it assumes it's always possible to read the instruction at 'pc'. This is not true, particularly for a SIGSEGV due to a branch to an invalid address (e.g. not mapped / no permission to read/exec address), which is generated due to Instruction Storage Interrupt (ISI). Hence we can use the interruption type (passed in 'trap' member to the signal handler) to discern when it's possible to inspect the 'pc' (DSI) and when it's not possible (ISI). The test case 13 precisely stresses that case of branching to an invalid address by forcing a function bad pointer = 0xf and calling it (on PPC64 that crash shows pc=0xc in the hs_err log due to the code alignment requirements for execution). So the additional code block checking for SIGSEGV related to UseMemBar feature on 11u needs to be adapted like the previous block using get_stack_bang_address(), which is already fixed on jdk/jdk tip. Kind regards, Gustavo From shade at redhat.com Fri May 3 14:21:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 May 2019 16:21:38 +0200 Subject: [11u] RFR: 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode In-Reply-To: References: Message-ID: <42b6e702-497c-3e2f-8539-ca7b31f2b13a@redhat.com> On 5/3/19 2:56 PM, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this JDK 11 backport? The JDK 12 change > does not apply cleanly unfortunately. One hunk in ProblemList.txt > didn't apply because of changed context lines. That's the only > difference. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204308 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8204308/01/webrev/ The backport looks fine. -Aleksey From jianglizhou at google.com Fri May 3 14:45:47 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 3 May 2019 07:45:47 -0700 Subject: [11u] RFR: 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode In-Reply-To: <42b6e702-497c-3e2f-8539-ca7b31f2b13a@redhat.com> References: <42b6e702-497c-3e2f-8539-ca7b31f2b13a@redhat.com> Message-ID: +1 Best, Jiangli *From: *Aleksey Shipilev *Date: *Fri, May 3, 2019, 7:22 AM *To: *Severin Gehwolf, jdk-updates-dev at openjdk.java.net *Cc: *serviceability-dev On 5/3/19 2:56 PM, Severin Gehwolf wrote: > > Hi, > > > > Could I please get reviews for this JDK 11 backport? The JDK 12 change > > does not apply cleanly unfortunately. One hunk in ProblemList.txt > > didn't apply because of changed context lines. That's the only > > difference. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204308 > > webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8204308/01/webrev/ > > The backport looks fine. > > -Aleksey > > From gromero at linux.vnet.ibm.com Fri May 3 16:08:52 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 3 May 2019 13:08:52 -0300 Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization In-Reply-To: References: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> Message-ID: <76c1afff-de58-9a23-a33c-fec6b8ae9df2@linux.vnet.ibm.com> Hi Martin, On 05/03/2019 10:06 AM, Doerr, Martin wrote: > thanks for addressing this issue. > > The fix looks good to me. Thanks a lot for reviewing it. > I'd appreciate if you could use a term in the comment like quoted "Data Storage Interrupt" such that somebody reading the code has a change to find a description of these bits. Sure. It makes the term "searchable" in the ISA. Done. > Also, please update copyrights before pushing. > I don't need for a new webrev for that. > I think it can get pushed once G?tz' testing has completed. Copyrights updated. I think I can't push to jdk11u-dev nor to jdk11u because I'm not a jdk-updates project Committer, so I'll need a sponsor, hence I provide a new webrev: Webrev: http://cr.openjdk.java.net/~gromero/8223266/v2/ BTW, to get consistent with "Data Stotage Interrupt" comment in this change the following text must be change on jdk/jdk tip and downport. I can take care of downporting it if you are fine with that change. It looks like "%note os_trap_1" must be cleaned-up too: diff -r e9da84f26908 src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp --- a/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp Thu May 02 18:01:23 2019 -0400 +++ b/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp Fri May 03 11:58:59 2019 -0400 @@ -302,7 +302,6 @@ address stub = NULL; address pc = NULL; - //%note os_trap_1 if (info != NULL && uc != NULL && thread != NULL) { pc = (address) os::Linux::ucontext_get_pc(uc); @@ -311,17 +310,17 @@ // si_addr may not be valid due to a bug in the linux-ppc64 kernel (see // comment below). Use get_stack_bang_address instead of si_addr. // If SIGSEGV is caused due to a branch to an invalid address an - // "Instruction Storage" interruption is generated and 'pc' (NIP) already + // "Instruction Storage Interrupt" is generated and 'pc' (NIP) already // contains the invalid address. Otherwise, the SIGSEGV is caused due to // load/store instruction trying to load/store from/to an invalid address - // and causing a "Data Storage" interruption, so we inspect the intruction + // and causing a "Data Storage Interrupt", so we inspect the intruction // in order to extract the faulty data addresss. address addr; if ((ucontext_get_trap(uc) & 0x0F00 /* no IRQ reply bits */) == 0x0400) { - // Instruction interruption + // Instruction Storage Interrupt (ISI) addr = pc; } else { - // Data interruption (0x0300): extract faulty data address + // Data Storage Interrupt (DSI), i.e. 0x0300: extract faulty data address addr = ((NativeInstruction*)pc)->get_stack_bang_address(uc); } Thank you! Best regards, Gustavo From goetz.lindenmaier at sap.com Mon May 6 07:09:49 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 May 2019 07:09:49 +0000 Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization In-Reply-To: <35c86770-bba3-8af2-aac3-69fdf4660270@linux.vnet.ibm.com> References: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> <35c86770-bba3-8af2-aac3-69fdf4660270@linux.vnet.ibm.com> Message-ID: Hi Gustavo, > > Looking at the issue: > > actually the current VM would think the signal is a > > memory serialization and return true, while it is > > a real crash? (Or a simulated one as in the test?) > > is_memory_serialization() never returns, so the VM never knows if it's > indeed a memory serialization case or not. > > Because the issue on some old kernels forbids us to rely on 'si_addr' we > are inspecting the instruction at 'pc' to extract the registers used in > the instruction to determine the actual faulty address before calling > os::is_memory_serialize_page(), similarly to what we do to dertermine the > faulty address in get_stack_bang_address(). > > In doing it's assumed that SIGSEGV can only be caused due to a load/store > (Data Storage Interrupt), because it assumes it's always possible to read > the instruction at 'pc'. This is not true, particularly for a SIGSEGV due > to a branch to an invalid address (e.g. not mapped / no permission to > read/exec address), which is generated due to Instruction Storage Interrupt > (ISI). Hence we can use the interruption type (passed in 'trap' member to > the signal handler) to discern when it's possible to inspect the 'pc' (DSI) > and when it's not possible (ISI). > > The test case 13 precisely stresses that case of branching to an invalid > address by forcing a function bad pointer = 0xf and calling it (on PPC64 > that crash shows pc=0xc in the hs_err log due to the code alignment > requirements for execution). > > So the additional code block checking for SIGSEGV related to UseMemBar > feature on 11u needs to be adapted like the previous block using > get_stack_bang_address(), which is already fixed on jdk/jdk tip. Thanks for the detailed explanation! Our tests are green, too. Reviewed. You can push to jdk11u-dev once the bug gets the jdk11u-fix-yes tag. Best regards, Goetz. From martin.doerr at sap.com Mon May 6 08:11:44 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 6 May 2019 08:11:44 +0000 Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization In-Reply-To: <76c1afff-de58-9a23-a33c-fec6b8ae9df2@linux.vnet.ibm.com> References: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> <76c1afff-de58-9a23-a33c-fec6b8ae9df2@linux.vnet.ibm.com> Message-ID: Hi Gustavo, thanks for improving the comment. V2 looks good. Testing is also completed. I had missed that the jdk11u-fix-request and approval is not yet there. Can you request it, please? We can push it once it's approved. Best regards, Martin -----Original Message----- From: Gustavo Romero Sent: Freitag, 3. Mai 2019 18:09 To: Doerr, Martin ; jdk-updates-dev at openjdk.java.net Subject: Re: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization Hi Martin, On 05/03/2019 10:06 AM, Doerr, Martin wrote: > thanks for addressing this issue. > > The fix looks good to me. Thanks a lot for reviewing it. > I'd appreciate if you could use a term in the comment like quoted "Data Storage Interrupt" such that somebody reading the code has a change to find a description of these bits. Sure. It makes the term "searchable" in the ISA. Done. > Also, please update copyrights before pushing. > I don't need for a new webrev for that. > I think it can get pushed once G?tz' testing has completed. Copyrights updated. I think I can't push to jdk11u-dev nor to jdk11u because I'm not a jdk-updates project Committer, so I'll need a sponsor, hence I provide a new webrev: Webrev: http://cr.openjdk.java.net/~gromero/8223266/v2/ BTW, to get consistent with "Data Stotage Interrupt" comment in this change the following text must be change on jdk/jdk tip and downport. I can take care of downporting it if you are fine with that change. It looks like "%note os_trap_1" must be cleaned-up too: diff -r e9da84f26908 src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp --- a/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp Thu May 02 18:01:23 2019 -0400 +++ b/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp Fri May 03 11:58:59 2019 -0400 @@ -302,7 +302,6 @@ address stub = NULL; address pc = NULL; - //%note os_trap_1 if (info != NULL && uc != NULL && thread != NULL) { pc = (address) os::Linux::ucontext_get_pc(uc); @@ -311,17 +310,17 @@ // si_addr may not be valid due to a bug in the linux-ppc64 kernel (see // comment below). Use get_stack_bang_address instead of si_addr. // If SIGSEGV is caused due to a branch to an invalid address an - // "Instruction Storage" interruption is generated and 'pc' (NIP) already + // "Instruction Storage Interrupt" is generated and 'pc' (NIP) already // contains the invalid address. Otherwise, the SIGSEGV is caused due to // load/store instruction trying to load/store from/to an invalid address - // and causing a "Data Storage" interruption, so we inspect the intruction + // and causing a "Data Storage Interrupt", so we inspect the intruction // in order to extract the faulty data addresss. address addr; if ((ucontext_get_trap(uc) & 0x0F00 /* no IRQ reply bits */) == 0x0400) { - // Instruction interruption + // Instruction Storage Interrupt (ISI) addr = pc; } else { - // Data interruption (0x0300): extract faulty data address + // Data Storage Interrupt (DSI), i.e. 0x0300: extract faulty data address addr = ((NativeInstruction*)pc)->get_stack_bang_address(uc); } Thank you! Best regards, Gustavo From goetz.lindenmaier at sap.com Mon May 6 10:39:39 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 May 2019 10:39:39 +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: Hi Paul, thanks for reviewing this change! Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 11. April 2019 16:03 > To: jdk-updates-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: RFR(M): jdk11u-dev backport 8205611: Improve the wording of > LinkageErrors to include module and class loader information > > 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 gromero at linux.vnet.ibm.com Mon May 6 12:27:13 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 6 May 2019 09:27:13 -0300 Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization In-Reply-To: References: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> <35c86770-bba3-8af2-aac3-69fdf4660270@linux.vnet.ibm.com> Message-ID: Hi Goetz, Thanks a lot for reviewing it! I've just added the tag and the comment requesting for the approval to push. I'll ping when the approval request is updated. Best regards, Gustavo On 05/06/2019 04:09 AM, Lindenmaier, Goetz wrote: > Hi Gustavo, > >>> Looking at the issue: >>> actually the current VM would think the signal is a >>> memory serialization and return true, while it is >>> a real crash? (Or a simulated one as in the test?) >> >> is_memory_serialization() never returns, so the VM never knows if it's >> indeed a memory serialization case or not. >> >> Because the issue on some old kernels forbids us to rely on 'si_addr' we >> are inspecting the instruction at 'pc' to extract the registers used in >> the instruction to determine the actual faulty address before calling >> os::is_memory_serialize_page(), similarly to what we do to dertermine the >> faulty address in get_stack_bang_address(). >> >> In doing it's assumed that SIGSEGV can only be caused due to a load/store >> (Data Storage Interrupt), because it assumes it's always possible to read >> the instruction at 'pc'. This is not true, particularly for a SIGSEGV due >> to a branch to an invalid address (e.g. not mapped / no permission to >> read/exec address), which is generated due to Instruction Storage Interrupt >> (ISI). Hence we can use the interruption type (passed in 'trap' member to >> the signal handler) to discern when it's possible to inspect the 'pc' (DSI) >> and when it's not possible (ISI). >> >> The test case 13 precisely stresses that case of branching to an invalid >> address by forcing a function bad pointer = 0xf and calling it (on PPC64 >> that crash shows pc=0xc in the hs_err log due to the code alignment >> requirements for execution). >> >> So the additional code block checking for SIGSEGV related to UseMemBar >> feature on 11u needs to be adapted like the previous block using >> get_stack_bang_address(), which is already fixed on jdk/jdk tip. > > Thanks for the detailed explanation! Our tests are green, too. > > Reviewed. > You can push to jdk11u-dev once the bug gets the jdk11u-fix-yes tag. > > Best regards, > Goetz. > > From martin.doerr at sap.com Mon May 6 12:40:54 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 6 May 2019 12:40:54 +0000 Subject: RFR(M): jdk11u-dev backport 8205611: Improve the wording of LinkageErrors to include module and class loader information In-Reply-To: <2183FC12-27E9-420C-8906-35138923D8CB@amazon.com> References: <2183FC12-27E9-420C-8906-35138923D8CB@amazon.com> Message-ID: Hi G?tz, thanks for backporting. It would have been much easier to backport the issues in the correct order. I think you resolved that correctly. The jdk11u backport of JDK-8212937 diffs from the jdk12u version. diff -r test/hotspot/jtreg/runtime/LoaderConstraints/ ../jdk12u/test/hotspot/jtreg/runtime/LoaderConstraints/ diff -r test/hotspot/jtreg/runtime/LoaderConstraints/duplicateParentLE/Test.java ../jdk12u/test/hotspot/jtreg/runtime/LoaderConstraints/duplicateParentLE/Test.java 72c72 < System.out.println("Expected: " + expectedErrorMessage_part1 + "" + expectedErrorMessage_part2 + "" + expectedErrorMessage_part3 + "\n" + --- > System.out.println("Expected: " + expectedErrorMessage_part1 + "" + expectedErrorMessage_part2 + "\n" + But that's not related to your change. So your backport change looks good. Reviewed. Best regards, Martin -----Original Message----- From: jdk-updates-dev On Behalf Of Hohensee, Paul Sent: Freitag, 12. April 2019 19:21 To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M): jdk11u-dev backport 8205611: Improve the wording of LinkageErrors to include module and class loader information 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 gromero at linux.vnet.ibm.com Mon May 6 12:42:07 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 6 May 2019 09:42:07 -0300 Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization In-Reply-To: References: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> <76c1afff-de58-9a23-a33c-fec6b8ae9df2@linux.vnet.ibm.com> Message-ID: Hi Martin, On 05/06/2019 05:11 AM, Doerr, Martin wrote: > thanks for improving the comment. V2 looks good. Testing is also completed. Thanks a lot for reviewing it! I'll send a patch to improve the other part to jdk/jdk tip. > I had missed that the jdk11u-fix-request and approval is not yet there. > Can you request it, please? > We can push it once it's approved. I've just placed the request to push. I'll ping when the status is updated. Best regards, Gustavo From goetz.lindenmaier at sap.com Mon May 6 12:49:22 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 May 2019 12:49:22 +0000 Subject: RFR(M): jdk11u-dev backport 8205611: Improve the wording of LinkageErrors to include module and class loader information In-Reply-To: References: <2183FC12-27E9-420C-8906-35138923D8CB@amazon.com> Message-ID: Hi Martin, thanks for looking at this! Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 6. Mai 2019 14:41 > To: Hohensee, Paul ; Lindenmaier, Goetz > ; jdk-updates-dev at openjdk.java.net; hotspot- > dev at openjdk.java.net > Subject: RE: RFR(M): jdk11u-dev backport 8205611: Improve the wording of > LinkageErrors to include module and class loader information > > Hi G?tz, > > thanks for backporting. > It would have been much easier to backport the issues in the correct order. > I think you resolved that correctly. > > The jdk11u backport of JDK-8212937 diffs from the jdk12u version. > diff -r test/hotspot/jtreg/runtime/LoaderConstraints/ > ../jdk12u/test/hotspot/jtreg/runtime/LoaderConstraints/ > diff -r > test/hotspot/jtreg/runtime/LoaderConstraints/duplicateParentLE/Test.java > ../jdk12u/test/hotspot/jtreg/runtime/LoaderConstraints/duplicateParentLE/Te > st.java > 72c72 > < System.out.println("Expected: " + expectedErrorMessage_part1 + > "" + expectedErrorMessage_part2 + "" + expectedErrorMessage_part3 > + "\n" + > --- > > System.out.println("Expected: " + expectedErrorMessage_part1 + > "" + expectedErrorMessage_part2 + "\n" + > > But that's not related to your change. > > So your backport change looks good. Reviewed. > > Best regards, > Martin > > > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Freitag, 12. April 2019 19:21 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): jdk11u-dev backport 8205611: Improve the wording of > LinkageErrors to include module and class loader information > > 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" updates-dev-bounces at openjdk.java.net on behalf of > goetz.lindenmaier at sap.com> 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 goetz.lindenmaier at sap.com Mon May 6 12:59:23 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 May 2019 12:59:23 +0000 Subject: RFR(S): jdk11u-dev backport 8216556: Unnecessary liveness computation with JVMTI In-Reply-To: References: Message-ID: Hi Martin, you well intergrated this change to 11. Thanks for downporting it, it will help the debugging performance slightly. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 6. Mai 2019 14:54 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; Lindenmaier, Goetz > Subject: RFR(S): jdk11u-dev backport 8216556: Unnecessary liveness > computation with JVMTI > > Hi, > > > > I'd like to backport this change to jdk11u because it's very simply and avoids > some unnecessary overhead. > > Applies almost cleanly (only needs manual resolution because neighboring > hunk has changed: CompileTheWorld removal). > > > > bug: > > https://bugs.openjdk.java.net/browse/JDK-8216556 > > > > original change: > > http://hg.openjdk.java.net/jdk/jdk/rev/91ab128a65a3 > > > > jdk11u webrev: > > http://cr.openjdk.java.net/~mdoerr/8216556_JVMTI_liveness/jdk11u/webrev. > 00/ > > > > I only had to reapply the change around > > "if (CURRENT_ENV->should_retain_local_variables() || DeoptimizeALot || > CompileTheWorld) {" > > (ciMethod.cpp) because CompileTheWorld was removed. > > > > Please review. > > > > Best regards, > > Martin > > From martin.doerr at sap.com Mon May 6 13:05:13 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 6 May 2019 13:05:13 +0000 Subject: RFR(S): jdk11u-dev backport 8216556: Unnecessary liveness computation with JVMTI In-Reply-To: References: Message-ID: Hi G?tz, thank you for reviewing. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 6. Mai 2019 14:59 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' ; jdk-updates-dev at openjdk.java.net Subject: RE: RFR(S): jdk11u-dev backport 8216556: Unnecessary liveness computation with JVMTI Hi Martin, you well intergrated this change to 11. Thanks for downporting it, it will help the debugging performance slightly. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 6. Mai 2019 14:54 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; Lindenmaier, Goetz > Subject: RFR(S): jdk11u-dev backport 8216556: Unnecessary liveness > computation with JVMTI > > Hi, > > > > I'd like to backport this change to jdk11u because it's very simply and avoids > some unnecessary overhead. > > Applies almost cleanly (only needs manual resolution because neighboring > hunk has changed: CompileTheWorld removal). > > > > bug: > > https://bugs.openjdk.java.net/browse/JDK-8216556 > > > > original change: > > http://hg.openjdk.java.net/jdk/jdk/rev/91ab128a65a3 > > > > jdk11u webrev: > > http://cr.openjdk.java.net/~mdoerr/8216556_JVMTI_liveness/jdk11u/webrev. > 00/ > > > > I only had to reapply the change around > > "if (CURRENT_ENV->should_retain_local_variables() || DeoptimizeALot || > CompileTheWorld) {" > > (ciMethod.cpp) because CompileTheWorld was removed. > > > > Please review. > > > > Best regards, > > Martin > > From christoph.langer at sap.com Tue May 7 10:46:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 7 May 2019 10:46:29 +0000 Subject: [8u, 11u]: Fix approvals, hgupdater status Message-ID: Hi Andrew, It seems like quite some fix requests have piled up in both, jdk8 and jdk11 updates. Is there any particular reason why the approvals are currently stalling (other than holidays)? ?? Furthermore, are there any updates from hgupdater for jdk11u and jdk8u repos? Thank you, Christoph From gromero at linux.vnet.ibm.com Tue May 7 13:06:30 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 7 May 2019 10:06:30 -0300 Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization In-Reply-To: References: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> <76c1afff-de58-9a23-a33c-fec6b8ae9df2@linux.vnet.ibm.com> Message-ID: Hi Martin, On 05/06/2019 09:42 AM, Gustavo Romero wrote: > On 05/06/2019 05:11 AM, Doerr, Martin wrote: >> I had missed that the jdk11u-fix-request and approval is not yet there. >> Can you request it, please? >> We can push it once it's approved. > > I've just placed the request to push. I'll ping when the status is updated. Andrew approved the change to be pushed. Could you sponsor the change please? Best regards, Gustavo From aph at redhat.com Tue May 7 13:33:37 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 May 2019 14:33:37 +0100 Subject: [8u, 11u]: Fix approvals, hgupdater status In-Reply-To: References: Message-ID: <3e709bdb-bdd9-e999-2727-034d6515f1d2@redhat.com> On 5/7/19 11:46 AM, Langer, Christoph wrote: > It seems like quite some fix requests have piled up in both, jdk8 and jdk11 updates. Is there any particular reason why the approvals are currently stalling (other than holidays)? ?? Probably. > Furthermore, are there any updates from hgupdater for jdk11u and jdk8u repos? All done. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Tue May 7 13:45:08 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 7 May 2019 13:45:08 +0000 Subject: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization In-Reply-To: References: <951d8b49-47b3-5cea-bea3-2c1e6627de66@linux.vnet.ibm.com> <76c1afff-de58-9a23-a33c-fec6b8ae9df2@linux.vnet.ibm.com> Message-ID: Done. Thanks, Martin -----Original Message----- From: Gustavo Romero Sent: Dienstag, 7. Mai 2019 15:07 To: Doerr, Martin ; jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: Re: [11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization Hi Martin, On 05/06/2019 09:42 AM, Gustavo Romero wrote: > On 05/06/2019 05:11 AM, Doerr, Martin wrote: >> I had missed that the jdk11u-fix-request and approval is not yet there. >> Can you request it, please? >> We can push it once it's approved. > > I've just placed the request to push. I'll ping when the status is updated. Andrew approved the change to be pushed. Could you sponsor the change please? Best regards, Gustavo From goetz.lindenmaier at sap.com Tue May 7 13:58:15 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 May 2019 13:58:15 +0000 Subject: [8u, 11u]: Fix approvals, hgupdater status In-Reply-To: <3e709bdb-bdd9-e999-2727-034d6515f1d2@redhat.com> References: <3e709bdb-bdd9-e999-2727-034d6515f1d2@redhat.com> Message-ID: Hi Andrew, thanks for driving the hgupdater issue. I will carefully pull jdk11u-dev to jdk11u tomorrow after tagging. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Haley > Sent: Dienstag, 7. Mai 2019 15:34 > To: Langer, Christoph > Cc: 'jdk8u-dev at openjdk.java.net' ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [8u, 11u]: Fix approvals, hgupdater status > > On 5/7/19 11:46 AM, Langer, Christoph wrote: > > It seems like quite some fix requests have piled up in both, jdk8 and jdk11 > updates. Is there any particular reason why the approvals are currently stalling > (other than holidays)? ?? > > Probably. > > > Furthermore, are there any updates from hgupdater for jdk11u and jdk8u > repos? > > All done. > > -- > 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 May 7 14:13:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 7 May 2019 14:13:46 +0000 Subject: [8u, 11u]: Fix approvals, hgupdater status In-Reply-To: References: <3e709bdb-bdd9-e999-2727-034d6515f1d2@redhat.com> Message-ID: Thanks, Andrew. Let's keep fingers crossed that all works when pulling over. Otherwise we'll have to go through several dozens of false 11.0.3 backport items and fix them manually. /Christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 7. Mai 2019 15:58 > To: Andrew Haley ; Langer, Christoph > > Cc: 'jdk8u-dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net > Subject: RE: [8u, 11u]: Fix approvals, hgupdater status > > Hi Andrew, > > thanks for driving the hgupdater issue. > I will carefully pull jdk11u-dev to jdk11u tomorrow after tagging. > > Best regards, > Goetz. > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Andrew Haley > > Sent: Dienstag, 7. Mai 2019 15:34 > > To: Langer, Christoph > > Cc: 'jdk8u-dev at openjdk.java.net' ; jdk- > updates- > > dev at openjdk.java.net > > Subject: Re: [8u, 11u]: Fix approvals, hgupdater status > > > > On 5/7/19 11:46 AM, Langer, Christoph wrote: > > > It seems like quite some fix requests have piled up in both, jdk8 and > jdk11 > > updates. Is there any particular reason why the approvals are currently > stalling > > (other than holidays)? ?? > > > > Probably. > > > > > Furthermore, are there any updates from hgupdater for jdk11u and > jdk8u > > repos? > > > > All done. > > > > -- > > 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 May 7 14:15:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 7 May 2019 14:15:56 +0000 Subject: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 In-Reply-To: References: Message-ID: Ping: Can I please get a review for this? From: Langer, Christoph Sent: Dienstag, 30. April 2019 11:26 To: jdk-updates-dev at openjdk.java.net Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net; Baesken, Matthias Subject: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 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 May 7 14:51:23 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 May 2019 14:51:23 +0000 Subject: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 In-Reply-To: References: Message-ID: Hi Christoph, I had a look at this change. The integration is good. I thought about the adaptions you had to do. They look good for the compilers you mention, and I would assume they also work with more recent ones. I guess nobody uses more recent compilers on Solaris. On AIX I know further adaptions are needed, and as they are missing it is ruled out anybody compiles with xlc 16. So looks good, too. I checked the tests, and the only somewhat related failing one is java/awt/FontMetrics/MaxAdvanceIsMax.java, but that is also failing without your patch. So testing is fine. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Dienstag, 30. April 2019 11:26 > To: jdk-updates-dev at openjdk.java.net > Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net; Baesken, > Matthias > Subject: [CAUTION] [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 > > 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 sgehwolf at redhat.com Tue May 7 15:19:40 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 07 May 2019 17:19:40 +0200 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: Message-ID: On Tue, 2019-05-07 at 14:51 +0000, Lindenmaier, Goetz wrote: > I checked the tests, and the only somewhat related > failing one is java/awt/FontMetrics/MaxAdvanceIsMax.java, > but that is also failing without your patch. How is it failing and has a bug been create for this failure if it's not a test setup issue? https://bugs.openjdk.java.net/browse/JDK-8218854 FWIW, I have: Passed: java/awt/FontMetrics/MaxAdvanceIsMax.java Thanks, Severin From goetz.lindenmaier at sap.com Wed May 8 06:26:56 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 8 May 2019 06:26:56 +0000 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: Message-ID: Hi Severin, Thanks for looking at the issue! I can reproduce the issue starting the test stand alone. So it's not a problem of our test infrastructure. But I can only reproduce it on a limited set of OSes: linuxppc64le: Red Hat Enterprise Linux Server release 7.2 (Maipo) Red Hat Enterprise Linux Server release 7.3 (Maipo) SUSE Linux Enterprise Server 15 I cannot reproduce it on these OSes: linuxppc64le: Red Hat Enterprise Linux Server VERSION 7.4 (Maipo) SUSE Linux Enterprise Server 12 (ppc64le) VERSION = 12 PATCHLEVEL = 1 Ubuntu 16.04.3 LTS Unfortunately, I don't have RHEL 7.2 or 7.3 on a linuxx86_64 box. But the test is passing on SLES 15 on linuxx86_64. I didn't yet open a bug for this, but the failure is still there with jdk-11.0.4+2. Checking 11.0.3, I see the failure too. So it is not a regression. I also can reproduce it with jdk/jdk on RHEL 7.2. Our nightly tests of 11.0.3 and jdk/jdk are scheduled on a SLES 12.3, therefor they don't show the problem. I'll send you a jtr file of the failure off-list. Best regards, Goetz. > -----Original Message----- > From: Severin Gehwolf > Sent: Tuesday, May 7, 2019 5:20 PM > To: Lindenmaier, Goetz ; Langer, Christoph > ; jdk-updates-dev at openjdk.java.net > Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net; > Martin Balao Alonso > Subject: Re: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure > (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) > > On Tue, 2019-05-07 at 14:51 +0000, Lindenmaier, Goetz wrote: > > I checked the tests, and the only somewhat related > > failing one is java/awt/FontMetrics/MaxAdvanceIsMax.java, > > but that is also failing without your patch. > > How is it failing and has a bug been create for this failure if it's > not a test setup issue? > > https://bugs.openjdk.java.net/browse/JDK-8218854 > > FWIW, I have: > > Passed: java/awt/FontMetrics/MaxAdvanceIsMax.java > > Thanks, > Severin From christoph.langer at sap.com Wed May 8 07:27:24 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 8 May 2019 07:27:24 +0000 Subject: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 In-Reply-To: References: Message-ID: Thanks for the review, Goetz. I still need approval, though... > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 7. Mai 2019 16:51 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net > Subject: RE: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 > > Hi Christoph, > > I had a look at this change. > The integration is good. > > I thought about the adaptions you had to do. > They look good for the compilers you mention, and I > would assume they also work with more recent ones. > I guess nobody uses more recent compilers on Solaris. > On AIX I know further adaptions are needed, and as > they are missing it is ruled out anybody compiles with xlc 16. > So looks good, too. > > I checked the tests, and the only somewhat related > failing one is java/awt/FontMetrics/MaxAdvanceIsMax.java, > but that is also failing without your patch. > So testing is fine. > > Best regards, > Goetz. > > > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Langer, Christoph > > Sent: Dienstag, 30. April 2019 11:26 > > To: jdk-updates-dev at openjdk.java.net > > Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net; > Baesken, > > Matthias > > Subject: [CAUTION] [11u] RFR 8210782: Upgrade HarfBuzz to the latest > 2.3.1 > > > > 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 T::min_size)> > > > > > { 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 GROEGES at uk.ibm.com Wed May 8 12:33:27 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 8 May 2019 13:33:27 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: The bug [1] which was merged into jdk/jdk [3] has been approved for back-porting to jdk11u and to jdk12u. Please could someone sponsor the back-ports and ensure that the code is merged into the relevant repositories. [1] https://bugs.openjdk.java.net/browse/JDK-8218152 [2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.04/ [3] http://hg.openjdk.java.net/jdk/jdk/rev/d9208a660094 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: Steve Groeger To: Andrew John Hughes Cc: jdk-updates-dev , "'jdk8u-dev at openjdk.java.net'" , jdk-updates-dev at openjdk.java.net Date: 02/05/2019 09:43 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Sent by: "jdk-updates-dev" Hi Andrew, Thanks for taking a look at this. > Regarding the 8u webrev, the two additions for hasNext() and next() in > JavacProcessingEnvironment.java seem to have been flipped. Was this > intentional? Comparing patched jdk8u with the jdk/jdk version: Yes, this was intentional. When I investigated this issue I did initially add the changes to hasNext() in the jdk8u code but that didn't resolve the issue. Having then looked at a generated stack trace it showed that the code was going thru the next() method and failing there rather than in hasNext(). Hence the reason the changes were put in the next() method for jdk8u and in the hasNext() for jdk11 and above. Seems the JavacProcessingEnvoronment.java class has changed since jdk8. > The test changes look ok and I assume they pass. Yes, the tests do pass when run on my local environment for all releases jdk8u, jdk11u and jdk12u. > Long term, we may want to look at backporting > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8050429&d=DwIBAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=LkzUD_N0v0KwSG0YynY27x94cP7H0yoJ6U7weXpeyPQ&s=3Yl646g64OzPtT77EUuXwAhXV6ZVMzF7ykQyPLV3KX4&e= > to avoid this work for every test. I agree that we need to back-port this at some point. It gets quite time consuming having to change tests that are created on jdk11u+ and need to be back-ported to jdk8u. Is there anything else I need to do in order to get these back-ports merged. If so, please let me know. 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: Andrew John Hughes To: jdk-updates-dev at openjdk.java.net, "'jdk8u-dev at openjdk.java.net'" Date: 01/05/2019 17:00 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Sent by: "jdk-updates-dev" [CCing jdk8u-dev for 8u review] On 01/05/2019 08:04, Steve Groeger wrote: > Hi all, > > The following issue [1] has been raised and the associated webrev [2] has > been approved and the code merged into jdk/jdk [3] > I am now requesting this fix to be back-ported to jdk8u, jdk11u and > jdk12u. > The patch imports and works correctly on jdk8u and jdk12u but not quite on > jdk8u due to difference in the test framework. > I have created a separate webrev for the jdk8u changes [4]. > I am therefore requesting someone to review these changes and to sponsor > these updates to jdk8u, jdk11u and jdk12u. > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=qupvoIE2b9o6H2gvzu3EdQUSjE0HvDBZeDXycoIlg4w&e= > [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.04_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=Lx2f4bK7_yW6MWLgQYj-Y8GzL5NbAH95L7X_ptB9SBk&e= > [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_d9208a660094&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=4I9emNaREfISeASbo-TDQVJ3x6_pTiKFtlFPK8K2hTk&e= > [4] https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.04_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=ByHXRWAiDbkm9dsfgHchCQR4FMQiZc_ge0LYlRQkYD8&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 > 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 > Regarding the 8u webrev, the two additions for hasNext() and next() in JavacProcessingEnvironment.java seem to have been flipped. Was this intentional? Comparing patched jdk8u with the jdk/jdk version: --- src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 16:50:40.409545256 +0100 +++ ../../jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 03:00 public boolean hasNext() { try { - return iterator.hasNext(); + return internalHasNext(); } catch(ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); + } catch (UnsupportedClassVersionError ucve) { + log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); + throw new Abort(ucve); + } catch (ClassFormatError cfe) { + log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); + throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } ... public Processor next() { try { - return iterator.next(); + return internalNext(); } catch (ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); - } catch (UnsupportedClassVersionError ucve) { - log.error("proc.cant.load.class", ucve.getLocalizedMessage()); - throw new Abort(ucve); - } catch (ClassFormatError cfe) { - log.error("proc.cant.load.class", cfe.getLocalizedMessage()); - throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } The test changes look ok and I assume they pass. Long term, we may want to look at backporting https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8050429&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=q-BAu0YUQlwQmBEoesgfjRpVLy_wpTd8b1UZ7CZ_Akk&e= to avoid this work for every test. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. ( https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redhat.com&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=IXk7fITakTIJN8xZ0a-S80B5oFOvfv5yzV1wdICi7hA&e= ) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://urldefense.proofpoint.com/v2/url?u=https-3A__keybase.io_gnu-5Fandrew&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=iHeIglNN6XbY2FUKnkzs8A3gd7i9W_jO428tjpYD-Q0&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 Wed May 8 14:15:09 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 8 May 2019 14:15:09 +0000 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: Hi Steve, I'll push the changes to jdk11u and jdk12u. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Steve Groeger > Sent: Mittwoch, 8. Mai 2019 14:33 > To: Steve Groeger > Cc: jdk-updates-dev ; jdk- > updates-dev at openjdk.java.net > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > > The bug [1] which was merged into jdk/jdk [3] has been approved for > back-porting to jdk11u and to jdk12u. > Please could someone sponsor the back-ports and ensure that the code is > merged into the relevant repositories. > > [1] https://bugs.openjdk.java.net/browse/JDK-8218152 > [2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.04/ > [3] http://hg.openjdk.java.net/jdk/jdk/rev/d9208a660094 > > 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: Steve Groeger > To: Andrew John Hughes > Cc: jdk-updates-dev , > "'jdk8u-dev at openjdk.java.net'" , > jdk-updates-dev at openjdk.java.net > Date: 02/05/2019 09:43 > Subject: Re: RFR: [8218152] javac fails and exits with no error if > a bad annotation processor is on the classpath > Sent by: "jdk-updates-dev" > > > > > Hi Andrew, > > Thanks for taking a look at this. > > > Regarding the 8u webrev, the two additions for hasNext() and next() in > > JavacProcessingEnvironment.java seem to have been flipped. Was this > > intentional? Comparing patched jdk8u with the jdk/jdk version: > > Yes, this was intentional. When I investigated this issue I did initially > add the changes to hasNext() in the jdk8u code but that didn't resolve the > > issue. Having then looked at a generated stack trace it showed that the > code was going thru the next() method and failing there rather than in > hasNext(). Hence the reason the changes were put in the next() method for > jdk8u and in the hasNext() for jdk11 and above. Seems the > JavacProcessingEnvoronment.java class has changed since jdk8. > > > The test changes look ok and I assume they pass. > > Yes, the tests do pass when run on my local environment for all releases > jdk8u, jdk11u and jdk12u. > > > Long term, we may want to look at backporting > > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__bugs.openjdk.java.net_browse_JDK- > 2D8050429&d=DwIBAg&c=jf_iaSHvJObTbx- > siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=LkzUD_N0v0KwSG0YynY27x94cP7H0yoJ6U7 > weXpeyPQ&s=3Yl646g64OzPtT77EUuXwAhXV6ZVMzF7ykQyPLV3KX4&e= > > > to avoid this work for every test. > > I agree that we need to back-port this at some point. It gets quite time > consuming having to change tests that are created on jdk11u+ and need to > be back-ported to jdk8u. > > Is there anything else I need to do in order to get these back-ports > merged. If so, please let me know. > > 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: Andrew John Hughes > To: jdk-updates-dev at openjdk.java.net, "'jdk8u-dev at openjdk.java.net'" > > Date: 01/05/2019 17:00 > Subject: Re: RFR: [8218152] javac fails and exits with no error if > a bad annotation processor is on the classpath > Sent by: "jdk-updates-dev" > > > > > [CCing jdk8u-dev for 8u review] > > On 01/05/2019 08:04, Steve Groeger wrote: > > Hi all, > > > > The following issue [1] has been raised and the associated webrev [2] > has > > been approved and the code merged into jdk/jdk [3] > > I am now requesting this fix to be back-ported to jdk8u, jdk11u and > > jdk12u. > > The patch imports and works correctly on jdk8u and jdk12u but not quite > on > > jdk8u due to difference in the test framework. > > I have created a separate webrev for the jdk8u changes [4]. > > I am therefore requesting someone to review these changes and to > sponsor > > > > these updates to jdk8u, jdk11u and jdk12u. > > > > [1] > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__bugs.openjdk.java.net_browse_JDK- > 2D8218152&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjAp > BdRxGug&s=qupvoIE2b9o6H2gvzu3EdQUSjE0HvDBZeDXycoIlg4w&e= > > > > [2] > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__cr.openjdk.java.net_- > 7Esgroeger_8218152_jdk_webrev.04_&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjAp > BdRxGug&s=Lx2f4bK7_yW6MWLgQYj-Y8GzL5NbAH95L7X_ptB9SBk&e= > > > > [3] > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__hg.openjdk.java.net_jdk_jdk_rev_d9208a660094&d=DwIFaQ&c=jf_iaS > HvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjAp > BdRxGug&s=4I9emNaREfISeASbo-TDQVJ3x6_pTiKFtlFPK8K2hTk&e= > > > > [4] > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__cr.openjdk.java.net_- > 7Esgroeger_8218152_jdk8u_webrev.04_&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjAp > BdRxGug&s=ByHXRWAiDbkm9dsfgHchCQR4FMQiZc_ge0LYlRQkYD8&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 > > 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 > > > > Regarding the 8u webrev, the two additions for hasNext() and next() in > JavacProcessingEnvironment.java seem to have been flipped. Was this > intentional? Comparing patched jdk8u with the jdk/jdk version: > > --- > src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironm > ent.java > 2019-05-01 16:50:40.409545256 +0100 > +++ > ../../jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/Jav > acProcessingEnvironment.java > 2019-05-01 03:00 > > public boolean hasNext() { > try { > - return iterator.hasNext(); > + return internalHasNext(); > } catch(ServiceConfigurationError sce) { > - log.error("proc.bad.config.file", > sce.getLocalizedMessage()); > + > log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); > throw new Abort(sce); > + } catch (UnsupportedClassVersionError ucve) { > + > log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); > + throw new Abort(ucve); > + } catch (ClassFormatError cfe) { > + > log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); > + throw new Abort(cfe); > } catch (Throwable t) { > - log.error("proc.bad.config.file", > t.getLocalizedMessage()); > + > log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); > throw new Abort(t); > } > } > > ... > > public Processor next() { > try { > - return iterator.next(); > + return internalNext(); > } catch (ServiceConfigurationError sce) { > - log.error("proc.bad.config.file", > sce.getLocalizedMessage()); > + > log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); > throw new Abort(sce); > - } catch (UnsupportedClassVersionError ucve) { > - log.error("proc.cant.load.class", > ucve.getLocalizedMessage()); > - throw new Abort(ucve); > - } catch (ClassFormatError cfe) { > - log.error("proc.cant.load.class", > cfe.getLocalizedMessage()); > - throw new Abort(cfe); > } catch (Throwable t) { > - log.error("proc.bad.config.file", > t.getLocalizedMessage()); > + > log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); > throw new Abort(t); > } > } > > The test changes look ok and I assume they pass. Long term, we may want > to look at backporting > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__bugs.openjdk.java.net_browse_JDK- > 2D8050429&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjAp > BdRxGug&s=q-BAu0YUQlwQmBEoesgfjRpVLy_wpTd8b1UZ7CZ_Akk&e= > > > to avoid this work for every test. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. ( > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.redhat.com&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjAp > BdRxGug&s=IXk7fITakTIJN8xZ0a-S80B5oFOvfv5yzV1wdICi7hA&e= > > ) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://urldefense.proofpoint.com/v2/url?u=https-3A__keybase.io_gnu- > 5Fandrew&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=78GW2OHz7nNTH2dBkTx7- > TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjAp > BdRxGug&s=iHeIglNN6XbY2FUKnkzs8A3gd7i9W_jO428tjpYD-Q0&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 martin.doerr at sap.com Wed May 8 15:37:03 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 8 May 2019 15:37:03 +0000 Subject: RFR(S): jdk11u-dev backport 8181143: Introduce diagnostic flag to abort VM on too long VM operations Message-ID: Hi, I'd like to backport this change to jdk11u because it's a helpful feature to diagnose too long running VM operations. bug: https://bugs.openjdk.java.net/browse/JDK-8181143 original change: http://hg.openjdk.java.net/jdk/jdk/rev/c403f39ec349 jdk11u webrev: http://cr.openjdk.java.net/~mdoerr/8181143_AbortVMOnVMOperationTimeout/jdk11u/webrev.00/ I only had to insert the #include "runtime/task.hpp" manually into vmThread.hpp because the succeeding include was changed in jdk12. Note that this change needs to get backported together with JDK-8215374 which is a simply fix for the original change which applies cleanly. Please review. Best regards, Martin From goetz.lindenmaier at sap.com Thu May 9 09:39:41 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 9 May 2019 09:39:41 +0000 Subject: Tagged 11.0.4+2 in jdk11u-dev. Sharing test failures. Message-ID: Hi, I tagged 11.0.4+2 in jdk11u-dev and pulled that tag to jdk11u. Update on the test failures I see: 11.0.4+2 failures: ----------------- linux ppc64le jdk/internal/platform/cgroup/TestCgroupMetrics.java Test failed for - memory:memory.kmem.tcp.usage_in_bytes, expected [131072], got [196608] I see this failing in 13 for quite a while, but now the first time in jdk11u-dev. 11.0.4+1 failures reproduced: ----------------------------- aix ppc64 java/nio/file/Files/DeleteOnClose.java JavaTest Message: Test threw exception: java.lang.RuntimeException: IOException expected java/nio/file/Files/SBC.java java.lang.RuntimeException at SBC.noFollowLinksTests(SBC.java:238) linux x86_64 and mac security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status Maybe an infrastructure problem. mac x86_64 java/net/MulticastSocket/Promiscuous.java java.lang.RuntimeException: Expected message not received, Receive timed out java/net/MulticastSocket/SetOutgoingIf.java java.net.SocketTimeoutException: Receive timed out solaris sparc, fastdebug build Tier 1!! compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Not enough space in non-nmethod code heap to run VM: 20480K < 21475K windows x86_64, fastdebug build java/net/httpclient/SmokeTest.java timeout 11.0.4+2 failures not reproduced: --------------------------------- all ppc platforms, fastdebug build vmTestbase/vm/mlvm/meth/stress/gc/createLotsOfMHConsts/Test.java sporadic timeouts ### TRACE 1: RNG seed = -7264363496160763377 (0x9b2fcbe37405e20f) Timeout refired 720 times linux s390x java/lang/management/MemoryMXBean/LowMemoryTest2.sh Exception in thread "Thread-0" java.lang.OutOfMemoryError: Compressed class space Resolved Issues: ---------------- all java/util/Calendar/NarrowNamesTest.sh java.lang.RuntimeException: test failed at NarrowNamesTest.main(NarrowNamesTest.java:134) I see this on various VMs today, also 11.0.3 and 8. But not consistently over all builds. For 11.0.4 only solaris sparc failed. Some kind of Japanese Era problem? Update 2019-05-08: I only saw this on 2019-05-01. It did not happen again, although the test ran a few hundred times on different JVMs, Java versions, OSes and CPUs. linux ppc64le runtime/ErrorHandling/ErrorHandler.java Fixed by Gustavo: 8223266: PPC64: Check for branch to illegal address before checking for mem serialization Thanks! linux ppc64le java/awt/FontMetrics/MaxAdvanceIsMax.java FAILED: getMaxAdvance is not max for font: java.awt.Font This is reproducible on RHEL 7.2 and 7.3 and SLES 15. I could not reproduce it on other CPUs. I can reproduce it with 11.0.3 and jdk/jdk on the given OSes, so it is not a regression of 11.0.4. windows x86_64, fastdebug build vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch002/TestDescription.java vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch004/TestDescription.java vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch010/TestDescription.java Error: Could not find or load main class nsk.jvmti.AddToBootstrapClassLoaderSearch.bootclssearch002 Caused by: java.lang.NoClassDefFoundError: nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch002p This is a test infrastructure problem. The paths used in the test exceed a limit of the windows OS because they include 'jdk11u-dev' which is longer than 'jdk11u'. The 11.0.3 tests I compare to are those of jdk11u... Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Mittwoch, 1. Mai 2019 15:34 > To: 'jdk8u-dev at openjdk.java.net' ; 'jdk- > updates-dev at openjdk.java.net' > Subject: Tagged 11.0.4+1 in jdk11u-dev. Sharing test failures. > > Hi, > > I tagged jdk11.0.4+1 in jdk11u-dev. > > below I list the jtreg tests we see failing as of jdk11.0.4+1. > This includes all tests I see failing, without ruling out > setup issues and the like. > These tests were not failing in our 11.0.3 builds, nor > in 12 or 13 except if explicitly stated. The fact they > are failing on a certain platform does not mean the bug > is platform dependent. Sometimes it's just the dependency > to the OS variant. We test on a wide variety of different > machines, OSes etc. > In the next days I will have a closer look at the > failures and open JBS issues if adequate. > If someone jumps in and adresses one of these issues > he is more than welcome. If so, I'm happy to share > more details about the failures. > > Best regards, > Goetz. > > all > java/util/Calendar/NarrowNamesTest.sh > java.lang.RuntimeException: test failed at > NarrowNamesTest.main(NarrowNamesTest.java:134) > I see this on various VMs today, also 11.0.3 and 8. But not consistently over > all builds. > For 11.0.4 only solaris sparc failed. Some kind of Japanese Era problem? > > all ppc platforms > vmTestbase/vm/mlvm/meth/stress/gc/createLotsOfMHConsts/Test.java > sporadic timeouts > ### TRACE 1: RNG seed = -7264363496160763377 (0x9b2fcbe37405e20f) > Timeout refired 720 times > > aix ppc64 > java/nio/file/Files/DeleteOnClose.java > JavaTest Message: Test threw exception: java.lang.RuntimeException: > IOException expected > java/nio/file/Files/SBC.java > java.lang.RuntimeException at SBC.noFollowLinksTests(SBC.java:238) > > linux ppc64le > runtime/ErrorHandling/ErrorHandler.java > Gustavo > java/awt/FontMetrics/MaxAdvanceIsMax.java > FAILED: getMaxAdvance is not max for font: java.awt.Font > > linux s390x > java/lang/management/MemoryMXBean/LowMemoryTest2.sh > Exception in thread "Thread-0" java.lang.OutOfMemoryError: Compressed > class space > > linux x86_64 and mac > > security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6 > CA.java > java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate > status > Maybe an infrastructure problem. > > mac x86_64 > java/net/MulticastSocket/Promiscuous.java > java.lang.RuntimeException: Expected message not received, Receive timed > out > java/net/MulticastSocket/SetOutgoingIf.java > java.net.SocketTimeoutException: Receive timed out > > solaris sparc > Tier 1!! > compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java > compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java > Not enough space in non-nmethod code heap to run VM: 20480K < 21475K > > windows x86_64 > > vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch002/T > estDescription.java > > vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch004/T > estDescription.java > > vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch010/T > estDescription.java > Error: Could not find or load main class > nsk.jvmti.AddToBootstrapClassLoaderSearch.bootclssearch002 > Caused by: java.lang.NoClassDefFoundError: > nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch002p > java/net/httpclient/SmokeTest.java > timeout > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Tuesday, April 30, 2019 2:48 PM > > To: Andrew John Hughes ; 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 > > > > 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 goetz.lindenmaier at sap.com Thu May 9 09:55:18 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 9 May 2019 09:55:18 +0000 Subject: RFR(S): jdk11u-dev backport 8181143: Introduce diagnostic flag to abort VM on too long VM operations In-Reply-To: References: Message-ID: Hi, the change is all fine. Best regards, Goetz. From: Doerr, Martin Sent: Mittwoch, 8. Mai 2019 17:37 To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; Lindenmaier, Goetz Subject: RFR(S): jdk11u-dev backport 8181143: Introduce diagnostic flag to abort VM on too long VM operations Hi, I'd like to backport this change to jdk11u because it's a helpful feature to diagnose too long running VM operations. bug: https://bugs.openjdk.java.net/browse/JDK-8181143 original change: http://hg.openjdk.java.net/jdk/jdk/rev/c403f39ec349 jdk11u webrev: http://cr.openjdk.java.net/~mdoerr/8181143_AbortVMOnVMOperationTimeout/jdk11u/webrev.00/ I only had to insert the #include "runtime/task.hpp" manually into vmThread.hpp because the succeeding include was changed in jdk12. Note that this change needs to get backported together with JDK-8215374 which is a simply fix for the original change which applies cleanly. Please review. Best regards, Martin From martin.doerr at sap.com Thu May 9 09:59:43 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 9 May 2019 09:59:43 +0000 Subject: RFR(S): jdk11u-dev backport 8181143: Introduce diagnostic flag to abort VM on too long VM operations In-Reply-To: References: Message-ID: Hi G?tz, thank you for the review. Best regards, Martin From: Lindenmaier, Goetz Sent: Donnerstag, 9. Mai 2019 11:55 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Subject: RE: RFR(S): jdk11u-dev backport 8181143: Introduce diagnostic flag to abort VM on too long VM operations Hi, the change is all fine. Best regards, Goetz. From: Doerr, Martin Sent: Mittwoch, 8. Mai 2019 17:37 To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; Lindenmaier, Goetz > Subject: RFR(S): jdk11u-dev backport 8181143: Introduce diagnostic flag to abort VM on too long VM operations Hi, I'd like to backport this change to jdk11u because it's a helpful feature to diagnose too long running VM operations. bug: https://bugs.openjdk.java.net/browse/JDK-8181143 original change: http://hg.openjdk.java.net/jdk/jdk/rev/c403f39ec349 jdk11u webrev: http://cr.openjdk.java.net/~mdoerr/8181143_AbortVMOnVMOperationTimeout/jdk11u/webrev.00/ I only had to insert the #include "runtime/task.hpp" manually into vmThread.hpp because the succeeding include was changed in jdk12. Note that this change needs to get backported together with JDK-8215374 which is a simply fix for the original change which applies cleanly. Please review. Best regards, Martin From jesper.wilhelmsson at oracle.com Thu May 9 22:06:35 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 10 May 2019 00:06:35 +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 25 Apr 2019, at 18:56, Aleksey Shipilev wrote: > > 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. I agree that using the -interest suffix would better describe the intent, and if possible I would suggest that we continue to use that standard instead of creating a new one that is less informative. I'd be happy to help bulk-update issues with redhat-openjdk to redhat-interest if needed. There are 374 in total. azul-openjdk has only been used on five issues so far so that should not be a problem to change. Thanks, /Jesper > > -Aleksey > From christoph.langer at sap.com Fri May 10 09:36:07 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 10 May 2019 09:36:07 +0000 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: Hi Steve > Is there anything else I need to do in order to get these back-ports > merged. If so, please let me know. In case you haven't seen yet: I have already pushed the backports for 11 and 12 yesterday. jdk8 I would leave for Andrew. Best regards Christoph From christoph.langer at sap.com Fri May 10 09:40:43 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 10 May 2019 09:40:43 +0000 Subject: How long is the jdk12u repo still open for fixes for 12.0.2? Message-ID: Hi jdk12u maintainers, I can see that still fix requests for jdk12u are approved and when pushed, they target to 12.0.2. My question: How long will jdk12u still collect fixes for 12.0.2? In the Wiki [0] I can read that RDP2 is late April which has already passed. And I assumed that that's the cutoff date after which pushes to jdk12u won't go directly into 12.0.2 any longer? Thanks Christoph [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK12u From rob.mckenna at oracle.com Fri May 10 14:26:08 2019 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Fri, 10 May 2019 15:26:08 +0100 Subject: How long is the jdk12u repo still open for fixes for 12.0.2? In-Reply-To: References: Message-ID: <20190510142608.GA12014@vimes> Hi Christoph, Given the short lifecycle of 12, we're doing our best to get as many of the requests in as possible. As such jdk12u-fix-requests are treated as critical requests. Any fix that won't be accepted for 12.0.2 will not be approved until the fixVersion on the repo changes. There is no hard and fast cutoff date for these requests, but I would expect to stop accepting them within the next couple of weeks. (at that point I'll change the hgupdater version on jdk12u. -Rob On 10/05/19 09:40, Langer, Christoph wrote: > Hi jdk12u maintainers, > > I can see that still fix requests for jdk12u are approved and when pushed, they target to 12.0.2. My question: How long will jdk12u still collect fixes for 12.0.2? > > In the Wiki [0] I can read that RDP2 is late April which has already passed. And I assumed that that's the cutoff date after which pushes to jdk12u won't go directly into 12.0.2 any longer? > > Thanks > Christoph > > [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK12u > > > From christoph.langer at sap.com Fri May 10 14:31:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 10 May 2019 14:31:46 +0000 Subject: How long is the jdk12u repo still open for fixes for 12.0.2? In-Reply-To: <20190510142608.GA12014@vimes> References: <20190510142608.GA12014@vimes> Message-ID: Hi Rob, thanks for clarifying. And I think this process is really good for JDK12 updates (as opposed to having to bring things in first and then use the critical label)?? Maybe you can announce on the mailing list when accepting fixes for 12.0.2 is finally stopped. /Christoph > -----Original Message----- > From: rob.mckenna at oracle.com > Sent: Freitag, 10. Mai 2019 16:26 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: How long is the jdk12u repo still open for fixes for 12.0.2? > > Hi Christoph, > > Given the short lifecycle of 12, we're doing our best to get as many of > the requests in as possible. As such jdk12u-fix-requests are treated as > critical requests. Any fix that won't be accepted for 12.0.2 will not be > approved until the fixVersion on the repo changes. > > There is no hard and fast cutoff date for these requests, but I would > expect to stop accepting them within the next couple of weeks. (at that > point I'll change the hgupdater version on jdk12u. > > -Rob > > On 10/05/19 09:40, Langer, Christoph wrote: > > Hi jdk12u maintainers, > > > > I can see that still fix requests for jdk12u are approved and when pushed, > they target to 12.0.2. My question: How long will jdk12u still collect fixes for > 12.0.2? > > > > In the Wiki [0] I can read that RDP2 is late April which has already passed. > And I assumed that that's the cutoff date after which pushes to jdk12u won't > go directly into 12.0.2 any longer? > > > > Thanks > > Christoph > > > > [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK12u > > > > > > From yasuenag at gmail.com Mon May 13 10:19:25 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 13 May 2019 19:19:25 +0900 Subject: How to request multiple backport for 11u? Message-ID: Hi all, I want to backport changes in below: - JDK-8200613 - JDK-8215342 - JDK-8219414 - JDK-8219574 - JDK-8215026 They are very helpful for crash analysis. We can apply them straightly to 11u, but they need to apply them in same time. Risk is low because these changes affects only to coredump on Linux. They are covered with serviceability/sa tests. Can I request them with "jdk11u-fix-request" on JBS? Or should I create single backport RFR for them? Thanks, Yasumasa From shade at redhat.com Mon May 13 10:24:49 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 13 May 2019 12:24:49 +0200 Subject: How to request multiple backport for 11u? In-Reply-To: References: Message-ID: On 5/13/19 12:19 PM, Yasumasa Suenaga wrote: > Can I request them with "jdk11u-fix-request" on JBS? > Or should I create single backport RFR for them? Yes, you can request jdk11u-fix-request on them individually. Mention the dependencies in "Fix Request" comment. I would prefer to have 1:1 mapping between changesets, so if the change has 4 follow-up fixes, I'd prefer to have 1+4 changesets in backport. The onus is on you to *push* them together to avoid breakage. -Aleksey From yasuenag at gmail.com Mon May 13 10:48:29 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 13 May 2019 19:48:29 +0900 Subject: How to request multiple backport for 11u? In-Reply-To: References: Message-ID: Thanks Aleksey! I added fix request to all related issues. Yasumasa On 2019/05/13 19:24, Aleksey Shipilev wrote: > On 5/13/19 12:19 PM, Yasumasa Suenaga wrote: >> Can I request them with "jdk11u-fix-request" on JBS? >> Or should I create single backport RFR for them? > > Yes, you can request jdk11u-fix-request on them individually. Mention the dependencies in "Fix > Request" comment. I would prefer to have 1:1 mapping between changesets, so if the change has 4 > follow-up fixes, I'd prefer to have 1+4 changesets in backport. The onus is on you to *push* them > together to avoid breakage. > > -Aleksey > From mbalao at redhat.com Mon May 13 16:27:17 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 13 May 2019 13:27:17 -0300 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: Message-ID: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> Hi Goetz, Thanks for raising this issue. I'm not surprised by MaxAdvanceIsMax test failing on some OS. The reason is that this test is very OS specific. All installed fonts are tested and a static value from each font is used for the assertion, after scale calculations. If there is a difference between what the font creator set when generating the font file and what the OS rendering library returns -considering that different FreeType library builds may return different values-, this test will fail. The internal test during development phase was more reliable because it tested a known-font only. However, shipping a font is not allowed by licenses and that's why we changed the test a bit. We should probably limit the scope somehow. Despite the test failure, I'm still confident that we did the right thing in 8218854 [1]. Kind regards, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8218854 From goetz.lindenmaier at sap.com Mon May 13 16:38:28 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 May 2019 16:38:28 +0000 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> References: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> Message-ID: Hi Martin, Thanks for explaining the issue to me, that sounds reasonable. Can I somehow verify that it's the font that has the problem? Can I fix the font so that the test passes? Best regards, Goetz. > -----Original Message----- > From: Martin Balao > Sent: Montag, 13. Mai 2019 18:27 > To: Lindenmaier, Goetz ; 'Severin Gehwolf' > ; Langer, Christoph ; jdk- > updates-dev at openjdk.java.net > Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net; Martin > Balao Alonso > Subject: Re: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure > (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) > > Hi Goetz, > > Thanks for raising this issue. > > I'm not surprised by MaxAdvanceIsMax test failing on some OS. The reason > is that this test is very OS specific. > > All installed fonts are tested and a static value from each font is used > for the assertion, after scale calculations. If there is a difference > between what the font creator set when generating the font file and what > the OS rendering library returns -considering that different FreeType > library builds may return different values-, this test will fail. > > The internal test during development phase was more reliable because it > tested a known-font only. However, shipping a font is not allowed by > licenses and that's why we changed the test a bit. > > We should probably limit the scope somehow. > > Despite the test failure, I'm still confident that we did the right > thing in 8218854 [1]. > > Kind regards, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8218854 From gnu.andrew at redhat.com Mon May 13 17:07:58 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 13 May 2019 18:07:58 +0100 Subject: How to request multiple backport for 11u? In-Reply-To: References: Message-ID: <9784b1a8-f9c3-695f-eca7-ab878e8a914e@redhat.com> On 13/05/2019 11:24, Aleksey Shipilev wrote: > On 5/13/19 12:19 PM, Yasumasa Suenaga wrote: >> Can I request them with "jdk11u-fix-request" on JBS? >> Or should I create single backport RFR for them? > > Yes, you can request jdk11u-fix-request on them individually. Mention the dependencies in "Fix > Request" comment. I would prefer to have 1:1 mapping between changesets, so if the change has 4 > follow-up fixes, I'd prefer to have 1+4 changesets in backport. The onus is on you to *push* them > together to avoid breakage. > > -Aleksey > I agree. At the very least, each bug should return a result when 'hg log -k ' is used. In general, it is better to stick to small, minimal changesets as this makes it easier to pinpoint the changes that caused a particular problem at a later date. A little extra time now often pays off in the long run, and is also a courtesy to your fellow developers. -- 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 May 14 04:43:54 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 14 May 2019 13:43:54 +0900 Subject: [11u] RDR: backport JDK-8212677 Message-ID: Hello. I got jdk11u-fix-yes for following bug ids: JDK-8212677 X11 default visual support for IM status window on VNC [1] Changeset 9b93a6b30cbe [2] can be applied. But Copyright year was not changed by above changeset: I create new patch for 11u (I just changed Copyright year) Change: https://cr.openjdk.java.net/~itakiguchi/8212677/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212677 Line#s were changed because of the other patches. Please suggest me if I need to apply the other patches for prerequisite. I'd like to obtain a sponsor for JDK-8212677. [1] https://bugs.openjdk.java.net/browse/JDK-8212677 [2] http://hg.openjdk.java.net/jdk/jdk/rev/9b93a6b30cbe Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From shade at redhat.com Tue May 14 09:49:41 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 May 2019 11:49:41 +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 5/10/19 12:06 AM, jesper.wilhelmsson at oracle.com wrote: >> On 25 Apr 2019, at 18:56, Aleksey Shipilev wrote: >> 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. > > I agree that using the -interest suffix would better describe the intent, and if possible I would > suggest that we continue to use that standard instead of creating a new one that is less > informative. I'd be happy to help bulk-update issues with redhat-openjdk to redhat-interest if > needed. There are 374 in total. azul-openjdk has only been used on five issues so far so that > should not be a problem to change. Yeah, we are fine with bulk renaming "redhat-openjdk" to "redhat-interest". This would require tool adjustment here and there, but no serious process breakages are expected. If Jesper is willing to help us with that, that would be perfect! -Aleksey From shade at redhat.com Tue May 14 10:13:35 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 May 2019 12:13:35 +0200 Subject: [11u] RDR: backport JDK-8212677 In-Reply-To: References: Message-ID: Hi, On 5/14/19 6:43 AM, Ichiroh Takiguchi wrote: > I got jdk11u-fix-yes for following bug ids: > JDK-8212677 X11 default visual support for IM status window on VNC [1] I can help you to push. > Changeset 9b93a6b30cbe [2] can be applied. > > But Copyright year was not changed by above changeset: > I create new patch for 11u > (I just changed Copyright year) I don't understand. I took this upstream changeset and it applies cleanly to jdk11u-dev: http://hg.openjdk.java.net/jdk/jdk/rev/9b93a6b30cbe Why do you need the additional webrev? -Aleksey From takiguc at linux.vnet.ibm.com Tue May 14 11:24:19 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 14 May 2019 20:24:19 +0900 Subject: [11u] RDR: backport JDK-8212677 In-Reply-To: References: Message-ID: Hello Aleksey. Thank you for your confirmation. According to src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c Current copyright year is: "* Copyright (c) 1997, 2016, Oracle and/or its affiliates. All rights reserved." Another changeset '2d18e5ed0f8d' [1] changed from 2016 to 2018 by JDK-8213944 [2] But changeset e3cd6d9d43e2 for [3] JDK-8213944 was already pushed by JDK-8223829 [4] on today. I'm sorry, I checked jdk-11.0.4+2 tag's source code... So please just push changeset 9b93a6b30cbe [5] I appreciate your help and kindness. [1] http://hg.openjdk.java.net/jdk/jdk/rev/2d18e5ed0f8d [2] https://bugs.openjdk.java.net/browse/JDK-8213944 [3] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/e3cd6d9d43e2 [4] https://bugs.openjdk.java.net/browse/JDK-8223829 [5] http://hg.openjdk.java.net/jdk/jdk/rev/9b93a6b30cbe Thanks, Ichiroh Takiguchi On 2019-05-14 19:13, Aleksey Shipilev wrote: > Hi, > > On 5/14/19 6:43 AM, Ichiroh Takiguchi wrote: >> I got jdk11u-fix-yes for following bug ids: >> JDK-8212677 X11 default visual support for IM status window on VNC [1] > > I can help you to push. > >> Changeset 9b93a6b30cbe [2] can be applied. >> >> But Copyright year was not changed by above changeset: >> I create new patch for 11u >> (I just changed Copyright year) > > I don't understand. I took this upstream changeset and it applies > cleanly to jdk11u-dev: > http://hg.openjdk.java.net/jdk/jdk/rev/9b93a6b30cbe > > Why do you need the additional webrev? > > -Aleksey From goetz.lindenmaier at sap.com Tue May 14 14:41:36 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 May 2019 14:41:36 +0000 Subject: RFR: jdk11u-dev backport: 8221470: Print methods in exception messages in java-like Syntax. Message-ID: Hi, I would like to backport this change. The hunk adding the new function in symbol.cpp does not apply because the context changed: Method try_increment_refcount() in the context is not there in jdk11. Original jdk13 webrev & change http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature/03/ http://hg.openjdk.java.net/jdk/jdk/rev/532e88de77eb New jdk11u-dev webrev: http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature-jdk11/01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221470 Best regards, Goetz. From martin.doerr at sap.com Tue May 14 14:54:00 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 14 May 2019 14:54:00 +0000 Subject: RFR: jdk11u-dev backport: 8221470: Print methods in exception messages in java-like Syntax. In-Reply-To: References: Message-ID: Hi G?tz, right, the succeeding code has changed (symbol.cpp). Backport looks good. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev On Behalf Of Lindenmaier, Goetz Sent: Dienstag, 14. Mai 2019 16:42 To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: [CAUTION] RFR: jdk11u-dev backport: 8221470: Print methods in exception messages in java-like Syntax. Hi, I would like to backport this change. The hunk adding the new function in symbol.cpp does not apply because the context changed: Method try_increment_refcount() in the context is not there in jdk11. Original jdk13 webrev & change http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature/03/ http://hg.openjdk.java.net/jdk/jdk/rev/532e88de77eb New jdk11u-dev webrev: http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature-jdk11/01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221470 Best regards, Goetz. From goetz.lindenmaier at sap.com Tue May 14 14:56:48 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 May 2019 14:56:48 +0000 Subject: When to do a review for a downported change? Message-ID: Hi, Do we really need reviews if a backport does not apply for trivial reasons? I always do them, but it seems quite some overhead to me. I consider at least changes in the context of a hunk and changes in the copyright year as trivial. I just posted this: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-May/001139.html for such a trivial reason. Best regards, Goetz. From shade at redhat.com Tue May 14 15:02:50 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 May 2019 17:02:50 +0200 Subject: When to do a review for a downported change? In-Reply-To: References: Message-ID: <1f642250-2a46-4b02-ebc5-fcdc9b3870c8@redhat.com> On 5/14/19 4:56 PM, Lindenmaier, Goetz wrote: > Do we really need reviews if a backport does not apply > for trivial reasons? I always do them, but it seems quite some > overhead to me. > I consider at least changes in the context of a hunk and > changes in the copyright year as trivial. I would say trivial conflict resolutions in the comments (not affecting the semantics of the code/docs) can be done without additional review. Copyright year adjustments are the examples of this. Just say that in Fix Request. However, the changes that massage the backport to fit older APIs need to be reviewed for sanity. The internal APIs are not overly consistent at times, and the thing that you might think is a trivial substitution might just not be so. Another pair of eyes to look at that addon is good to have. Aside, I think it is a good style (though optional) to post the diff between the upstream patch and the backport -- it seems low-overhead when there is the mq patch on top. This would also make reviews much easier, and probably fits the backporting workflow too. That is what I do anyway. -Aleksey From aph at redhat.com Tue May 14 15:52:54 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 May 2019 16:52:54 +0100 Subject: When to do a review for a downported change? In-Reply-To: <1f642250-2a46-4b02-ebc5-fcdc9b3870c8@redhat.com> References: <1f642250-2a46-4b02-ebc5-fcdc9b3870c8@redhat.com> Message-ID: <28cd659b-b6a1-d557-12e0-b004239d2d38@redhat.com> On 5/14/19 4:02 PM, Aleksey Shipilev wrote: > On 5/14/19 4:56 PM, Lindenmaier, Goetz wrote: >> Do we really need reviews if a backport does not apply >> for trivial reasons? I always do them, but it seems quite some >> overhead to me. >> I consider at least changes in the context of a hunk and >> changes in the copyright year as trivial. > > I would say trivial conflict resolutions in the comments (not > affecting the semantics of the code/docs) can be done without > additional review. Copyright year adjustments are the examples of > this. Just say that in Fix Request. > > However, the changes that massage the backport to fit older APIs > need to be reviewed for sanity. The internal APIs are not overly > consistent at times, and the thing that you might think is a trivial > substitution might just not be so. Another pair of eyes to look at > that addon is good to have. +1 > Aside, I think it is a good style (though optional) to post the diff > between the upstream patch and the backport -- it seems low-overhead > when there is the mq patch on top. This would also make reviews much > easier, and probably fits the backporting workflow too. That is what > I do anyway. Post in what format, though? A diff of a diff? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Tue May 14 16:22:05 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 May 2019 18:22:05 +0200 Subject: When to do a review for a downported change? In-Reply-To: <28cd659b-b6a1-d557-12e0-b004239d2d38@redhat.com> References: <1f642250-2a46-4b02-ebc5-fcdc9b3870c8@redhat.com> <28cd659b-b6a1-d557-12e0-b004239d2d38@redhat.com> Message-ID: On 5/14/19 5:52 PM, Andrew Haley wrote: > On 5/14/19 4:02 PM, Aleksey Shipilev wrote: >> Aside, I think it is a good style (though optional) to post the diff >> between the upstream patch and the backport -- it seems low-overhead >> when there is the mq patch on top. This would also make reviews much >> easier, and probably fits the backporting workflow too. That is what >> I do anyway. > > Post in what format, though? A diff of a diff? Depends. Whatever fits the workflow, and maybe with workflow adjustments: a) Sometimes just copy-paste *.rej and explain why those are not applicable. b) Sometimes just inline the "addon" patches that fix the original change: in my workflow with mq there are two patches: the original "backport" change with rejects, and the follow up patch that resolves those rejects, hg qdiff the second one and paste it. c) Sometimes just the copy-pasted affected block "before" / "after", showing the adjustment made; d) Sometimes just the diff of a diff is enough to highlight the changes. If that is not available, I would do that during review for a non-trivial backport _anyway_. e) Sometimes just pointing out which files and methods have differences vs upstream version, so we can eyeball them. I mean, anything that _you_ as reviewer, who sees the backport for the first time, would like to see in order to understand what was done, quickly and exactly. If backport differences are indeed trivial, then any of the ways above would amount to a copy-pasted paragraph in RFR, and it would breeze through the review, making the whole thing low-overhead. (This is not to say people here are not doing that. Just describing "the common sense" out loud.) -Aleksey From mbalao at redhat.com Tue May 14 16:41:00 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 14 May 2019 13:41:00 -0300 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> Message-ID: Hi Goetz, On 5/13/19 1:38 PM, Lindenmaier, Goetz wrote: > > Can I somehow verify that it's the font that has the problem? > Can I fix the font so that the test passes? > I cannot say whether or not the static max advance value in each font is right or not, but let's assume it is. The underlying problem here is that OpenJDK uses a couple of internal FreeType library values to calculate the effects of algorithmic bold and italic in the max advance value -"algorithmic" means that the font is not italic or bold and is up to the rendering engine to generate the desired effect-. These values have changed over the years. What we did in 8218854 [1] was updating the italic value to the latest version and supporting bold in the calculation. Ideally, OpenJDK should not be tight to these values. However, that's not easy to get rid of unless we change the API or the API semantics. All this means that if you use OpenJDK 11 with an old Free Type library, you may have different values and the test may fail. Note: this is just an hypothesis, I couldn't reproduce on my own. I believe the test assertion is right if we consider API semantics only but we can put some constraints given reality. Kind regards, Martin.- -- [1] - http://hg.openjdk.java.net/jdk/jdk/rev/0804f29e8be7 From goetz.lindenmaier at sap.com Wed May 15 05:37:03 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 15 May 2019 05:37:03 +0000 Subject: RFR: jdk11u-dev backport: 8221470: Print methods in exception messages in java-like Syntax. In-Reply-To: References: Message-ID: Thanks, Martin! Best regards, Goetz > -----Original Message----- > From: Doerr, Martin > Sent: Tuesday, May 14, 2019 4:54 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: RE: RFR: jdk11u-dev backport: 8221470: Print methods in exception > messages in java-like Syntax. > > Hi G?tz, > > right, the succeeding code has changed (symbol.cpp). Backport looks good. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 14. Mai 2019 16:42 > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: [CAUTION] RFR: jdk11u-dev backport: 8221470: Print methods in > exception messages in java-like Syntax. > > Hi, > > I would like to backport this change. > The hunk adding the new function in symbol.cpp > does not apply because the context changed: > Method try_increment_refcount() in the context is not > there in jdk11. > > Original jdk13 webrev & change > http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature/03/ > http://hg.openjdk.java.net/jdk/jdk/rev/532e88de77eb > New jdk11u-dev webrev: > http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature- > jdk11/01/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221470 > > Best regards, > Goetz. From christoph.langer at sap.com Wed May 15 06:53:50 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 15 May 2019 06:53:50 +0000 Subject: [11u]: RFR(S) Backport: 8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h Message-ID: Hi, please review this simple backport of a cleanup change for awt/X11. Unfortunately, the patch didn?t fully apply because of this hunk: --- XKeysym.java +++ XKeysym.java @@ -33,15 +44,6 @@ public class XKeysym { - public static void main( String[] args ) { - System.out.println( "Cyrillc zhe:"+convertKeysym(0x06d6, 0)); - System.out.println( "Arabic sheen:"+convertKeysym(0x05d4, 0)); - System.out.println( "Latin a breve:"+convertKeysym(0x01e3, 0)); - System.out.println( "Latin f:"+convertKeysym(0x066, 0)); - System.out.println( "Backspace:"+Integer.toHexString(convertKeysym(0xff08, 0))); - System.out.println( "Ctrl+f:"+Integer.toHexString(convertKeysym(0x066, XConstants.ControlMask))); - } - private XKeysym() {} static class Keysym2JavaKeycode { The signature of main had been changed by JDK-8211300 which isn?t downported. So I deleted the main method manually to resolve ?? Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213213.11u/ Original Bug: https://bugs.openjdk.java.net/browse/JDK-8213213 Thanks Christoph From goetz.lindenmaier at sap.com Wed May 15 07:11:13 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 15 May 2019 07:11:13 +0000 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> Message-ID: Hi Martin, Yesterday I filed 8223869: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java on more platforms as I found it is excluded on solaris and mac already. Thanks for the explanation. I will look at what freetype libs are used on the systems where this is failing. Maybe we should mark the test with @key intermittent if it depends on the system setup that much? Best regards, Goetz. > -----Original Message----- > From: Martin Balao > Sent: Tuesday, May 14, 2019 6:41 PM > To: Lindenmaier, Goetz ; 'Severin Gehwolf' > ; Langer, Christoph ; > jdk-updates-dev at openjdk.java.net > Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net; > Martin Balao Alonso > Subject: Re: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure > (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) > > Hi Goetz, > > On 5/13/19 1:38 PM, Lindenmaier, Goetz wrote: > > > > Can I somehow verify that it's the font that has the problem? > > Can I fix the font so that the test passes? > > > > I cannot say whether or not the static max advance value in each font is > right or not, but let's assume it is. The underlying problem here is > that OpenJDK uses a couple of internal FreeType library values to > calculate the effects of algorithmic bold and italic in the max advance > value -"algorithmic" means that the font is not italic or bold and is up > to the rendering engine to generate the desired effect-. These values > have changed over the years. What we did in 8218854 [1] was updating the > italic value to the latest version and supporting bold in the > calculation. Ideally, OpenJDK should not be tight to these values. > However, that's not easy to get rid of unless we change the API or the > API semantics. All this means that if you use OpenJDK 11 with an old > Free Type library, you may have different values and the test may fail. > > Note: this is just an hypothesis, I couldn't reproduce on my own. > > I believe the test assertion is right if we consider API semantics only > but we can put some constraints given reality. > > Kind regards, > Martin.- > > -- > [1] - http://hg.openjdk.java.net/jdk/jdk/rev/0804f29e8be7 > From goetz.lindenmaier at sap.com Wed May 15 07:16:13 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 15 May 2019 07:16:13 +0000 Subject: When to do a review for a downported change? In-Reply-To: References: <1f642250-2a46-4b02-ebc5-fcdc9b3870c8@redhat.com> <28cd659b-b6a1-d557-12e0-b004239d2d38@redhat.com> Message-ID: Hi, This all sounds well reasonable and I agree to it. To subsubme: - For pure hunk context changes and Copyright changes mention them in the "Fix Request" comment but don't send a downport RFR. - If only a smallish change is needed to resolve supply a diff or other appropriate format in the mail. Best regards, Goetz. > -----Original Message----- > From: Aleksey Shipilev > Sent: Tuesday, May 14, 2019 6:22 PM > To: Andrew Haley ; Lindenmaier, Goetz > ; jdk-updates-dev at openjdk.java.net > Subject: Re: When to do a review for a downported change? > > On 5/14/19 5:52 PM, Andrew Haley wrote: > > On 5/14/19 4:02 PM, Aleksey Shipilev wrote: > >> Aside, I think it is a good style (though optional) to post the diff > >> between the upstream patch and the backport -- it seems low-overhead > >> when there is the mq patch on top. This would also make reviews much > >> easier, and probably fits the backporting workflow too. That is what > >> I do anyway. > > > > Post in what format, though? A diff of a diff? > > Depends. Whatever fits the workflow, and maybe with workflow > adjustments: > a) Sometimes just copy-paste *.rej and explain why those are not applicable. > b) Sometimes just inline the "addon" patches that fix the original change: in > my workflow with mq > there are two patches: the original "backport" change with rejects, and the > follow up patch that > resolves those rejects, hg qdiff the second one and paste it. > c) Sometimes just the copy-pasted affected block "before" / "after", > showing the adjustment made; > d) Sometimes just the diff of a diff is enough to highlight the changes. If that > is not available, > I would do that during review for a non-trivial backport _anyway_. > e) Sometimes just pointing out which files and methods have differences vs > upstream version, so we > can eyeball them. > > I mean, anything that _you_ as reviewer, who sees the backport for the first > time, would like to see > in order to understand what was done, quickly and exactly. If backport > differences are indeed > trivial, then any of the ways above would amount to a copy-pasted > paragraph in RFR, and it would > breeze through the review, making the whole thing low-overhead. > > (This is not to say people here are not doing that. Just describing "the > common sense" out loud.) > > -Aleksey From shade at redhat.com Wed May 15 15:07:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 May 2019 17:07:36 +0200 Subject: [11u] RDR: backport JDK-8212677 In-Reply-To: References: Message-ID: <9a6d5da5-65dd-ac4a-64fd-3349cf491b80@redhat.com> On 5/14/19 1:24 PM, Ichiroh Takiguchi wrote: > Another changeset '2d18e5ed0f8d' [1] changed from 2016 to 2018 by JDK-8213944 [2] > But changeset e3cd6d9d43e2 for [3] JDK-8213944 was already pushed by JDK-8223829 [4] on today. > I'm sorry, I checked jdk-11.0.4+2 tag's source code... > > So please just push changeset 9b93a6b30cbe [5] Sorry for the delay, pushed: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/77b2c252913d -Aleksey From rob.mckenna at oracle.com Wed May 15 15:46:00 2019 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Wed, 15 May 2019 16:46:00 +0100 Subject: How long is the jdk12u repo still open for fixes for 12.0.2? In-Reply-To: References: <20190510142608.GA12014@vimes> Message-ID: <20190515154600.GB11526@vimes> Sorry for the delayed response. At this point I think we need to start being very careful what goes into the release. From Monday (20th) on, only serious regressions or showstoppers will be considered for approval. -Rob On 10/05/19 14:31, Langer, Christoph wrote: > Hi Rob, > > thanks for clarifying. And I think this process is really good for JDK12 updates (as opposed to having to bring things in first and then use the critical label)?? > > Maybe you can announce on the mailing list when accepting fixes for 12.0.2 is finally stopped. > > /Christoph > > > -----Original Message----- > > From: rob.mckenna at oracle.com > > Sent: Freitag, 10. Mai 2019 16:26 > > To: Langer, Christoph > > Cc: jdk-updates-dev at openjdk.java.net > > Subject: Re: How long is the jdk12u repo still open for fixes for 12.0.2? > > > > Hi Christoph, > > > > Given the short lifecycle of 12, we're doing our best to get as many of > > the requests in as possible. As such jdk12u-fix-requests are treated as > > critical requests. Any fix that won't be accepted for 12.0.2 will not be > > approved until the fixVersion on the repo changes. > > > > There is no hard and fast cutoff date for these requests, but I would > > expect to stop accepting them within the next couple of weeks. (at that > > point I'll change the hgupdater version on jdk12u. > > > > -Rob > > > > On 10/05/19 09:40, Langer, Christoph wrote: > > > Hi jdk12u maintainers, > > > > > > I can see that still fix requests for jdk12u are approved and when pushed, > > they target to 12.0.2. My question: How long will jdk12u still collect fixes for > > 12.0.2? > > > > > > In the Wiki [0] I can read that RDP2 is late April which has already passed. > > And I assumed that that's the cutoff date after which pushes to jdk12u won't > > go directly into 12.0.2 any longer? > > > > > > Thanks > > > Christoph > > > > > > [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK12u > > > > > > > > > From hohensee at amazon.com Wed May 15 15:46:11 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 15 May 2019 15:46:11 +0000 Subject: [11u]: RFR(S) Backport: 8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h In-Reply-To: References: Message-ID: <7EC26BFD-3848-40E0-BBFE-7725131E87B1@amazon.com> Looks good. Paul ?On 5/14/19, 11:54 PM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: Hi, please review this simple backport of a cleanup change for awt/X11. Unfortunately, the patch didn?t fully apply because of this hunk: --- XKeysym.java +++ XKeysym.java @@ -33,15 +44,6 @@ public class XKeysym { - public static void main( String[] args ) { - System.out.println( "Cyrillc zhe:"+convertKeysym(0x06d6, 0)); - System.out.println( "Arabic sheen:"+convertKeysym(0x05d4, 0)); - System.out.println( "Latin a breve:"+convertKeysym(0x01e3, 0)); - System.out.println( "Latin f:"+convertKeysym(0x066, 0)); - System.out.println( "Backspace:"+Integer.toHexString(convertKeysym(0xff08, 0))); - System.out.println( "Ctrl+f:"+Integer.toHexString(convertKeysym(0x066, XConstants.ControlMask))); - } - private XKeysym() {} static class Keysym2JavaKeycode { The signature of main had been changed by JDK-8211300 which isn?t downported. So I deleted the main method manually to resolve ?? Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213213.11u/ Original Bug: https://bugs.openjdk.java.net/browse/JDK-8213213 Thanks Christoph From gil at azul.com Wed May 15 18:49:55 2019 From: gil at azul.com (Gil Tene) Date: Wed, 15 May 2019 18:49:55 +0000 Subject: Mystery meat OpenJDK builds strike again Message-ID: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> Umm? Lumpy.local-43% docker run -it --rm openjdk:8 java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) Lumpy.local-44% date Wed May 15 11:41:12 PDT 2019 Look at the build number carefully? This was populated no later than March 27, 2019. 3 weeks before the actual 8u212 was released on April 16, 2019. Similarly: Lumpy.local-46% docker run -it --rm openjdk:11 java -version openjdk version "11.0.3" 2019-04-16 OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91) OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing) Lumpy.local-47% date Wed May 15 11:43:12 PDT 2019 This one was populate dno later than April 3, 2 weeks before the actual 11.0.3 was released on April 16, 2019 If anyone was wondering about the importance of having version strings say "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any and all OpenJDK builds that are not an actual release build, the above shows you how bad things get when that practice is not followed. Right now, anyone using the *Official* Docker images for OpenJDK 8 and 11 (https://hub.docker.com/_/openjdk) is probably thinking that they are running 8u212 or 11.0.3, when what they are actually running is an interim "work in progress build", with several bugs unaddressed, several updates missing, and (critically) CVE vulnerabilities that were fixed in the actual 8u212 and 11.0.3 un-addressed. The mechanics of how this situation came about seem to be: The docker file for openjdk:8 (https://github.com/docker-library/openjdk/blob/b8ce9eff38451de3282b2eb2bcd8b520fb95e1ce/8/jdk/Dockerfile ) was updated on March 27, 2019, 3 weeks before the actual release of OpenJDK 8u212 (see changes in https://github.com/docker-library/openjdk/commit/b8ce9eff38451de3282b2eb2bcd8b520fb95e1ce#diff-fef076ee1e5f270f2c5a93d075150919), and is set to use a specific Debian stretch build version (8u212-b01-1~deb9u1) that was available at that time, pulled via apt-get from debian stretch repos. Similarly, the docker file for openjdk:11 (https://github.com/docker-library/openjdk/blob/178c542fbb93a8f8a42e331b73a1214c9d8ba81d/11/jdk/Dockerfile) was updated on April 3, 2019, two weeks before the actual release of OpenJDK 11.0.3 (see changes in https://github.com/docker-library/openjdk/commit/178c542fbb93a8f8a42e331b73a1214c9d8ba81d#diff-c338262eaf0fd203322a06702be174e0), and set to use a specific Debian stretch build version (11.0.3+1-1~bpo9+1) also pulled via apt-get from debian stretch repos. Why Debian populated their repos with these builds is their business, and why docker chose to use those specific debian builds can be speculated about all we want. the details don't matter. The end result of these cumulative "reasonable" (according to some people) choices is that the default openjdk runs done by millions of people on docker right now are using "mystery meat", incomplete, and exposed builds while seeming to report (to the lay person) a Java version that would suggest a real 8u212 or 11.0.3 (which one would expect has the security vulnerabilities in the April update addressed, the bug fixes included, etc.). Making sure OpenJDK version string only show non-EA contents in actual release builds (which is the practice we had recently moved to for both 8u and 11u) will not necessarily prevent such unfortunate decision chains from getting interim builds to unsuspecting end users, but will at least (assuming no malice is involved and no manual removal of EA labels happens) make it clear to the end user that what they got is not an actual released version. ? Gil. From gnu.andrew at redhat.com Wed May 15 21:39:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 May 2019 22:39:46 +0100 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> Message-ID: On 15/05/2019 19:49, Gil Tene wrote: > Umm? > > Lumpy.local-43% docker run -it --rm openjdk:8 java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > Lumpy.local-44% date > Wed May 15 11:41:12 PDT 2019 > > Look at the build number carefully? This was populated no later > than March 27, 2019. 3 weeks before the actual 8u212 was released > on April 16, 2019. > > Similarly: > > Lumpy.local-46% docker run -it --rm openjdk:11 java -version > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91) > OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing) > Lumpy.local-47% date > Wed May 15 11:43:12 PDT 2019 > > This one was populate dno later than April 3, 2 weeks before > the actual 11.0.3 was released on April 16, 2019 > > If anyone was wondering about the importance of having version strings say > "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any > and all OpenJDK builds that are not an actual release build, the above shows > you how bad things get when that practice is not followed. > > Right now, anyone using the *Official* Docker images for OpenJDK 8 and 11 > (https://hub.docker.com/_/openjdk) is probably thinking that they are running > 8u212 or 11.0.3, when what they are actually running is an interim "work in > progress build", with several bugs unaddressed, several updates missing, > and (critically) CVE vulnerabilities that were fixed in the actual > 8u212 and 11.0.3 un-addressed. > > The mechanics of how this situation came about seem to be: > > The docker file for openjdk:8 (https://github.com/docker-library/openjdk/blob/b8ce9eff38451de3282b2eb2bcd8b520fb95e1ce/8/jdk/Dockerfile ) was updated on March 27, 2019, 3 weeks before the actual release of > OpenJDK 8u212 (see changes in https://github.com/docker-library/openjdk/commit/b8ce9eff38451de3282b2eb2bcd8b520fb95e1ce#diff-fef076ee1e5f270f2c5a93d075150919), and is set to use a specific > Debian stretch build version (8u212-b01-1~deb9u1) that was available > at that time, pulled via apt-get from debian stretch repos. > > Similarly, the docker file for openjdk:11 (https://github.com/docker-library/openjdk/blob/178c542fbb93a8f8a42e331b73a1214c9d8ba81d/11/jdk/Dockerfile) > was updated on April 3, 2019, two weeks before the actual release > of OpenJDK 11.0.3 (see changes in https://github.com/docker-library/openjdk/commit/178c542fbb93a8f8a42e331b73a1214c9d8ba81d#diff-c338262eaf0fd203322a06702be174e0), and set to use a specific > Debian stretch build version (11.0.3+1-1~bpo9+1) also pulled via apt-get > from debian stretch repos. > > Why Debian populated their repos with these builds is their business, and > why docker chose to use those specific debian builds can be speculated > about all we want. the details don't matter. The end result of these > cumulative "reasonable" (according to some people) choices is that the > default openjdk runs done by millions of people on docker right now are > using "mystery meat", incomplete, and exposed builds while seeming to > report (to the lay person) a Java version that would suggest a real 8u212 > or 11.0.3 (which one would expect has the security vulnerabilities in the > April update addressed, the bug fixes included, etc.). > > Making sure OpenJDK version string only show non-EA contents in actual > release builds (which is the practice we had recently moved to for both 8u > and 11u) will not necessarily prevent such unfortunate decision chains from > getting interim builds to unsuspecting end users, but will at least (assuming > no malice is involved and no manual removal of EA labels happens) make > it clear to the end user that what they got is not an actual released version. > > ? Gil. > > > > > Wouldn't this be better raised on the Debian mailing lists than here? The above is not the default output, so they are already overriding any defaults we might set. At least it does say it is 11.0.3+1, which can be compared to the official released version [0] [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.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 shade at redhat.com Wed May 15 21:44:48 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 May 2019 23:44:48 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> Message-ID: <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> On 5/15/19 11:39 PM, Andrew John Hughes wrote: > Wouldn't this be better raised on the Debian mailing lists than here? +1 Plus, who actually maintains the "official" Docker images for 8u and 11u? Github history for Dockerfiles points to no one I recognize from around OpenJDK. That seems to be part of the problem here: responsible people are not in the loop to get all the important memos. -Aleksey From gnu.andrew at redhat.com Wed May 15 21:45:23 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 May 2019 22:45:23 +0100 Subject: When to do a review for a downported change? In-Reply-To: References: <1f642250-2a46-4b02-ebc5-fcdc9b3870c8@redhat.com> <28cd659b-b6a1-d557-12e0-b004239d2d38@redhat.com> Message-ID: <24376b51-8149-e5da-7222-9e1e56474226@redhat.com> On 14/05/2019 17:22, Aleksey Shipilev wrote: > On 5/14/19 5:52 PM, Andrew Haley wrote: >> On 5/14/19 4:02 PM, Aleksey Shipilev wrote: >>> Aside, I think it is a good style (though optional) to post the diff >>> between the upstream patch and the backport -- it seems low-overhead >>> when there is the mq patch on top. This would also make reviews much >>> easier, and probably fits the backporting workflow too. That is what >>> I do anyway. >> >> Post in what format, though? A diff of a diff? > > Depends. Whatever fits the workflow, and maybe with workflow adjustments: > a) Sometimes just copy-paste *.rej and explain why those are not applicable. > b) Sometimes just inline the "addon" patches that fix the original change: in my workflow with mq > there are two patches: the original "backport" change with rejects, and the follow up patch that > resolves those rejects, hg qdiff the second one and paste it. > c) Sometimes just the copy-pasted affected block "before" / "after", showing the adjustment made; > d) Sometimes just the diff of a diff is enough to highlight the changes. If that is not available, > I would do that during review for a non-trivial backport _anyway_. > e) Sometimes just pointing out which files and methods have differences vs upstream version, so we > can eyeball them. > > I mean, anything that _you_ as reviewer, who sees the backport for the first time, would like to see > in order to understand what was done, quickly and exactly. If backport differences are indeed > trivial, then any of the ways above would amount to a copy-pasted paragraph in RFR, and it would > breeze through the review, making the whole thing low-overhead. > > (This is not to say people here are not doing that. Just describing "the common sense" out loud.) > > -Aleksey > Indeed. When reviewing backports (which I do for jdk8u-fix-request as well), I diff the original changeset against the webrev patch. Having that in a review e-mail would help. As to trivial changes, I'd lump copyright headers in with the filename shuffling as trivial stuff that doesn't warrant a review. It is worth noting though that copyright changes should only ever be applied when they move to a later year (e.g. patch says 2019, code is 2018, so changed to 2019). We shouldn't roll backwards (e.g. patch says 2018, code is 2019, so changed to 2018). -- 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 May 15 21:52:11 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 May 2019 22:52:11 +0100 Subject: [OpenJDK 2D-Dev] [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> Message-ID: <70e98e74-b65e-459b-633b-7da05de6a2d1@redhat.com> On 14/05/2019 17:41, Martin Balao wrote: > Hi Goetz, > > On 5/13/19 1:38 PM, Lindenmaier, Goetz wrote: >> >> Can I somehow verify that it's the font that has the problem? >> Can I fix the font so that the test passes? >> > > I cannot say whether or not the static max advance value in each font is > right or not, but let's assume it is. The underlying problem here is > that OpenJDK uses a couple of internal FreeType library values to > calculate the effects of algorithmic bold and italic in the max advance > value -"algorithmic" means that the font is not italic or bold and is up > to the rendering engine to generate the desired effect-. These values > have changed over the years. What we did in 8218854 [1] was updating the > italic value to the latest version and supporting bold in the > calculation. Ideally, OpenJDK should not be tight to these values. > However, that's not easy to get rid of unless we change the API or the > API semantics. All this means that if you use OpenJDK 11 with an old > Free Type library, you may have different values and the test may fail. > > Note: this is just an hypothesis, I couldn't reproduce on my own. > > I believe the test assertion is right if we consider API semantics only > but we can put some constraints given reality. > > Kind regards, > Martin.- > > -- > [1] - http://hg.openjdk.java.net/jdk/jdk/rev/0804f29e8be7 > > I think the important thing here is to ensure that the test passes with the FreeType library included in the OpenJDK sources (--with-freetype=system). It's unrealistic to test with every possible version of FreeType one could compile against. -- 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 jesper.wilhelmsson at oracle.com Thu May 16 01:42:08 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 16 May 2019 03:42:08 +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: <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> > On 14 May 2019, at 11:49, Aleksey Shipilev wrote: > > On 5/10/19 12:06 AM, jesper.wilhelmsson at oracle.com wrote: >>> On 25 Apr 2019, at 18:56, Aleksey Shipilev wrote: >>> 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. >> >> I agree that using the -interest suffix would better describe the intent, and if possible I would >> suggest that we continue to use that standard instead of creating a new one that is less >> informative. I'd be happy to help bulk-update issues with redhat-openjdk to redhat-interest if >> needed. There are 374 in total. azul-openjdk has only been used on five issues so far so that >> should not be a problem to change. > Yeah, we are fine with bulk renaming "redhat-openjdk" to "redhat-interest". This would require tool > adjustment here and there, but no serious process breakages are expected. If Jesper is willing to > help us with that, that would be perfect! I'll run the bulk update tomorrow unless you need to prepare something first. /Jesper From martijnverburg at gmail.com Thu May 16 02:31:28 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 16 May 2019 11:31:28 +0900 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> Message-ID: AdoptOpenJDK is working with the Docker folks to find out who is providing the 'official' openjdk builds there (we're also not sure who's currently providing that openjdk). We're also in some longer-term discussions with Debian folks about how they can better manage their builds (since they have a build from source policy). But yeah - it's really a concern for those two communities. Cheers, Martijn On Thu, 16 May 2019 at 06:45, Aleksey Shipilev wrote: > On 5/15/19 11:39 PM, Andrew John Hughes wrote: > > Wouldn't this be better raised on the Debian mailing lists than here? > > +1 > > Plus, who actually maintains the "official" Docker images for 8u and 11u? > Github history for > Dockerfiles points to no one I recognize from around OpenJDK. That seems > to be part of the problem > here: responsible people are not in the loop to get all the important > memos. > > -Aleksey > > From christoph.langer at sap.com Thu May 16 06:15:31 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 16 May 2019 06:15:31 +0000 Subject: How long is the jdk12u repo still open for fixes for 12.0.2? In-Reply-To: <20190515154600.GB11526@vimes> References: <20190510142608.GA12014@vimes> <20190515154600.GB11526@vimes> Message-ID: Thanks, Rob, for sending out this info. > -----Original Message----- > From: rob.mckenna at oracle.com > Sent: Mittwoch, 15. Mai 2019 17:46 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: How long is the jdk12u repo still open for fixes for 12.0.2? > > Sorry for the delayed response. > > At this point I think we need to start being very careful what goes into > the release. From Monday (20th) on, only serious regressions or > showstoppers will be considered for approval. > > -Rob > > On 10/05/19 14:31, Langer, Christoph wrote: > > Hi Rob, > > > > thanks for clarifying. And I think this process is really good for JDK12 > updates (as opposed to having to bring things in first and then use the critical > label)?? > > > > Maybe you can announce on the mailing list when accepting fixes for 12.0.2 > is finally stopped. > > > > /Christoph > > > > > -----Original Message----- > > > From: rob.mckenna at oracle.com > > > Sent: Freitag, 10. Mai 2019 16:26 > > > To: Langer, Christoph > > > Cc: jdk-updates-dev at openjdk.java.net > > > Subject: Re: How long is the jdk12u repo still open for fixes for 12.0.2? > > > > > > Hi Christoph, > > > > > > Given the short lifecycle of 12, we're doing our best to get as many of > > > the requests in as possible. As such jdk12u-fix-requests are treated as > > > critical requests. Any fix that won't be accepted for 12.0.2 will not be > > > approved until the fixVersion on the repo changes. > > > > > > There is no hard and fast cutoff date for these requests, but I would > > > expect to stop accepting them within the next couple of weeks. (at that > > > point I'll change the hgupdater version on jdk12u. > > > > > > -Rob > > > > > > On 10/05/19 09:40, Langer, Christoph wrote: > > > > Hi jdk12u maintainers, > > > > > > > > I can see that still fix requests for jdk12u are approved and when > pushed, > > > they target to 12.0.2. My question: How long will jdk12u still collect fixes > for > > > 12.0.2? > > > > > > > > In the Wiki [0] I can read that RDP2 is late April which has already > passed. > > > And I assumed that that's the cutoff date after which pushes to jdk12u > won't > > > go directly into 12.0.2 any longer? > > > > > > > > Thanks > > > > Christoph > > > > > > > > [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK12u > > > > > > > > > > > > From shade at redhat.com Thu May 16 07:46:35 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 May 2019 09:46:35 +0200 Subject: redhat-openjdk labels in JIRA In-Reply-To: <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> Message-ID: <95c197b2-a3a1-eeb1-c9c3-974256c1e278@redhat.com> On 5/16/19 3:42 AM, jesper.wilhelmsson at oracle.com wrote: >> On 14 May 2019, at 11:49, Aleksey Shipilev wrote: >> Yeah, we are fine with bulk renaming "redhat-openjdk" to "redhat-interest". This would require tool >> adjustment here and there, but no serious process breakages are expected. If Jesper is willing to >> help us with that, that would be perfect! > > I'll run the bulk update tomorrow unless you need to prepare something first. No, we don't have to prepare. Please run the bulk updater as you see fit. -Aleksey From goetz.lindenmaier at sap.com Thu May 16 09:55:33 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 May 2019 09:55:33 +0000 Subject: [OpenJDK 2D-Dev] [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: <70e98e74-b65e-459b-633b-7da05de6a2d1@redhat.com> References: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> <70e98e74-b65e-459b-633b-7da05de6a2d1@redhat.com> Message-ID: Hi, that's a good point. First, I will check whether the bundled freetype fixes the issue. Then, I can have a look how to adapt the test, some whitebox functionality maybe. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew John Hughes > Sent: Mittwoch, 15. Mai 2019 23:52 > To: 2d-dev at openjdk.java.net; 'jdk-updates-dev at openjdk.java.net' updates-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] [11u] > java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR > 8210782: Upgrade HarfBuzz to the latest 2.3.1) > > > > On 14/05/2019 17:41, Martin Balao wrote: > > Hi Goetz, > > > > On 5/13/19 1:38 PM, Lindenmaier, Goetz wrote: > >> > >> Can I somehow verify that it's the font that has the problem? > >> Can I fix the font so that the test passes? > >> > > > > I cannot say whether or not the static max advance value in each font is > > right or not, but let's assume it is. The underlying problem here is > > that OpenJDK uses a couple of internal FreeType library values to > > calculate the effects of algorithmic bold and italic in the max advance > > value -"algorithmic" means that the font is not italic or bold and is up > > to the rendering engine to generate the desired effect-. These values > > have changed over the years. What we did in 8218854 [1] was updating the > > italic value to the latest version and supporting bold in the > > calculation. Ideally, OpenJDK should not be tight to these values. > > However, that's not easy to get rid of unless we change the API or the > > API semantics. All this means that if you use OpenJDK 11 with an old > > Free Type library, you may have different values and the test may fail. > > > > Note: this is just an hypothesis, I couldn't reproduce on my own. > > > > I believe the test assertion is right if we consider API semantics only > > but we can put some constraints given reality. > > > > Kind regards, > > Martin.- > > > > -- > > [1] - http://hg.openjdk.java.net/jdk/jdk/rev/0804f29e8be7 > > > > > > I think the important thing here is to ensure that the test passes with > the FreeType library included in the OpenJDK sources > (--with-freetype=system). It's unrealistic to test with every possible > version of FreeType one could compile against. > -- > 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 May 16 09:57:49 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 16 May 2019 09:57:49 +0000 Subject: JDK11/8 Updates: process, schedules and tagging Message-ID: Hi, after we had the discussion about the OpenJDK 8/11 release process and schedule [0], I?d like to explicitly spell out the current status and update the Wiki pages. It seems like we have agreed to a 3 phase model 1. Development 2. Rampdown (RDP2) 3. Freeze I?ve updated the timelines on the Wiki pages [1], [2] now accordingly. Please check/review. I would short-summarize our process like this: During development phase, changes go into the development repositories (jdk8u-dev/jdk11u-dev) and weekly tagging will be done in there. When the release repositories (jdk8u/jdk11u) aren?t blocked by rampdown/freeze of the previous release, the tags will be synced on a weekly basis to the release repositories. When rampdown of a release starts, merges from dev to release repositories are suspended and RDP2 approved changes have to be pushed to the release repositories. From that time merges happen from release->dev. After the freeze tag, no changes must go into the release repository while the CPU is assembled non publicly. After release, the CPU is merged back to the open repositories. Is that our common understanding? If I get no objections, I?ll update the process description pages [3] and [4] accordingly. I furthermore have 2 questions / things to clarify. a) Will we tag in the dev-repositories right from the start? E.g. will we start tagging 11.0.5 right after the 11.0.4 RDP2 integration from 11u-dev to 11u in the week after May 28? - I would suggest to do so. b) Will we also do a weekly tag when no changes happened after the previous tag? This should probably be a rare case given the current activities but we should have a guideline for that. - My feeling would be to skip the tag then. I can?t see any value in this. May I please have your feedback on that (especially from the Andrews ??) Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000996.html [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u [2] https://wiki.openjdk.java.net/display/jdk8u/Main [3] https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Description [4] https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description From aph at redhat.com Thu May 16 13:25:39 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 May 2019 14:25:39 +0100 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: References: Message-ID: On 5/16/19 10:57 AM, Langer, Christoph wrote: > > after we had the discussion about the OpenJDK 8/11 release process > and schedule [0], I?d like to explicitly spell out the current > status and update the Wiki pages. > > It seems like we have agreed to a 3 phase model > > 1. Development > > 2. Rampdown (RDP2) > > 3. Freeze Yes. > I?ve updated the timelines on the Wiki pages [1], [2] now > accordingly. Please check/review. > > > > I would short-summarize our process like this: > > During development phase, changes go into the development > repositories (jdk8u-dev/jdk11u-dev) and weekly tagging will be done > in there. When the release repositories (jdk8u/jdk11u) aren?t > blocked by rampdown/freeze of the previous release, the tags will be > synced on a weekly basis to the release repositories. When rampdown > of a release starts, merges from dev to release repositories are > suspended and RDP2 approved changes have to be pushed to the release > repositories. From that time merges happen from release->dev. After > the freeze tag, no changes must go into the release repository while > the CPU is assembled non publicly. After release, the CPU is merged > back to the open repositories. That sounds right, modulo last-minute critical patches. > Is that our common understanding? If I get no objections, I?ll > update the process description pages [3] and [4] accordingly. > > I furthermore have 2 questions / things to clarify. > > a) Will we tag in the dev-repositories right from the start? > E.g. will we start tagging 11.0.5 right after the 11.0.4 RDP2 > integration from 11u-dev to 11u in the week after May 28? > > - I would suggest to do so. We might as well: it simplifies the process. > b) Will we also do a weekly tag when no changes happened after the > previous tag? This should probably be a rare case given the current > activities but we should have a guideline for that. > > - My feeling would be to skip the tag then. I can?t see any > value in this. It doesn't matter. If the tag is done and there are no chages, there is no harm because that tag won't be used for any merges. If the tag is not done, there is no harm because that tag won't be used for any merges. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Thu May 16 13:48:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 May 2019 13:48:42 +0000 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: References: Message-ID: Hi, I appreciate what was proposed here. > > b) Will we also do a weekly tag when no changes happened after the > > previous tag? This should probably be a rare case given the current > > activities but we should have a guideline for that. > > > > - My feeling would be to skip the tag then. I can?t see any > > value in this. > > It doesn't matter. If the tag is done and there are no chages, there > is no harm because that tag won't be used for any merges. If the tag > is not done, there is no harm because that tag won't be used for any > merges. I see two problems with skipping tags: - You cannot predict when a tag will applied. You can not talk about the future mentioning tags if you skip them. - If you look at a repo, you can not easily tell at which sequence tags were applied. You need to look at the dates of changes. With regular weekly tags, going back 4 tags means going back 4 weeks. I.e., I think it's not essential, but makes life more easy if it's predictable. Also, Oracle does not skip them. See 11.0.2+2 and 11.0.2+3. http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/fa6e8935bbf2 http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8a8606a3bdf2 I think we should be similar here. Best regards, Goetz. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jesper.wilhelmsson at oracle.com Thu May 16 18:13:27 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 16 May 2019 20:13:27 +0200 Subject: redhat-openjdk labels in JIRA In-Reply-To: <95c197b2-a3a1-eeb1-c9c3-974256c1e278@redhat.com> References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> <95c197b2-a3a1-eeb1-c9c3-974256c1e278@redhat.com> Message-ID: <0CC88C1D-CAA8-4CBE-8F22-DD90CA90E700@oracle.com> The deed is done. Gil, do you want me to change the azul-openjdk labels as well? /Jesper > On 16 May 2019, at 09:46, Aleksey Shipilev wrote: > > On 5/16/19 3:42 AM, jesper.wilhelmsson at oracle.com wrote: >>> On 14 May 2019, at 11:49, Aleksey Shipilev wrote: >>> Yeah, we are fine with bulk renaming "redhat-openjdk" to "redhat-interest". This would require tool >>> adjustment here and there, but no serious process breakages are expected. If Jesper is willing to >>> help us with that, that would be perfect! >> >> I'll run the bulk update tomorrow unless you need to prepare something first. > > No, we don't have to prepare. Please run the bulk updater as you see fit. > > -Aleksey > From shade at redhat.com Thu May 16 18:25:02 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 May 2019 20:25:02 +0200 Subject: redhat-openjdk labels in JIRA In-Reply-To: <0CC88C1D-CAA8-4CBE-8F22-DD90CA90E700@oracle.com> References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> <95c197b2-a3a1-eeb1-c9c3-974256c1e278@redhat.com> <0CC88C1D-CAA8-4CBE-8F22-DD90CA90E700@oracle.com> Message-ID: <5f3a3e12-a144-3293-d5e6-95fa51e6ea74@redhat.com> On 5/16/19 8:13 PM, jesper.wilhelmsson at oracle.com wrote: > The deed is done. Thanks! Re-targeting our tools to use that new label now... -Aleksey From gnu.andrew at redhat.com Thu May 16 19:43:50 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 16 May 2019 20:43:50 +0100 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: References: Message-ID: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> On 16/05/2019 10:57, Langer, Christoph wrote: > Hi, > > ? > > after we had the discussion about the OpenJDK 8/11 release process and > schedule [0], I?d like to explicitly spell out the current status and > update the Wiki pages. > > ? > > It seems like we have agreed to a 3 phase model > > ? > > 1. Development > > 2. Rampdown (RDP2) > > 3. Freeze > > ? > > I?ve updated the timelines on the Wiki pages [1], [2] now accordingly. > Please check/review. > Thanks. I'll review the 8u page and check it matches the process I'm following. I do think "RDP2" should be avoided as there is no "RDP1". > ? > > I would short-summarize our process like this: > > During development phase, changes go into the development repositories > (jdk8u-dev/jdk11u-dev) and weekly tagging will be done in there. When > the release repositories (jdk8u/jdk11u) aren?t blocked by > rampdown/freeze of the previous release, the tags will be synced on a > weekly basis to the release repositories. When rampdown of a release > starts, merges from dev to release repositories are suspended and RDP2 > approved changes have to be pushed to the release repositories. From > that time merges happen from release->dev. After the freeze tag, no > changes must go into the release repository while the CPU is assembled > non publicly. After release, the CPU is merged back to the open > repositories. Yes: Dev phase: dev tagged, dev->master Rampdown phase: master tagged, master->dev Freeze phase: no changes to master Release: CPU changes pushed to master, master->dev > > ? > > Is that our common understanding? If I get no objections, I?ll update > the process description pages [3] and [4] accordingly. > > ? > > I furthermore have 2 questions / things to clarify. > > ? > > a) Will we tag in the dev-repositories right from the start? E.g. will > we start tagging 11.0.5 right after the 11.0.4 RDP2 integration from > 11u-dev to 11u in the week after May 28? > > ??? - I would suggest to do so. We do tag that point as -b00, I believe. If you mean do we start weekly tags of release x+1 in dev once release x is in rampdown, then no, I don't plan to for 8u. If you have the cycles to do so for 11, you can, but I need that time - particularly the freeze period - to prepare, build and test the imminent releases. Also, I don't really see the point when there is nowhere to promote the build to, as master is still on release x. That does mean that b01 will run over a longer period than other tags, but I don't see that as a particular problem. > > b) Will we also do a weekly tag when no changes happened after the > previous tag? This should probably be a rare case given the current > activities but we should have a guideline for that. > > ??? - My feeling would be to skip the tag then. I can?t see any value in > this. > I agree with skipping such empty tags, with an appropriate list announcement. I think the predictability argument is already lost in the final stages where we may have to add multiple tags in secret during the addition of the security patches. On the other hand, tagging periods with no changes introduces the possibility of a lot of needless work testing unchanged sources. I think it's easier to convey the message that a tag is being skipped - which someone who notices the lack of a new tag may look for - than it is to tag and have unknown users downstream building and testing something with no changes. The problem with comparing with Oracle processes is that their process is largely internal and so there are not the same potential communication issues. I think this is unlikely during the development stage, but more likely during the rampdown if nothing is critical enough to be included in the imminent release. My answer to both questions is concerned more with the reality of the workload involved than pointlessly sticking to an agreed protocol, when our limited resources could be better utilised. > ? > > May I please have your feedback on that (especially from the Andrews ??) > > ? > > Thanks > > Christoph > > ? > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000996.html > > [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > [2] https://wiki.openjdk.java.net/display/jdk8u/Main > > [3] > https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Description > > > [4] https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description > > ? > 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 Fri May 17 08:04:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 May 2019 08:04:42 +0000 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> References: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> Message-ID: Hi, > I do think "RDP2" should be avoided as there is no "RDP1". I understand you don't want the OpenJDK RDP terms. So let's use the term Rampdown. Could you please propose some wording to describe which changes are acceptable during rampdown? I will do the weekly tags on 11. Best regards, Goetz. > > I would short-summarize our process like this: > > > > During development phase, changes go into the development repositories > > (jdk8u-dev/jdk11u-dev) and weekly tagging will be done in there. When > > the release repositories (jdk8u/jdk11u) aren?t blocked by > > rampdown/freeze of the previous release, the tags will be synced on a > > weekly basis to the release repositories. When rampdown of a release > > starts, merges from dev to release repositories are suspended and RDP2 > > approved changes have to be pushed to the release repositories. From > > that time merges happen from release->dev. After the freeze tag, no > > changes must go into the release repository while the CPU is assembled > > non publicly. After release, the CPU is merged back to the open > > repositories. > > Yes: > > Dev phase: dev tagged, dev->master > Rampdown phase: master tagged, master->dev > Freeze phase: no changes to master > Release: CPU changes pushed to master, master->dev > > > > > > > > > Is that our common understanding? If I get no objections, I?ll update > > the process description pages [3] and [4] accordingly. > > > > > > > > I furthermore have 2 questions / things to clarify. > > > > > > > > a) Will we tag in the dev-repositories right from the start? E.g. will > > we start tagging 11.0.5 right after the 11.0.4 RDP2 integration from > > 11u-dev to 11u in the week after May 28? > > > > ??? - I would suggest to do so. > > We do tag that point as -b00, I believe. > > If you mean do we start weekly tags of release x+1 in dev once release x > is in rampdown, then no, I don't plan to for 8u. If you have the cycles > to do so for 11, you can, but I need that time - particularly the freeze > period - to prepare, build and test the imminent releases. > > Also, I don't really see the point when there is nowhere to promote the > build to, as master is still on release x. > > That does mean that b01 will run over a longer period than other tags, > but I don't see that as a particular problem. > > > > > b) Will we also do a weekly tag when no changes happened after the > > previous tag? This should probably be a rare case given the current > > activities but we should have a guideline for that. > > > > ??? - My feeling would be to skip the tag then. I can?t see any value in > > this. > > > > I agree with skipping such empty tags, with an appropriate list > announcement. > > I think the predictability argument is already lost in the final stages > where we may have to add multiple tags in secret during the addition of > the security patches. On the other hand, tagging periods with no changes > introduces the possibility of a lot of needless work testing unchanged > sources. > > I think it's easier to convey the message that a tag is being skipped - > which someone who notices the lack of a new tag may look for - than it > is to tag and have unknown users downstream building and testing > something with no changes. > > The problem with comparing with Oracle processes is that their process > is largely internal and so there are not the same potential > communication issues. > > I think this is unlikely during the development stage, but more likely > during the rampdown if nothing is critical enough to be included in the > imminent release. > > My answer to both questions is concerned more with the reality of the > workload involved than pointlessly sticking to an agreed protocol, when > our limited resources could be better utilised. > > > > > > > May I please have your feedback on that (especially from the Andrews ??) > > > > > > > > Thanks > > > > Christoph > > > > > > > > [0] > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/000996.html > > > > [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > > > [2] https://wiki.openjdk.java.net/display/jdk8u/Main > > > > [3] > > > https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Descripti > on > > > > > > [4] > https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description > > > > > > > > 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 aph at redhat.com Fri May 17 08:15:54 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 May 2019 09:15:54 +0100 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: References: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> Message-ID: On 5/17/19 9:04 AM, Lindenmaier, Goetz wrote: > Could you please propose some wording to describe which > changes are acceptable during rampdown? Hmm. OK, so we need some rough guidelines, but it'll be a judgment call. There was more traffic than I liked last time around, but on the other hand things seemed to work out pretty well. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Fri May 17 13:59:58 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 May 2019 13:59:58 +0000 Subject: RFR: jdk11u-dev backport: 8221470: Print methods in exception messages in java-like Syntax. In-Reply-To: References: Message-ID: Hi, I'm sorry, I need to request another review. While linuxx86_64 opt build works fine, includes are missing in some dbg builds, also the aix opt build failed. I needed to add this: --- a/src/hotspot/share/oops/symbol.cpp +++ b/src/hotspot/share/oops/symbol.cpp @@ -34,6 +34,7 @@ #include "oops/symbol.hpp" #include "runtime/atomic.hpp" #include "runtime/os.hpp" +#include "runtime/signature.hpp" Symbol::Symbol(const u1* name, int length, int refcount) { _refcount = refcount; New webrev: http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature-jdk11/02/ Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 14. Mai 2019 16:42 > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: [CAUTION] RFR: jdk11u-dev backport: 8221470: Print methods in > exception messages in java-like Syntax. > > Hi, > > I would like to backport this change. > The hunk adding the new function in symbol.cpp > does not apply because the context changed: > Method try_increment_refcount() in the context is not > there in jdk11. > > Original jdk13 webrev & change > http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature/03/ > http://hg.openjdk.java.net/jdk/jdk/rev/532e88de77eb > New jdk11u-dev webrev: > http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature-jdk11/01/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221470 > > Best regards, > Goetz. From gil at azul.com Fri May 17 14:53:32 2019 From: gil at azul.com (Gil Tene) Date: Fri, 17 May 2019 14:53:32 +0000 Subject: redhat-openjdk labels in JIRA In-Reply-To: <0CC88C1D-CAA8-4CBE-8F22-DD90CA90E700@oracle.com> References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> <95c197b2-a3a1-eeb1-c9c3-974256c1e278@redhat.com>, <0CC88C1D-CAA8-4CBE-8F22-DD90CA90E700@oracle.com> Message-ID: Yes. thanks! Sent from my iPad > On May 16, 2019, at 11:15 AM, "jesper.wilhelmsson at oracle.com" wrote: > > The deed is done. > > Gil, do you want me to change the azul-openjdk labels as well? > /Jesper > >> On 16 May 2019, at 09:46, Aleksey Shipilev wrote: >> >> On 5/16/19 3:42 AM, jesper.wilhelmsson at oracle.com wrote: >>>> On 14 May 2019, at 11:49, Aleksey Shipilev wrote: >>>> Yeah, we are fine with bulk renaming "redhat-openjdk" to "redhat-interest". This would require tool >>>> adjustment here and there, but no serious process breakages are expected. If Jesper is willing to >>>> help us with that, that would be perfect! >>> >>> I'll run the bulk update tomorrow unless you need to prepare something first. >> >> No, we don't have to prepare. Please run the bulk updater as you see fit. >> >> -Aleksey >> > From martin.doerr at sap.com Fri May 17 14:55:23 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 17 May 2019 14:55:23 +0000 Subject: RFR: jdk11u-dev backport: 8221470: Print methods in exception messages in java-like Syntax. In-Reply-To: References: Message-ID: Hi G?tz, thanks for fixing it. Backport looks good. I think it's nice if jdk11 uses can get the better readable syntax, too. Maybe other reviewers have an opinion on this, too. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev On Behalf Of Lindenmaier, Goetz Sent: Freitag, 17. Mai 2019 16:00 To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: [CAUTION] RE: RFR: jdk11u-dev backport: 8221470: Print methods in exception messages in java-like Syntax. Hi, I'm sorry, I need to request another review. While linuxx86_64 opt build works fine, includes are missing in some dbg builds, also the aix opt build failed. I needed to add this: --- a/src/hotspot/share/oops/symbol.cpp +++ b/src/hotspot/share/oops/symbol.cpp @@ -34,6 +34,7 @@ #include "oops/symbol.hpp" #include "runtime/atomic.hpp" #include "runtime/os.hpp" +#include "runtime/signature.hpp" Symbol::Symbol(const u1* name, int length, int refcount) { _refcount = refcount; New webrev: http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature-jdk11/02/ Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 14. Mai 2019 16:42 > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: [CAUTION] RFR: jdk11u-dev backport: 8221470: Print methods in > exception messages in java-like Syntax. > > Hi, > > I would like to backport this change. > The hunk adding the new function in symbol.cpp > does not apply because the context changed: > Method try_increment_refcount() in the context is not > there in jdk11. > > Original jdk13 webrev & change > http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature/03/ > http://hg.openjdk.java.net/jdk/jdk/rev/532e88de77eb > New jdk11u-dev webrev: > http://cr.openjdk.java.net/~goetz/wr19/8221470-exMsg-signature-jdk11/01/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221470 > > Best regards, > Goetz. From jesper.wilhelmsson at oracle.com Fri May 17 15:44:55 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 17 May 2019 17:44:55 +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> <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> <95c197b2-a3a1-eeb1-c9c3-974256c1e278@redhat.com> <0CC88C1D-CAA8-4CBE-8F22-DD90CA90E700@oracle.com> Message-ID: Done. /Jesper > On 17 May 2019, at 16:53, Gil Tene wrote: > > Yes. thanks! > > Sent from my iPad > >> On May 16, 2019, at 11:15 AM, "jesper.wilhelmsson at oracle.com" wrote: >> >> The deed is done. >> >> Gil, do you want me to change the azul-openjdk labels as well? >> /Jesper >> >>> On 16 May 2019, at 09:46, Aleksey Shipilev wrote: >>> >>> On 5/16/19 3:42 AM, jesper.wilhelmsson at oracle.com wrote: >>>>> On 14 May 2019, at 11:49, Aleksey Shipilev wrote: >>>>> Yeah, we are fine with bulk renaming "redhat-openjdk" to "redhat-interest". This would require tool >>>>> adjustment here and there, but no serious process breakages are expected. If Jesper is willing to >>>>> help us with that, that would be perfect! >>>> >>>> I'll run the bulk update tomorrow unless you need to prepare something first. >>> >>> No, we don't have to prepare. Please run the bulk updater as you see fit. >>> >>> -Aleksey >>> >> From mbalao at redhat.com Fri May 17 20:20:23 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 17 May 2019 17:20:23 -0300 Subject: [OpenJDK 2D-Dev] [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> <70e98e74-b65e-459b-633b-7da05de6a2d1@redhat.com> Message-ID: On 5/16/19 6:55 AM, Lindenmaier, Goetz wrote: > that's a good point. > First, I will check whether the bundled freetype fixes the issue. > Then, I can have a look how to adapt the test, some whitebox > functionality maybe. > Indeed, it's a good point the one Andrew brought. I've checked FT_GlyphSlot_Oblique and FT_GlyphSlot_Embolden internal values (in jdk11u/src/java.desktop/share/native/libfreetype/src/base/ftsynth.c) and look aligned to what 8218854 set in jdk11u/src/java.desktop/share/native/libfontmanager/freetypeScaler.c. The test still depends on the system installed fonts, but that would be easier to fix because we can assert on some fonts only (filtered by name). @Goetz: I couldn't reproduce here -with the fonts and FreeType binaries I have- but if, using the bundled FreeType library, you find a font file that is causing a failure, please send it to me so I can try to reproduce. From aph at redhat.com Sun May 19 16:44:45 2019 From: aph at redhat.com (Andrew Haley) Date: Sun, 19 May 2019 17:44:45 +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: <30cdeab6-98d8-ae27-22ec-d1df51e13959@redhat.com> On 5/3/19 2:15 PM, Lindenmaier, Goetz wrote: >> But otherwise, the intent here is for people to start aiming their >> work at the next release at rampdown. Patches being pushed to >> jdk11u should be rare. > I think we should use jdk11u only for rampdown. So patches pushed to > jdk11u should be limited and well restricted, but not necessarily > rare. But yes, definitely less than pushed to jdk11u-dev. I have to agree with Andrew here. We should minimize churn at rampdown: every patch and combination of patches risks undermining stability, and that's true even with apparently low-risk patches. There were a lot of patches pushed to jdk11 during rampdown last time around, and that isn't necessarily good. >> The master tree (jdk11u) is snapshots for people to test and integrate >> downstream, leading up to the final release. >No. The jdk11u is a repository used for rampdown so that development >can be continued in another repository, here jdk11u-dev. >It is not a convenience for testers, it is to allow parallel work with >two different intentions: development <--> stabilization. Both of these can be true: Andrew is talking about what 11u is, you are talking about what it is for. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Mon May 20 07:22:02 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 May 2019 07:22:02 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <30cdeab6-98d8-ae27-22ec-d1df51e13959@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <30cdeab6-98d8-ae27-22ec-d1df51e13959@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Haley > Sent: Sonntag, 19. Mai 2019 18:45 > To: Lindenmaier, Goetz ; Andrew John Hughes > ; Langer, Christoph > Cc: Severin Gehwolf ; 'jdk8u-dev at openjdk.java.net' > ; Aleksey Shipilev ; jdk- > updates-dev at openjdk.java.net > Subject: Re: [11u]: 8u222 & 11.0.4 release schedule > > On 5/3/19 2:15 PM, Lindenmaier, Goetz wrote: > > >> But otherwise, the intent here is for people to start aiming their > >> work at the next release at rampdown. Patches being pushed to > >> jdk11u should be rare. > > I think we should use jdk11u only for rampdown. So patches pushed to > > jdk11u should be limited and well restricted, but not necessarily > > rare. But yes, definitely less than pushed to jdk11u-dev. > > I have to agree with Andrew here. We should minimize churn at > rampdown: every patch and combination of patches risks undermining > stability, and that's true even with apparently low-risk > patches. There were a lot of patches pushed to jdk11 during rampdown > last time around, and that isn't necessarily good. Well, yes. Now as we do only 4 weeks of rampdown, we need to be much more careful about the changes than if we do 4 weeks RDP1 and 4 weeks RDP2. Best regards, Goetz. > >> The master tree (jdk11u) is snapshots for people to test and integrate > >> downstream, leading up to the final release. > >No. The jdk11u is a repository used for rampdown so that development > >can be continued in another repository, here jdk11u-dev. > >It is not a convenience for testers, it is to allow parallel work with > >two different intentions: development <--> stabilization. > > Both of these can be true: Andrew is talking about what 11u is, you > are talking about what it is for. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon May 20 08:52:38 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 May 2019 09:52:38 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: <0ff8f29b-b1cd-1150-7ab8-c251603ac03b@redhat.com> On 4/27/19 7:40 PM, Ismael Juma wrote: > This is great. Are there plans for macOS builds too? Not that I know of. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Mon May 20 09:02:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 May 2019 11:02:56 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> Message-ID: <27387e08-a6d5-d419-c7ca-ea37b9cd7c21@redhat.com> On 5/15/19 11:44 PM, Aleksey Shipilev wrote: > On 5/15/19 11:39 PM, Andrew John Hughes wrote: >> Wouldn't this be better raised on the Debian mailing lists than here? > > +1 I take it that no one did? Looking around archives yield no relevant hits. Maybe it is stashed in Debian bugtracker somewhere I cannot find. So, I just did this: https://lists.debian.org/debian-java/2019/05/msg00007.html -- Thanks, -Aleksey From sgehwolf at redhat.com Mon May 20 09:08:10 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 20 May 2019 11:08:10 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <27387e08-a6d5-d419-c7ca-ea37b9cd7c21@redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> <27387e08-a6d5-d419-c7ca-ea37b9cd7c21@redhat.com> Message-ID: <71bda8763fa18c64f933af129226a99bae0067bb.camel@redhat.com> On Mon, 2019-05-20 at 11:02 +0200, Aleksey Shipilev wrote: > On 5/15/19 11:44 PM, Aleksey Shipilev wrote: > > On 5/15/19 11:39 PM, Andrew John Hughes wrote: > > > Wouldn't this be better raised on the Debian mailing lists than here? > > > > +1 > > I take it that no one did? Looking around archives yield no relevant hits. Maybe it is stashed in > Debian bugtracker somewhere I cannot find. > > So, I just did this: > https://lists.debian.org/debian-java/2019/05/msg00007.html See also: https://github.com/docker-library/openjdk/issues/320 Thanks, Severin From aph at redhat.com Mon May 20 09:23:35 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 May 2019 10:23:35 +0100 Subject: RFR: jdk11u-dev backport: 8221470: Print methods in exception messages in java-like Syntax. In-Reply-To: References: Message-ID: <2cd97e52-3a23-c107-a22c-e62c05b3fff4@redhat.com> On 5/17/19 3:55 PM, Doerr, Martin wrote: > I think it's nice if jdk11 uses can get the better readable syntax, too. Maybe other reviewers have an opinion on this, too. I guess it's nice but it's also rather marginal for a backport. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Mon May 20 20:30:38 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 20 May 2019 20:30:38 +0000 Subject: redhat-openjdk labels in JIRA In-Reply-To: References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> <95c197b2-a3a1-eeb1-c9c3-974256c1e278@redhat.com> <0CC88C1D-CAA8-4CBE-8F22-DD90CA90E700@oracle.com> Message-ID: <1F71119B-868A-4064-B674-C2B36D6914BF@amazon.com> Amazon would like to get in on the fun too. May we have an amazon-interest label please? :) Thanks, Paul ?On 5/17/19, 8:45 AM, "jdk-updates-dev on behalf of jesper.wilhelmsson at oracle.com" wrote: Done. /Jesper > On 17 May 2019, at 16:53, Gil Tene wrote: > > Yes. thanks! > > Sent from my iPad > >> On May 16, 2019, at 11:15 AM, "jesper.wilhelmsson at oracle.com" wrote: >> >> The deed is done. >> >> Gil, do you want me to change the azul-openjdk labels as well? >> /Jesper >> >>> On 16 May 2019, at 09:46, Aleksey Shipilev wrote: >>> >>> On 5/16/19 3:42 AM, jesper.wilhelmsson at oracle.com wrote: >>>>> On 14 May 2019, at 11:49, Aleksey Shipilev wrote: >>>>> Yeah, we are fine with bulk renaming "redhat-openjdk" to "redhat-interest". This would require tool >>>>> adjustment here and there, but no serious process breakages are expected. If Jesper is willing to >>>>> help us with that, that would be perfect! >>>> >>>> I'll run the bulk update tomorrow unless you need to prepare something first. >>> >>> No, we don't have to prepare. Please run the bulk updater as you see fit. >>> >>> -Aleksey >>> >> From jesper.wilhelmsson at oracle.com Mon May 20 20:45:32 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 20 May 2019 22:45:32 +0200 Subject: redhat-openjdk labels in JIRA In-Reply-To: <1F71119B-868A-4064-B674-C2B36D6914BF@amazon.com> References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> <95c197b2-a3a1-eeb1-c9c3-974256c1e278@redhat.com> <0CC88C1D-CAA8-4CBE-8F22-DD90CA90E700@oracle.com> <1F71119B-868A-4064-B674-C2B36D6914BF@amazon.com> Message-ID: Of course :-) Just add it to some issues and it will be created automatically. /Jesper > On 20 May 2019, at 22:30, Hohensee, Paul wrote: > > Amazon would like to get in on the fun too. May we have an amazon-interest label please? :) > > Thanks, > > Paul > > ?On 5/17/19, 8:45 AM, "jdk-updates-dev on behalf of jesper.wilhelmsson at oracle.com" wrote: > > Done. > /Jesper > >> On 17 May 2019, at 16:53, Gil Tene wrote: >> >> Yes. thanks! >> >> Sent from my iPad >> >>> On May 16, 2019, at 11:15 AM, "jesper.wilhelmsson at oracle.com" wrote: >>> >>> The deed is done. >>> >>> Gil, do you want me to change the azul-openjdk labels as well? >>> /Jesper >>> >>>> On 16 May 2019, at 09:46, Aleksey Shipilev wrote: >>>> >>>> On 5/16/19 3:42 AM, jesper.wilhelmsson at oracle.com wrote: >>>>>> On 14 May 2019, at 11:49, Aleksey Shipilev wrote: >>>>>> Yeah, we are fine with bulk renaming "redhat-openjdk" to "redhat-interest". This would require tool >>>>>> adjustment here and there, but no serious process breakages are expected. If Jesper is willing to >>>>>> help us with that, that would be perfect! >>>>> >>>>> I'll run the bulk update tomorrow unless you need to prepare something first. >>>> >>>> No, we don't have to prepare. Please run the bulk updater as you see fit. >>>> >>>> -Aleksey >>>> >>> > > > From takiguc at linux.vnet.ibm.com Tue May 21 05:50:36 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 21 May 2019 14:50:36 +0900 Subject: [11u] RDR: backport JDK-8213232, JDK-8211826 and JDK-8212676 Message-ID: Hello. I got jdk11u-fix-yes for following bug ids: JDK-8213232 Unix/X11 setCompositionEnableNative issue [1] JDK-8211826 StringIndexOutOfBoundsException happens via GetStringUTFRegion() [2] JDK-8212676 AWT SystemColor setting on CDE [3] Changesets are: JDK-8213232 65297f60ba19 JDK-8211826 bcfedddcf4ce JDK-8212676 23ff4073267f For JDK-8212676, Copyright year was changed by JDK-8211300 [7]: As of "When to do a review for a downported change?" [8] discussion, Copyright year issue may not require code change... Just in case, I create new patch for 11u (I just changed Copyright year) Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.03/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 Please suggest me if I need to apply the other patches for prerequisite. I'd like to obtain a sponsor for JDK-8213232, JDK-8211826 and JDK-8212676. [1] https://bugs.openjdk.java.net/browse/JDK-8213232 [2] https://bugs.openjdk.java.net/browse/JDK-8211826 [3] https://bugs.openjdk.java.net/browse/JDK-8212676 [4] http://hg.openjdk.java.net/jdk/jdk/rev/65297f60ba19 [5] http://hg.openjdk.java.net/jdk/jdk/rev/bcfedddcf4ce [6] http://hg.openjdk.java.net/jdk/jdk/rev/23ff4073267f [7] https://bugs.openjdk.java.net/browse/JDK-8211300 [8] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-May/001141.html Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From christoph.langer at sap.com Tue May 21 06:23:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 21 May 2019 06:23:16 +0000 Subject: [11u] RDR: backport JDK-8213232, JDK-8211826 and JDK-8212676 In-Reply-To: References: Message-ID: Hi Ichiroh, Looks good. I'll take care of these and sponsor them. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ichiroh Takiguchi > Sent: Dienstag, 21. Mai 2019 07:51 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RDR: backport JDK-8213232, JDK-8211826 and JDK-8212676 > > Hello. > > I got jdk11u-fix-yes for following bug ids: > > JDK-8213232 Unix/X11 setCompositionEnableNative issue [1] > JDK-8211826 StringIndexOutOfBoundsException happens via > GetStringUTFRegion() [2] > JDK-8212676 AWT SystemColor setting on CDE [3] > > Changesets are: > JDK-8213232 65297f60ba19 > JDK-8211826 bcfedddcf4ce > JDK-8212676 23ff4073267f > > For JDK-8212676, Copyright year was changed by JDK-8211300 [7]: > As of "When to do a review for a downported change?" [8] discussion, > Copyright year issue may not require code change... > > Just in case, I create new patch for 11u > (I just changed Copyright year) > > Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.03/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 > > Please suggest me if I need to apply the other patches for prerequisite. > > I'd like to obtain a sponsor for JDK-8213232, JDK-8211826 and > JDK-8212676. > > [1] https://bugs.openjdk.java.net/browse/JDK-8213232 > [2] https://bugs.openjdk.java.net/browse/JDK-8211826 > [3] https://bugs.openjdk.java.net/browse/JDK-8212676 > [4] http://hg.openjdk.java.net/jdk/jdk/rev/65297f60ba19 > [5] http://hg.openjdk.java.net/jdk/jdk/rev/bcfedddcf4ce > [6] http://hg.openjdk.java.net/jdk/jdk/rev/23ff4073267f > [7] https://bugs.openjdk.java.net/browse/JDK-8211300 > [8] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > May/001141.html > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. From shade at redhat.com Tue May 21 07:39:35 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 May 2019 09:39:35 +0200 Subject: redhat-openjdk labels in JIRA In-Reply-To: <1F71119B-868A-4064-B674-C2B36D6914BF@amazon.com> References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> <95c197b2-a3a1-eeb1-c9c3-974256c1e278@redhat.com> <0CC88C1D-CAA8-4CBE-8F22-DD90CA90E700@oracle.com> <1F71119B-868A-4064-B674-C2B36D6914BF@amazon.com> Message-ID: <5d8e3e9c-50e8-6ecf-bcf2-6e545e57868d@redhat.com> On 5/20/19 10:30 PM, Hohensee, Paul wrote: > Amazon would like to get in on the fun too. May we have an amazon-interest label please? :) Just put the tag on the issues, it would be created automatically. Instructed the backports-monitor to track those tags too. It is mostly RH-workflow-centric (i.e. handles downstream repositories RH is servicing), but might be useful for others too. https://builds.shipilev.net/backports-monitor/label-actionable-amazon-interest.txt https://builds.shipilev.net/backports-monitor/label-actionable-azul-interest.txt https://builds.shipilev.net/backports-monitor/label-actionable-redhat-interest.txt -- Thanks, -Aleksey From sgehwolf at redhat.com Tue May 21 09:33:42 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 21 May 2019 11:33:42 +0200 Subject: [11u] RFR: 8224474: harfbuzz 2.3.1 code fails to compile with gcc 4.4.7 Message-ID: Hi, Could I please get a review for this JDK 11u only fix? harfbuzz has been upgraded to 2.3.1 between jdk-11.0.4+2 and jdk-11.0.4+3. Unfortunately, this breaks the JDK 11u build on CentOS/RHEL 6 with system GCC 4.4.7 which the upstream OpenJDK 11u builds machinery uses. The fix is rather trivial: Move GCC pragmas outside functions. webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8224474/01/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8224474 Testing: release/slowdebug builds on Linux x86_64 with gcc 4.4.7. fastdebug build on Linux x86_64 with gcc 8.3.1 Thoughts? Thanks, Severin From christoph.langer at sap.com Tue May 21 12:09:20 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 21 May 2019 12:09:20 +0000 Subject: [11u] RFR: 8224474: harfbuzz 2.3.1 code fails to compile with gcc 4.4.7 In-Reply-To: References: Message-ID: Hi Severin, looks good to me. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Severin Gehwolf > Sent: Dienstag, 21. Mai 2019 11:34 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8224474: harfbuzz 2.3.1 code fails to compile with gcc 4.4.7 > > Hi, > > Could I please get a review for this JDK 11u only fix? harfbuzz has > been upgraded to 2.3.1 between jdk-11.0.4+2 and jdk-11.0.4+3. > Unfortunately, this breaks the JDK 11u build on CentOS/RHEL 6 with > system GCC 4.4.7 which the upstream OpenJDK 11u builds machinery uses. > > The fix is rather trivial: Move GCC pragmas outside functions. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8224474/01/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8224474 > > Testing: release/slowdebug builds on Linux x86_64 with gcc 4.4.7. > fastdebug build on Linux x86_64 with gcc 8.3.1 > > Thoughts? > > Thanks, > Severin From aph at redhat.com Tue May 21 14:56:10 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 May 2019 15:56:10 +0100 Subject: [11u] RFR: 8224474: harfbuzz 2.3.1 code fails to compile with gcc 4.4.7 In-Reply-To: References: Message-ID: On 5/21/19 1:09 PM, Langer, Christoph wrote: > looks good to me. Yes: trivial fix, breaks build. Please push. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Tue May 21 18:20:54 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 21 May 2019 18:20:54 +0000 Subject: redhat-openjdk labels in JIRA In-Reply-To: References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> <95c197b2-a3a1-eeb1-c9c3-974256c1e278@redhat.com> <0CC88C1D-CAA8-4CBE-8F22-DD90CA90E700@oracle.com> <1F71119B-868A-4064-B674-C2B36D6914BF@amazon.com> Message-ID: Thanks, Jesper and Aleksey. :) ?On 5/20/19, 1:45 PM, "jesper.wilhelmsson at oracle.com" wrote: Of course :-) Just add it to some issues and it will be created automatically. /Jesper > On 20 May 2019, at 22:30, Hohensee, Paul wrote: > > Amazon would like to get in on the fun too. May we have an amazon-interest label please? :) > > Thanks, > > Paul > > ?On 5/17/19, 8:45 AM, "jdk-updates-dev on behalf of jesper.wilhelmsson at oracle.com" wrote: > > Done. > /Jesper > >> On 17 May 2019, at 16:53, Gil Tene wrote: >> >> Yes. thanks! >> >> Sent from my iPad >> >>> On May 16, 2019, at 11:15 AM, "jesper.wilhelmsson at oracle.com" wrote: >>> >>> The deed is done. >>> >>> Gil, do you want me to change the azul-openjdk labels as well? >>> /Jesper >>> >>>> On 16 May 2019, at 09:46, Aleksey Shipilev wrote: >>>> >>>> On 5/16/19 3:42 AM, jesper.wilhelmsson at oracle.com wrote: >>>>>> On 14 May 2019, at 11:49, Aleksey Shipilev wrote: >>>>>> Yeah, we are fine with bulk renaming "redhat-openjdk" to "redhat-interest". This would require tool >>>>>> adjustment here and there, but no serious process breakages are expected. If Jesper is willing to >>>>>> help us with that, that would be perfect! >>>>> >>>>> I'll run the bulk update tomorrow unless you need to prepare something first. >>>> >>>> No, we don't have to prepare. Please run the bulk updater as you see fit. >>>> >>>> -Aleksey >>>> >>> > > > From aph at redhat.com Wed May 22 09:15:38 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 May 2019 10:15:38 +0100 Subject: RFR: 8221610: Resurrect (legacy) JRE bundle target In-Reply-To: References: Message-ID: <02d89b5a-3b31-0d68-6dee-83c70452e666@redhat.com> On 3/29/19 11:18 AM, Langer, Christoph wrote: >> I'm curious who these "stakeholders" are and what they use these JRE >> bundle for? As you know, moving to a modular platform has blurred the >> historical distinction between what we knew as the JRE and JDK in the >> past. Are they concerned about disk space? > I think the requirement comes mostly from people that work with CloudFoundry buildpacks. Eventually I think they should be educated on how they can leverage jlink based images but currently they still pull JRE images. Most probably their main concern is image size. Can we get this done for 11, please? You have reviews and approval. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Wed May 22 09:31:20 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 22 May 2019 09:31:20 +0000 Subject: RFR: 8221610: Resurrect (legacy) JRE bundle target In-Reply-To: <02d89b5a-3b31-0d68-6dee-83c70452e666@redhat.com> References: <02d89b5a-3b31-0d68-6dee-83c70452e666@redhat.com> Message-ID: Hi Andrew, it has been pushed to 11.0.4 already a while ago: https://bugs.openjdk.java.net/browse/JDK-8222119 Is that what you mean? Best regards Christoph > -----Original Message----- > From: Andrew Haley > Sent: Mittwoch, 22. Mai 2019 11:16 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net; Schuenemann, Rene > > Subject: Re: RFR: 8221610: Resurrect (legacy) JRE bundle target > > On 3/29/19 11:18 AM, Langer, Christoph wrote: > >> I'm curious who these "stakeholders" are and what they use these JRE > >> bundle for? As you know, moving to a modular platform has blurred the > >> historical distinction between what we knew as the JRE and JDK in the > >> past. Are they concerned about disk space? > > I think the requirement comes mostly from people that work with > CloudFoundry buildpacks. Eventually I think they should be educated on how > they can leverage jlink based images but currently they still pull JRE images. > Most probably their main concern is image size. > > Can we get this done for 11, please? You have reviews and approval. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Thu May 23 14:54:17 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 May 2019 14:54:17 +0000 Subject: Reminder: jdk 11.0.4 rampdown starts Tuesday, May 28, 18:00 CET. Message-ID: Hi, I would like to remind everybody who is working on jdk 11 updates that Rampdown of 11.0.4 starts next Tuesday, May 28, at 18:00 CET. At that point in time the last merge from jdk11u-dev to jdk11u will take place. Please push all changes you want to get to 11.0.4 before that date. After that, changes for jdk11u must be requested with jdk11u-critical-request tags, and they need to be pushed directly to jdk11u. Also, please don't push to jdk11u-dev after this date until tag 11.0.5+0 arrived in the repo. This should happen soon after, though. Best regards, Goetz From christoph.langer at sap.com Fri May 24 07:52:13 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 24 May 2019 07:52:13 +0000 Subject: [11u] RFR (Backport): 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler Message-ID: Hi, I'd like to bring this fix down to jdk11 updates. Unfortunately, the webrev did not apply cleanly in the imports section of src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java, so I had to resolve this part manually. I also updated the copyright year. Please check. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.11u/ Thanks Christoph From takiguc at linux.vnet.ibm.com Fri May 24 12:48:26 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 24 May 2019 21:48:26 +0900 Subject: [11u] RDR: backport JDK-8211841, JDK-8213614, JDK-8211810 and JDK-8208996 Message-ID: <9e19d3d22ae2a16d0c1915a4ab939389@linux.vnet.ibm.com> Hello. I got jdk11u-fix-yes for following bug ids: JDK-8211841 [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix) [1] JDK-8213614 DnD operation change feature does not work with 64bit big endian CPU [2] JDK-8211810 X11 Time stamp data should be unsigned [3] JDK-8208996 X11 icon window color handing bug [4] Changesets are: JDK-8211841 6b37a7ba9b66 [5] JDK-8213614 5b91e69e1fd0 [6] JDK-8211810 edc729e2ee36 [7] JDK-8208996 5ade5b3a227e [8] I'd like to obtain a sponsor for JDK-8211841, JDK-8213614, JDK-8211810 and JDK-8208996. [1] https://bugs.openjdk.java.net/browse/JDK-8211841 [2] https://bugs.openjdk.java.net/browse/JDK-8213614 [3] https://bugs.openjdk.java.net/browse/JDK-8211810 [4] https://bugs.openjdk.java.net/browse/JDK-8208996 [5] http://hg.openjdk.java.net/jdk/jdk12/rev/6b37a7ba9b66 [6] http://hg.openjdk.java.net/jdk/jdk/rev/5b91e69e1fd0 [7] http://hg.openjdk.java.net/jdk/jdk/rev/edc729e2ee36 [8] http://hg.openjdk.java.net/jdk/jdk/rev/5ade5b3a227e Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From christoph.langer at sap.com Fri May 24 12:55:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 24 May 2019 12:55:27 +0000 Subject: [11u] RDR: backport JDK-8211841, JDK-8213614, JDK-8211810 and JDK-8208996 In-Reply-To: <9e19d3d22ae2a16d0c1915a4ab939389@linux.vnet.ibm.com> References: <9e19d3d22ae2a16d0c1915a4ab939389@linux.vnet.ibm.com> Message-ID: Hi Ichiroh, I'll sponsor them. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ichiroh Takiguchi > Sent: Freitag, 24. Mai 2019 14:48 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RDR: backport JDK-8211841, JDK-8213614, JDK-8211810 and > JDK-8208996 > > Hello. > > I got jdk11u-fix-yes for following bug ids: > > JDK-8211841 [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile > (aix) [1] > JDK-8213614 DnD operation change feature does not work with 64bit big > endian CPU [2] > JDK-8211810 X11 Time stamp data should be unsigned [3] > JDK-8208996 X11 icon window color handing bug [4] > > Changesets are: > JDK-8211841 6b37a7ba9b66 [5] > JDK-8213614 5b91e69e1fd0 [6] > JDK-8211810 edc729e2ee36 [7] > JDK-8208996 5ade5b3a227e [8] > > I'd like to obtain a sponsor for JDK-8211841, JDK-8213614, JDK-8211810 > and JDK-8208996. > > [1] https://bugs.openjdk.java.net/browse/JDK-8211841 > [2] https://bugs.openjdk.java.net/browse/JDK-8213614 > [3] https://bugs.openjdk.java.net/browse/JDK-8211810 > [4] https://bugs.openjdk.java.net/browse/JDK-8208996 > [5] http://hg.openjdk.java.net/jdk/jdk12/rev/6b37a7ba9b66 > [6] http://hg.openjdk.java.net/jdk/jdk/rev/5b91e69e1fd0 > [7] http://hg.openjdk.java.net/jdk/jdk/rev/edc729e2ee36 > [8] http://hg.openjdk.java.net/jdk/jdk/rev/5ade5b3a227e > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. From hohensee at amazon.com Fri May 24 16:41:52 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 24 May 2019 16:41:52 +0000 Subject: [11u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 Message-ID: <1D2BF80D-85BF-4A16-B5C4-01984B48CCB9@amazon.com> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8224765 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8224766 Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8210985 Original email thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 Requesting approval for the backport CSR as well as the backport itself. Since this is a backport, I?ve gone with the one-phase CSR approval process and finalized the CSR. Original patch applies cleanly to 11u. Thanks, Paul From hohensee at amazon.com Fri May 24 17:04:44 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 24 May 2019 17:04:44 +0000 Subject: [11u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: <1D2BF80D-85BF-4A16-B5C4-01984B48CCB9@amazon.com> References: <1D2BF80D-85BF-4A16-B5C4-01984B48CCB9@amazon.com> Message-ID: <44A82E47-193D-4DD9-90AE-5A13DC9E9BF6@amazon.com> Add Original CSR: https://bugs.openjdk.java.net/browse/JDK-8213577 ?On 5/24/19, 9:42 AM, "jdk-updates-dev on behalf of Hohensee, Paul" wrote: Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8224765 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8224766 Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8210985 Original email thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 Requesting approval for the backport CSR as well as the backport itself. Since this is a backport, I?ve gone with the one-phase CSR approval process and finalized the CSR. Original patch applies cleanly to 11u. Thanks, Paul From ali.ince at gmail.com Sat May 25 17:07:27 2019 From: ali.ince at gmail.com (Ali Ince) Date: Sat, 25 May 2019 18:07:27 +0100 Subject: Backport of 8217707 Message-ID: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> Hi All, I would like to request backport of this fix to 11u and 12u. Bug: https://bugs.openjdk.java.net/browse/JDK-8217707 Fix: http://hg.openjdk.java.net/jdk/jdk/rev/3a217bbdd3a2 The patch itself applies cleanly to both repos. Best regards, Ali From aph at redhat.com Sat May 25 19:20:23 2019 From: aph at redhat.com (Andrew Haley) Date: Sat, 25 May 2019 20:20:23 +0100 Subject: Backport of 8217707 In-Reply-To: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> References: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> Message-ID: <08cf03de-730c-1dd9-ef9a-4acc6841ef9d@redhat.com> On 5/25/19 6:07 PM, Ali Ince wrote: > Hi All, > > I would like to request backport of this fix to 11u and 12u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217707 > Fix: http://hg.openjdk.java.net/jdk/jdk/rev/3a217bbdd3a2 > > The patch itself applies cleanly to both repos. OK for 11, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Sun May 26 05:13:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 26 May 2019 15:13:11 +1000 Subject: Backport of 8217707 In-Reply-To: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> References: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> Message-ID: <5be722fa-7cbc-1ee9-3823-3694b02a63a4@oracle.com> Hi Ali, On 26/05/2019 3:07 am, Ali Ince wrote: > Hi All, > > I would like to request backport of this fix to 11u and 12u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217707 > Fix: http://hg.openjdk.java.net/jdk/jdk/rev/3a217bbdd3a2 > > The patch itself applies cleanly to both repos. Please follow the backport approval process described here: http://openjdk.java.net/projects/jdk-updates/approval.html Thanks, David ----- > Best regards, > > Ali > From aph at redhat.com Sun May 26 10:15:02 2019 From: aph at redhat.com (Andrew Haley) Date: Sun, 26 May 2019 11:15:02 +0100 Subject: Backport of 8217707 In-Reply-To: <5be722fa-7cbc-1ee9-3823-3694b02a63a4@oracle.com> References: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> <5be722fa-7cbc-1ee9-3823-3694b02a63a4@oracle.com> Message-ID: <94a25477-826e-0b94-bab7-881b2a9f5610@redhat.com> On 5/26/19 6:13 AM, David Holmes wrote: > > On 26/05/2019 3:07 am, Ali Ince wrote: >> >> I would like to request backport of this fix to 11u and 12u. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217707 >> Fix: http://hg.openjdk.java.net/jdk/jdk/rev/3a217bbdd3a2 >> >> The patch itself applies cleanly to both repos. > > Please follow the backport approval process described here: > > http://openjdk.java.net/projects/jdk-updates/approval.html In particular the "jdku-fix-request" tag. And quickly, please: we're nearly at rampdown for release. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ali.ince at gmail.com Sun May 26 12:36:07 2019 From: ali.ince at gmail.com (Ali Ince) Date: Sun, 26 May 2019 13:36:07 +0100 Subject: Backport of 8217707 In-Reply-To: <94a25477-826e-0b94-bab7-881b2a9f5610@redhat.com> References: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> <5be722fa-7cbc-1ee9-3823-3694b02a63a4@oracle.com> <94a25477-826e-0b94-bab7-881b2a9f5610@redhat.com> Message-ID: <5cea8839.1c69fb81.78491.b219@mx.google.com> Hi Andrew, David, If I get it right, the backport approval process requires me to have a JBS user, which currently I don?t. Would you mind adding corresponding fix-request tags for 11u and 12u for me, please? Meanwhile I?ll also start a formal JBS user request. And I?m also very sorry that in my initial e-mail, the underlying link for the bug was point a totally different entry, so the correct one is https://bugs.openjdk.java.net/browse/JDK-8217707. Thanks. Ali From: Andrew Haley Sent: 26 May 2019 11:15 To: Ali Ince; jdk-updates-dev at openjdk.java.net Subject: Re: Backport of 8217707 On 5/26/19 6:13 AM, David Holmes wrote: > > On 26/05/2019 3:07 am, Ali Ince wrote: >> >> I would like to request backport of this fix to 11u and 12u. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217707 >> Fix: http://hg.openjdk.java.net/jdk/jdk/rev/3a217bbdd3a2 >> >> The patch itself applies cleanly to both repos. > > Please follow the backport approval process described here: > > http://openjdk.java.net/projects/jdk-updates/approval.html In particular the "jdku-fix-request" tag. And quickly, please: we're nearly at rampdown for release. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sun May 26 15:26:51 2019 From: aph at redhat.com (Andrew Haley) Date: Sun, 26 May 2019 16:26:51 +0100 Subject: Backport of 8217707 In-Reply-To: <5cea8839.1c69fb81.78491.b219@mx.google.com> References: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> <5be722fa-7cbc-1ee9-3823-3694b02a63a4@oracle.com> <94a25477-826e-0b94-bab7-881b2a9f5610@redhat.com> <5cea8839.1c69fb81.78491.b219@mx.google.com> Message-ID: <53f49635-1729-41da-02e4-ccde75120e50@redhat.com> On 5/26/19 1:36 PM, Ali Ince wrote: > Would you mind adding corresponding fix-request tags for 11u and 12u for me, please? Done. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ali.ince at gmail.com Sun May 26 16:56:57 2019 From: ali.ince at gmail.com (=?utf-8?Q?Ali_=C4=B0nce?=) Date: Sun, 26 May 2019 17:56:57 +0100 Subject: Backport of 8217707 In-Reply-To: <53f49635-1729-41da-02e4-ccde75120e50@redhat.com> References: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> <5be722fa-7cbc-1ee9-3823-3694b02a63a4@oracle.com> <94a25477-826e-0b94-bab7-881b2a9f5610@redhat.com> <5cea8839.1c69fb81.78491.b219@mx.google.com> <53f49635-1729-41da-02e4-ccde75120e50@redhat.com> Message-ID: <3E1C822C-6C78-45B8-972B-69C905762EC3@gmail.com> Thanks Andrew. Ali > On 26 May 2019, at 16:26, Andrew Haley wrote: > >> On 5/26/19 1:36 PM, Ali Ince wrote: >> Would you mind adding corresponding fix-request tags for 11u and 12u for me, please? > > Done. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From doko at ubuntu.com Sun May 26 22:25:05 2019 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 27 May 2019 00:25:05 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> Message-ID: I am disappointed to see such trolling, bashing and telling fake news on a technical mailing list. Is this Azul's business model to promote their own binary builds? Such behavior propagates e.g. via twitter https://twitter.com/jroper/status/1130678379403857920 I'm starting the discussion about version numbers and release information in a new thread. I am neither involved with any Docker image nor with any Debian backport. Debian provides security support for its stable release (stretch, 9.x). openjdk-11 isn't part of any released Debian version. Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until the EOL of Ubuntu 16.04 LTS (around April 2021). Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the security pocket). There is no mystery meat, just security supported uploads for both Debian and Ubuntu. On 15.05.19 20:49, Gil Tene wrote: > Umm? > > Lumpy.local-43% docker run -it --rm openjdk:8 java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > Lumpy.local-44% date > Wed May 15 11:41:12 PDT 2019 > > Look at the build number carefully? This was populated no later > than March 27, 2019. 3 weeks before the actual 8u212 was released > on April 16, 2019. The Debian openjdk-8 source package is put together from the jdk8u, aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects. Certainly not ideal, however these packages can only be made if all the sources are available, or tagged. I am happy to see that the aarch64-port tries to keep up with the jdk8u project however this is a different story with the aarch32-port project: The project doesn't have *any* prerelease tags, plus the project updates it's release tags only months after the jdk8u releases. So blaming Debian for shipping what they are able to ship and Azul holding back source releases yourself? Ein Schelm wer B?ses dabei denkt ... > Similarly: > > Lumpy.local-46% docker run -it --rm openjdk:11 java -version > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91) > OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing) > Lumpy.local-47% date > Wed May 15 11:43:12 PDT 2019 > > This one was populate dno later than April 3, 2 weeks before > the actual 11.0.3 was released on April 16, 2019 > > If anyone was wondering about the importance of having version strings say > "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any > and all OpenJDK builds that are not an actual release build, the above shows > you how bad things get when that practice is not followed. Don't trust the label, just the content. I agree that the java community is much more label/version driven, however this is not a reason to discredit other sane builds. > Why Debian populated their repos with these builds is their business, and > why docker chose to use those specific debian builds can be speculated > about all we want. the details don't matter. The end result of these > cumulative "reasonable" (according to some people) choices is that the > default openjdk runs done by millions of people on docker right now are > using "mystery meat", incomplete, and exposed builds while seeming to > report (to the lay person) a Java version that would suggest a real 8u212 > or 11.0.3 (which one would expect has the security vulnerabilities in the > April update addressed, the bug fixes included, etc.). Again, I see this as an advertising or promotion email for the Azul binary builds. Fine, do so. Both please use marketing lists and not the OpenJDK technical lists. Matthias From gil at azul.com Sun May 26 23:41:07 2019 From: gil at azul.com (Gil Tene) Date: Sun, 26 May 2019 23:41:07 +0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com>, Message-ID: <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com> Seriously? You see factual reporting (directly documented and dated in the original posting) of the actual version numbers being used by official docker images, along with irrefutable proof that the packages used in those were built weeks before the respective OpenJDK 8u and 11u releases were complete, as ?fake news?? You think that alerting millions of unsuspecting people using exposed, insecure builds that falsely report their OpenJDK version (as one that includes e.g. critical security fixes) to the fact as ?marketing?? And you consider pleas to use responsibly built and tested OpenJDK builds, with no mention of any vendor name at all, ?trolling?? This (the specific things documented at the start of this thread) was absolutely Mystery Meat masquerading as an actual release OpenJDK. Facts are facts. Blaming the messager and trying to attribute commercial motives to the calling out of inconvenient truths is a way of dealing with reality. Sent from Gil's iPhone > On May 26, 2019, at 3:25 PM, Matthias Klose wrote: > > I am disappointed to see such trolling, bashing and telling fake news on a > technical mailing list. Is this Azul's business model to promote their own > binary builds? > > Such behavior propagates e.g. via twitter > https://twitter.com/jroper/status/1130678379403857920 > > I'm starting the discussion about version numbers and release information in a > new thread. > > I am neither involved with any Docker image nor with any Debian backport. > > Debian provides security support for its stable release (stretch, 9.x). > openjdk-11 isn't part of any released Debian version. > > Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is > committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until > the EOL of Ubuntu 16.04 LTS (around April 2021). > > Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update > to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the > security pocket). > > There is no mystery meat, just security supported uploads for both Debian and > Ubuntu. > >> On 15.05.19 20:49, Gil Tene wrote: >> Umm? >> >> Lumpy.local-43% docker run -it --rm openjdk:8 java -version >> openjdk version "1.8.0_212" >> OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) >> OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) >> Lumpy.local-44% date >> Wed May 15 11:41:12 PDT 2019 >> >> Look at the build number carefully? This was populated no later >> than March 27, 2019. 3 weeks before the actual 8u212 was released >> on April 16, 2019. > > The Debian openjdk-8 source package is put together from the jdk8u, > aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects. Certainly not > ideal, however these packages can only be made if all the sources are available, > or tagged. > > I am happy to see that the aarch64-port tries to keep up with the jdk8u project > however this is a different story with the aarch32-port project: The project > doesn't have *any* prerelease tags, plus the project updates it's release tags > only months after the jdk8u releases. So blaming Debian for shipping what they > are able to ship and Azul holding back source releases yourself? Ein Schelm > wer B?ses dabei denkt ... > >> Similarly: >> >> Lumpy.local-46% docker run -it --rm openjdk:11 java -version >> openjdk version "11.0.3" 2019-04-16 >> OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91) >> OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing) >> Lumpy.local-47% date >> Wed May 15 11:43:12 PDT 2019 >> >> This one was populate dno later than April 3, 2 weeks before >> the actual 11.0.3 was released on April 16, 2019 >> >> If anyone was wondering about the importance of having version strings say >> "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any >> and all OpenJDK builds that are not an actual release build, the above shows >> you how bad things get when that practice is not followed. > > Don't trust the label, just the content. I agree that the java community is > much more label/version driven, however this is not a reason to discredit other > sane builds. > >> Why Debian populated their repos with these builds is their business, and >> why docker chose to use those specific debian builds can be speculated >> about all we want. the details don't matter. The end result of these >> cumulative "reasonable" (according to some people) choices is that the >> default openjdk runs done by millions of people on docker right now are >> using "mystery meat", incomplete, and exposed builds while seeming to >> report (to the lay person) a Java version that would suggest a real 8u212 >> or 11.0.3 (which one would expect has the security vulnerabilities in the >> April update addressed, the bug fixes included, etc.). > > Again, I see this as an advertising or promotion email for the Azul binary > builds. Fine, do so. Both please use marketing lists and not the OpenJDK > technical lists. > > Matthias From gil at azul.com Mon May 27 01:24:58 2019 From: gil at azul.com (Gil Tene) Date: Mon, 27 May 2019 01:24:58 +0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> Message-ID: <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> > On May 26, 2019, at 3:25 PM, Matthias Klose wrote: > > I am disappointed to see such trolling, bashing and telling fake news on a > technical mailing list. Is this Azul's business model to promote their own > binary builds? > > Such behavior propagates e.g. via twitter > https://twitter.com/jroper/status/1130678379403857920 > > I'm starting the discussion about version numbers and release information in a > new thread. > > I am neither involved with any Docker image nor with any Debian backport. > > Debian provides security support for its stable release (stretch, 9.x). > openjdk-11 isn't part of any released Debian version. > > Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is > committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until > the EOL of Ubuntu 16.04 LTS (around April 2021). > > Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update > to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the > security pocket). > > There is no mystery meat, just security supported uploads for both Debian and > Ubuntu. With such an emphatic attack on the motives associated with the original posting on this thread, I tried to figure out what might lead someone to take that path. I can attribute one of few possible logic paths that may lead you to making the above argument: a) You never bothered to check any of the actual facts posted, and just assumed the original posting was fake news. b) You did check the facts, but read the output wrong (like most people in the world would have, since the scary details behind the specific 8u212 and 11.0.3 builds involved need some digging to figure out), and somehow assumed that the thing reporting e.g. 'openjdk version "1.8.0_212"' was a good (non-Mystery-Meat) build of the released version being reported. c) You know the facts, but want others to think someone else is wrong for pointing them out, and go about doing that by trying to associate as many negative motives as you can muster ("trolling", "bashing", "fake news", "marketing", "business model", "advertising", "promotion", all of which you had literally used in this one e-mail) to the factual posting at the top of this tread. d) You think the facts posted, even when true, do not amount to the associated builds deserving to be called Mystery Meat. So let's quickly dispense the first two possibilities: If the benefit of the doubt for not actually realizing the truth of the situation, and the accuracy of the contents of the original e-mail is deserved, and you wrongly called this stuff "fake news", go ahead and check on the facts and come back to us with a correction. But somehow (see below), I doubt that (a) or (b) explain your misrepresentation of facts in this e-mail. I doubt that the original e-mail in this thread could have been much more clear or specific in documenting the actual Mystery Meat situation in the wild on the date it was posted. Thankfully, the Official Docker openjdk images has since fixed their official builds to no longer present docker users with images containing faulty, Mystery Meat 8u212 and 11.0.3 OpenJDK versions. However, there seem to be plenty of people (you included, clearly, per this very e-mail) who are trying to argue that the builds themselves are not a problem, that it is the lack of education or understanding of the end-user that is responsible, etc. Many of these arguments have taken a deflection approach of e.g. focusing on OpenJDK 11, combined with something like "the good, stable, meant-for-actual-use, security-supported version of Debian (debian stretrch, 9.x per the above) does not provide openjdk-11, and some irresponsible middle-person act of taking mislabeled builds from other repos (e.g. backports, unstable, etc.) is to blame. Fine, let's go with that for just a minute. Ignore the fact that the original posting was about the end-result (and specifically stated "Why Debian populated their repos with these builds is their business") and ignore the impact on OpenJDK 11. Just for a minute. Let's focus on the OpenJDK 8 part, and let's test the facts, *today*, and limit our testing to the stable, "security supported uploads" in Debian stretch: We still end up staring at this very inconvenient truth: OpenJDK 8, Debian (stable, stretch, 9), and the current situation (two weeks into being alerted to it) show the following right now: root at 020dc36b9046:/# root at 020dc36b9046:/# date Sun May 26 23:55:45 UTC 2019 root at 020dc36b9046:/# root at 020dc36b9046:/# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" root at 020dc36b9046:/# root at 020dc36b9046:/# apt-get update Ign:2 http://cdn-fastly.deb.debian.org/debian stable InRelease Hit:1 http://security-cdn.debian.org/debian-security stable/updates InRelease Hit:3 http://cdn-fastly.deb.debian.org/debian stable-updates InRelease Hit:4 http://cdn-fastly.deb.debian.org/debian stable Release Reading package lists... Done root at 020dc36b9046:/# root at 020dc36b9046:/# apt-get install openjdk-8-jdk ... root at 020dc36b9046:/# root at 020dc36b9046:/# java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) root at 020dc36b9046:/# To be clear on what ?build 1.8.0_212-8u212-b01-1~deb9u1-b01" in the above tracks to, we can track it in https://tracker.debian.org/pkg/openjdk-8 , which has this convenient log for when the build was created (March 29, 2019, 3 weeks prior to the actual release of 8u212 by the OpenJDK 8u project): ? [2019-04-06] openjdk-8 REMOVED from testing (Debian testing watch) ? [2019-03-30] Removed 8u212-b01-1 from unstable (Debian FTP Masters) ? [2019-03-30] Removed 8u144-b01-2 from unstable (Debian FTP Masters) ? [2019-03-30] Removed 8u141-b15-3 from unstable (Debian FTP Masters) ? [2019-03-29] openjdk-8 8u212-b01-1 MIGRATED to testing (Debian testing watch) ? [2019-03-29] Accepted openjdk-8 8u212-b01-1~deb9u1 (source amd64 all) into proposed-updates->stable-new, proposed-updates (Moritz Muehlenhoff) (signed by: Moritz M?hlenhoff) ? [2019-03-20] Accepted openjdk-8 8u212-b01-1~deb9u1 (source amd64 all) into stable->embargoed, stable(Moritz Muehlenhoff) (signed by: Moritz M?hlenhoff) ? [2019-03-19] Accepted openjdk-8 8u212-b01-1 (source) into unstable (Matthias Klose) [The fact that your name is on the actual log items above makes it unlikely that options (a) or (b) above apply. It's pretty clearly (c) and/or (d).] So what do we have here? A mislabeled (' openjdk version "1.8.0_212" ', no disqualifiers, early access, or "danger, this is not really 8u212" labeled anywhere), fell off the truck (actually built from sources picked up at a random weekly tag point, 3 weeks prior to the actual 8u212 release was complete, and missing a multitude of bug fixes and security fixes that are in the actual 8u212 release), build of OpenJDK "8u212" is being delivered in the current, stable, debian release from default repositories. Not the unstable repos, not the backports repos, not by some other version's repos, not by some middle-men. You may not think that "Mystery Meat" is a good label for this very situation. But I suspect that would put you in the tiny minority of people who believe or argue that all meat, from all sources, is equally untrustworthy. And that labels, cleanliness, use-by-dates, and (most importantly) reputation for label accuracy and trustworthiness should not affect people's consumption choices. That's what is going on right now. Arguing that someone else is to blame doesn't change it. Arguing that "the media" is against you and has nefarious motives doesn't either. And arguing that "this is fine, and it is what users of "stable" Debian should expect", well, that just tells them what to expect, I guess. > > On 15.05.19 20:49, Gil Tene wrote: >> Umm? >> >> Lumpy.local-43% docker run -it --rm openjdk:8 java -version >> openjdk version "1.8.0_212" >> OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) >> OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) >> Lumpy.local-44% date >> Wed May 15 11:41:12 PDT 2019 >> >> Look at the build number carefully? This was populated no later >> than March 27, 2019. 3 weeks before the actual 8u212 was released >> on April 16, 2019. > > The Debian openjdk-8 source package is put together from the jdk8u, > aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects. Certainly not > ideal, however these packages can only be made if all the sources are available, > or tagged. > > I am happy to see that the aarch64-port tries to keep up with the jdk8u project > however this is a different story with the aarch32-port project: The project > doesn't have *any* prerelease tags, plus the project updates it's release tags > only months after the jdk8u releases. So blaming Debian for shipping what they > are able to ship and Azul holding back source releases yourself? Ein Schelm > wer B?ses dabei denkt ... > >> Similarly: >> >> Lumpy.local-46% docker run -it --rm openjdk:11 java -version >> openjdk version "11.0.3" 2019-04-16 >> OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91) >> OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing) >> Lumpy.local-47% date >> Wed May 15 11:43:12 PDT 2019 >> >> This one was populate dno later than April 3, 2 weeks before >> the actual 11.0.3 was released on April 16, 2019 >> >> If anyone was wondering about the importance of having version strings say >> "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any >> and all OpenJDK builds that are not an actual release build, the above shows >> you how bad things get when that practice is not followed. > > Don't trust the label, just the content. I agree that the java community is > much more label/version driven, however this is not a reason to discredit other > sane builds. > >> Why Debian populated their repos with these builds is their business, and >> why docker chose to use those specific debian builds can be speculated >> about all we want. the details don't matter. The end result of these >> cumulative "reasonable" (according to some people) choices is that the >> default openjdk runs done by millions of people on docker right now are >> using "mystery meat", incomplete, and exposed builds while seeming to >> report (to the lay person) a Java version that would suggest a real 8u212 >> or 11.0.3 (which one would expect has the security vulnerabilities in the >> April update addressed, the bug fixes included, etc.). > > Again, I see this as an advertising or promotion email for the Azul binary > builds. Fine, do so. Both please use marketing lists and not the OpenJDK > technical lists. > > Matthias From fweimer at redhat.com Mon May 27 10:13:12 2019 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 27 May 2019 12:13:12 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> (Gil Tene's message of "Mon, 27 May 2019 01:24:58 +0000") References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> Message-ID: <875zpwkxxj.fsf@oldenburg2.str.redhat.com> * Gil Tene: > root at 020dc36b9046:/# java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > root at 020dc36b9046:/# I wonder if the core technical issue is this: Debian stretch currently packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or 8u212-b04 (which one isn't clear, the release announcement was for 8u212-b03, not for 8u212-b04 or 8u212-ga). My understanding is that 8u212-b01 is a version identifier created by the jdk8u project, and based on a quick check, it matches what Debian identifies as its upstream sources (except for some stripping of system library components). But it's not the most current release. Thanks, Florian From martijnverburg at gmail.com Mon May 27 10:19:13 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 27 May 2019 11:19:13 +0100 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <875zpwkxxj.fsf@oldenburg2.str.redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> Message-ID: On Mon, 27 May 2019 at 11:13, Florian Weimer wrote: > * Gil Tene: > > > root at 020dc36b9046:/# java -version > > openjdk version "1.8.0_212" > > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > > root at 020dc36b9046:/# > > I wonder if the core technical issue is this: Debian stretch currently > packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or > 8u212-b04 (which one isn't clear, the release announcement > > was for 8u212-b03, not for 8u212-b04 or 8u212-ga). > > My understanding is that 8u212-b01 is a version identifier created by > the jdk8u project, and based on a quick check, it matches what Debian > identifies as its upstream sources (except for some stripping of system > library components). But it's not the most current release. > It's one of the challenges, the rest of the world doesn't necessarily know about the new `-ga` tag that we use to designate releases, so we need to go and help them. I've also replied separately to this thread (with a meeting request) but cut out the OpenJDK mailing lists as it's really the Debian distro list that we should be discussing this on. If folks feel otherwise, let me know and I'll CC these lists back in. Cheers, Martijn > > Thanks, > Florian > From fweimer at redhat.com Mon May 27 10:39:12 2019 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 27 May 2019 12:39:12 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: (Martijn Verburg's message of "Mon, 27 May 2019 11:19:13 +0100") References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> Message-ID: <871s0kkwq7.fsf@oldenburg2.str.redhat.com> * Martijn Verburg: > On Mon, 27 May 2019 at 11:13, Florian Weimer wrote: > > * Gil Tene: > > > root at 020dc36b9046:/# java -version > > openjdk version "1.8.0_212" > > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > > root at 020dc36b9046:/# > > I wonder if the core technical issue is this: Debian stretch currently > packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or > 8u212-b04 (which one isn't clear, the release announcement > > was for 8u212-b03, not for 8u212-b04 or 8u212-ga). > > My understanding is that 8u212-b01 is a version identifier created by > the jdk8u project, and based on a quick check, it matches what Debian > identifies as its upstream sources (except for some stripping of system > library components). But it's not the most current release. > > It's one of the challenges, the rest of the world doesn't necessarily > know about the new `-ga ` tag that we use to designate releases, so we > need to go and help them. Right. could mention these tags and link to official tarball(s). I suspect this page is the permanent, quasi-official release announcement due to the openjdk.java.net limitations. It would also help to have a permanent location *anywhere* which is compatible with distribution upstream watch files. Thanks, Florian From goetz.lindenmaier at sap.com Mon May 27 12:53:54 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 27 May 2019 12:53:54 +0000 Subject: RFR(XS): 8224838: Bump update version for OpenJDK: jdk-11.0.5 Message-ID: Hi, to start development of jdk-11.0.5, we need to bump the version: http://cr.openjdk.java.net/~goetz/wr19/8224838-version_11.0.5/01/ Please review. Naturally, I will only push this after JBS was updated to tag for 11.0.5. Thanks, Goetz. From doko at ubuntu.com Mon May 27 13:34:04 2019 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 27 May 2019 15:34:04 +0200 Subject: OpenJDK 8u/11u release information Message-ID: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> Hi guys, until recently we didn't have any source code releases for OpenJDK at all. I appreciate the effort to have source releases, however the gap to produce binaries based on the source release is way to high. Instead of having a dozen of configuration options to build a binary, please can we have a default option which builds consumable packages by default? OpenJDK doesn't have source releases until recently. Now we have, and from my point of view, such a source release should only have a minimal set of configuration options to build a usable image. Things I would like to see - I see it's important to display the version string as the first line of java -version. The source release should set that correctly. - The OpenJDK source release ships with the vendor set to Oracle. Distributors set that to Azul, AdoptJDK, Debian, and probably other values. The binaries built by the OpenJDK itself set that to some sort of version string. An "unknown" vendor causes issue, because some software (LibreOffice, Gradle) uses or at least used that to check for a valid java installation. - The version number should be used for both the source release and the binary package. E.g. the 11.0.3 source release is missing the -ga modifier. - To include a package in a Linux distro, you have to use a monotonically increasing version number, and you have to follow the versioning constraints for the distro. So sometimes you have to juggle with the version numbers. E.g. for Debian/Ubuntu a second dash is problematic for version comparisons. I consider uploads to a development distro as essential, so I have to plan for these version numbers as well. Last time when I asked on the mailing lists, people seemed to be fine with the versioning, however if needed, we could document such versioning on the OpenJDK wiki? - It would be very helpful to see directly in the binary how the build was configured. GCC is showing this information with gcc -v Python is showing that with python -c 'import sysconfig; print(sysconfig.get_config_var("CONFIG_ARGS"))' Or maybe this already exists? Usually binaries in a distro come with a changelog, however sometimes even that is stripped away by re-distributors of binaries. - The configure system has some issues with invalid configure arguments, e.g. configuring --with-version-build='' leads to a failing build. Matthias From christoph.langer at sap.com Mon May 27 13:35:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 27 May 2019 13:35:44 +0000 Subject: RFR(XS): 8224838: Bump update version for OpenJDK: jdk-11.0.5 In-Reply-To: References: Message-ID: Thumbs up ?? /Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 27. Mai 2019 14:54 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] RFR(XS): 8224838: Bump update version for OpenJDK: > jdk-11.0.5 > > Hi, > > to start development of jdk-11.0.5, we need to bump > the version: > http://cr.openjdk.java.net/~goetz/wr19/8224838-version_11.0.5/01/ > > Please review. > > Naturally, I will only push this after JBS was updated to tag for 11.0.5. > > Thanks, > Goetz. From thomas.stuefe at gmail.com Mon May 27 14:59:16 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 May 2019 16:59:16 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com> Message-ID: Hi Gil, On Mon, May 27, 2019 at 1:41 AM Gil Tene wrote: > Seriously? > > You see factual reporting (directly documented and dated in the original > posting) of the actual version numbers being used by official docker > images, along with irrefutable proof that the packages used in those were > built weeks before the respective OpenJDK 8u and 11u releases were > complete, as ?fake news?? > > You think that alerting millions of unsuspecting people using exposed, > insecure builds that falsely report their OpenJDK version (as one that > includes e.g. critical security fixes) to the fact as ?marketing?? > > Did you try to contact Debian folks to give them opportunity to fix those security concerns before going public with them? Or did they not react in time? Cheers, Thomas From gil at azul.com Mon May 27 16:23:00 2019 From: gil at azul.com (Gil Tene) Date: Mon, 27 May 2019 16:23:00 +0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com>, Message-ID: <9CD92EA4-EAAE-44ED-9901-C269628035C7@azul.com> Sent from my iPad On May 27, 2019, at 7:59 AM, Thomas St?fe > wrote: Hi Gil, On Mon, May 27, 2019 at 1:41 AM Gil Tene > wrote: Seriously? You see factual reporting (directly documented and dated in the original posting) of the actual version numbers being used by official docker images, along with irrefutable proof that the packages used in those were built weeks before the respective OpenJDK 8u and 11u releases were complete, as ?fake news?? You think that alerting millions of unsuspecting people using exposed, insecure builds that falsely report their OpenJDK version (as one that includes e.g. critical security fixes) to the fact as ?marketing?? Did you try to contact Debian folks to give them opportunity to fix those security concerns before going public with them? Or did they not react in time? Multiple times over ~4.5 years, and through multiple channels. The ?we don?t care?, ?go away, vendor?, and ?java and openjdk do versioning wrong? reactions are the most common. Many were less polite than that. The defensive tone of the email you see on this thread is about average. The denial and deflection attempts you see there are also common. Some people just don?t want help, at least not from some. And that?s fine. There is an established way to coordinate activity around security issues in the java community, with plenty of time to deal with them before publication, and a coordinated embargo date before which they do not get discussed publicly. Each java distribution is then free to include fixes to those issues after that date. And since the binaries for fixed versions become widely available, CVE information published, and source code for the fixes show up in at least some cases (e.g. OpenJDK), the cats are out of theirs bags at that point. As has happened many many times in the past, OpenJDK 8u chose the 8u212 release, and OpenJDK 11u the 11.0.3 release, as the ones that would include the 8u and 11u updates for issues revealed on April 16, 2019 (the coordinated quarterly update date). All tagged builds with 8u212 mentioned prior to that date were not releases, but things preparing to eventually become the 8u212 release. By necessity, none of the non-release builds included any security fixes, as those were all developed and integrated ?in the dark?. Same goes for 11.0.3. OpenJDK code is open source, and the process of developing an upcoming quarterly update release is done mostly in the open (with exceptions, like the security part, which is done in the dark but still with community coordination). These are good things. But these good things also mean that anyone, anywhere, can pick up source code at any point, and are perfectly within their rights to build that code, call it whatever version they want, give it to people, and even advertise and market it as ?stable? and attack anyone who dares to suggest anything is wrong with their choices. Does that mean that making a JDK from unreleased code and calling it 8u212 (with no ?not really? disqualifier) a good idea? Probably not according to most people. Certainly not IMO. But as noted before, I?ve given up on holding my breath a long time ago. Cheers, Thomas From ebourg at apache.org Mon May 27 15:32:31 2019 From: ebourg at apache.org (Emmanuel Bourg) Date: Mon, 27 May 2019 17:32:31 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com> Message-ID: <56bca97d-7110-19d2-92c1-a12dc87bd7fb@apache.org> Le 27/05/2019 ? 16:59, Thomas St?fe a ?crit?: > Did you try to contact Debian folks to give them opportunity to fix > those security concerns before going public with them? No he didn't, and I don't think he cares. I'd like to thank Aleksey Shipilev for bringing the issue in a constructive and civilized manner on the debian-java list. This led to the upload of OpenJDK 11.0.3+7 to the Debian 9 "Stretch" backport repository last week. Emmanuel Bourg From doko at ubuntu.com Mon May 27 16:53:58 2019 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 27 May 2019 18:53:58 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <9CD92EA4-EAAE-44ED-9901-C269628035C7@azul.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com> <9CD92EA4-EAAE-44ED-9901-C269628035C7@azul.com> Message-ID: On 27.05.19 18:23, Gil Tene wrote: >> Did you try to contact Debian folks to give them opportunity to fix those security concerns before going public with them? Or did they not react in time? > > Multiple times over ~4.5 years, and through multiple channels. The > ?we don?t care?, ?go away, vendor?, and ?java and openjdk do versioning > wrong? reactions are the most common. Many were less polite than that. > The defensive tone of the email you see on this thread is about average. > The denial and deflection attempts you see there are also common. I can't follow that. There is not a single bug report about that in the Debian tracker. Looking at the Debian Java mailing list, there is not a single posting from your side. And I can't remember that being discussed on the ML either. Also not on the distro-pkg-dev ML. Same thing for the Ubuntu bug tracker. So which channels are you using? > Some people just don?t want help, at least not from some. And that?s fine. I raised questions about the versioning on the jdk ML's multiple times. Most of those were ignored, or saw the versioning as being correct. I brought up the configuration issues at this year OpenJDK committers workshop, but it was voted down because other topics seemed more pressing to discuss. Matthias From gil at azul.com Tue May 28 00:51:53 2019 From: gil at azul.com (Gil Tene) Date: Tue, 28 May 2019 00:51:53 +0000 Subject: OpenJDK 8u/11u release information In-Reply-To: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> References: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> Message-ID: <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> > On May 27, 2019, at 6:34 AM, Matthias Klose wrote: > > Hi guys, The following is meant to be constructive and informational, so please don't read it as anything other than that. With that said, any and all "you are plain wrong, and here is why" followups to what I say below are welcome. > > until recently we didn't have any source code releases for OpenJDK at all. Not sure what you mean by this. Can you clarify what you mean when you use the term "source code releases"? And how the thing you mean differs from historical practice in OpenJDK? By my understanding OpenJDK, as a source code project, has been producing source code releases pretty much since OpenJDK 6 was first released, and has never stopped doing so, with continuing update releases happening within major version project on a pretty regular basis. Version formats have changed across major java versions, tagging and development processes going into a release also evolved and changed over time. But at all points in the past several years, it's been pretty clear when a release happened, and what the source code for that release actually was. Binary builds of those released sources have been around for quite a while as well. But in the past, these may not have been created consistently by the project lead for every update. What is "new" (AFAIK), specifically in 8u and 11u (and not in other projects thus far), is the posting of project-lead blessed, TCK-tested builds of "vanilla" released (as well as EA) sources of 8u and 11u (see e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009105.html and subsequent discussions) at some external location. That's a very positive development, which I certainly hope will last and continue. But as noted in that e-mail thread, those binaries are simply good, fully-TCK-tested builds of the released sources, posted to a known location. They did not change the release process in any way. > I appreciate the effort to have source releases, however the gap to produce > binaries based on the source release is way to high. Instead of having a dozen > of configuration options to build a binary, please can we have a default option > which builds consumable packages by default? As things stand, across the various java version projects, the default build modes for all sources (including releases) produce consumable-by-the-builder things, intentionally labeled in ways that would scare people away from using the bits as a release. This is intentional, and is aimed to make sure that things that look like an actual release will only happen through intent, assertive actions and real choices about reported versions. E.g., when I build things using the defaults, I'd get stuff like: # bash ./configure # make all # build/linux-x86_64-normal-server-release/jdk/bin/java -version openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-gil_2019_05_27_10_48-b00) OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) And that's a good thing. It prevents the accidental leakage of unfinished bits to others. To produce things you would give other people ("consumable" by others), you need to intentionally make assertive (non-default) choices about configuration. Normally, stating your update version, build version, and milestone (or "pre" version) at the very least, and likely things like vendor version, etc. Non of those have good "defaults", as you don't want any of those to appear "by accident" in a build. The same is true for the sources of the actual quarterly releases, which are no more than a snapshot of the sources at the release point. To create a binary build that does not carry the "-internal" identification, and that has specific update and build numbers, you have to assertively declare those in the build configuration. But that's not very complicated. E.g. # bash ./configure --with-update-version=972 --with-build-number=b41 --with-milestone="snapshot" # make clean; make all # build/linux-x86_64-normal-server-release/jdk/bin/java -version openjdk version "1.8.0_972-snapshot" OpenJDK Runtime Environment (build 1.8.0_972-snapshot-b41) OpenJDK 64-Bit Server VM (build 25.972-b41, mixed mode) And with the special milestone called "fcs": # bash ./configure --with-update-version=982 --with-build-number=b42 --with-milestone="fcs" # make clean; make all # build/linux-x86_64-normal-server-release/jdk/bin/java -version openjdk version "1.8.0_982" OpenJDK Runtime Environment (build 1.8.0_982-b42) OpenJDK 64-Bit Server VM (build 25.982-b42, mixed mode) Note: For OpenJDK 8u "fcs" is a special milestone. It is the specific thing you need to do to get rid of the milestone part of the versions string. Any other value (including "", which will revert to "internal") will show up in the version, because of this in common/autoconf/spec.gmk.in : # These variables need to be generated here so that MILESTONE and # JDK_BUILD_NUMBER can be overridden on the make command line. ifeq ($(MILESTONE), fcs) RELEASE=$(JDK_VERSION)$(BUILD_VARIANT_RELEASE) else RELEASE=$(JDK_VERSION)-$(MILESTONE)$(BUILD_VARIANT_RELEASE) endif 11u is a little different. The release versioning is more specifically defined (JEP322), and the term for that "disqualifier" part for the version that tells you it is not an actual release (what 8u sets using --with-milestone) is the "pre-release identifier" ($PRE) part of the version string (set --with-version-pre). The default behaves the same with regards to "-internal" in the sense that $PRE defaults to "internal", a =nd must be assertively set to "" to get rid of it. But in 11u a default for the UPDATE portion of the JEP322 version string is typically baked into make/autoconf/version-numbers (as opposed to having to be set via --with-update-version in 8u) so e.g.: # bash ./configure # make all # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version openjdk version "11.0.3-internal" 2019-04-16 OpenJDK Runtime Environment (build 11.0.3-internal+0-adhoc.gil.11u1103rel) OpenJDK 64-Bit Server VM (build 11.0.3-internal+0-adhoc.gil.11u1103rel, mixed mode) But when you build something that is fit for others to consume, you will still want to provide a build number with --with-build-number, use -with-version-pre="" if you want to say it is an actual release (use e.g. "ea", or just leave blank to make it "internal" otherwise), and in addition set --with-version-opt to control that thing that defaults to "adhoc.$USERNAME.$basedirname". Finally, --with-vendor-version-string="18.9" is considered "vanilla" (the year.month for Java SE 11), and that's where non-vanilla distros tend put their name in. So e.g.: # bash ./configure --with-version-build=42 --with-version-opt="" --with-version-pre="" --with-vendor-version-string="18.9" # make all # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version openjdk version "11.0.3" 2019-04-16 OpenJDK Runtime Environment 18.9 (build 11.0.3+42) OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+42, mixed mode) > > OpenJDK doesn't have source releases until recently. Now we have, and from my > point of view, such a source release should only have a minimal set of > configuration options to build a usable image. Things I would like to see > > - I see it's important to display the version string as the first line > of java -version. The source release should set that correctly. See above discussion about why (by long standing OpenJDK historical practice) version strings are controlled by the build configuration, and not by the source code of a release. > > - The OpenJDK source release ships with the vendor set to Oracle. > Distributors set that to Azul, AdoptJDK, Debian, and probably other > values. The binaries built by the OpenJDK itself set that to some > sort of version string. An "unknown" vendor causes issue, because some > software (LibreOffice, Gradle) uses or at least used that to check > for a valid java installation. I'll assume you are referring to the "18.9" part in the version string reported by the "blessed by project lead" builds of the OpenJDK 11u 11.0.3 release: # ./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) That 18.9 part is the "vendor version string" as defined by JEP322 (a new property that did not exist in 8u). The choice of "18.9" (the year.month that Java SE 11 was released) is both the actual example vendor version string shown in the JEP, and follows the precedent already set for "vanilla" OpenJDK builds of 11, 11.0.1, and 11.0.2 produced by the previous project lead during the first 6 months of 11u. (note that those were the OpenJDK build posted by Oracle, not the Oracle JDK builds). Since "18.9" was there as a vendor version string form the very start of OpenJDK 11, we can assume that anything that knows how to parse JEP322 versions will not have a problem with it. > > - The version number should be used for both the source release and the > binary package. E.g. the 11.0.3 source release is missing the -ga > modifier. I'll assume that you are referring to version string reported by the binary, e.g. in response to -version, and not to package names, file names, or tags in source control. The version string conventions for each existing Java SE version are already established, and they (unfortunately) differ by major version. Thus far, for all Java SE versions I know of which had an OpenJDK project (6, 7, 8, 9, 10, 11, 12), neither Oracle nor OpenJDK builds have included a positive (e.g. "-ga") indicator in the version strings of actually-released versions. Instead, the long standing convention has been to include a disqualifier ("-ea", "-internal", "-rc1") in non-released builds. The build system defaults to using the -internal qualifier in all versions to date. Thus the current output from the project-lead blessed builds of 8u212 is: # java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-b04) OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) (which, since there is no "disqualifier" in the version, means that it reports as a build of an actual release). The technical term for this "disqualifier" has varied over the years. As shown above, 8u calls it "milestone", 11u calls it a "pre-release identifier". But in all versions so far, *not* having it there means that it is a release. Changing version string formats and conventions for indicating things within a major java version is a generally bad idea. Adding "-ga" to actual update releases of existing Java SE major versions is likely to blow up a whole bunch of things. For one: a common ways to determine that a version of OpenJDK or Oracle JDK is an actual released version (as opposed to some ea/beta/rc1/internal/experimental thing) is to verify that there is no "-XYZ" part (the milestone or $PRE) in the version string. Making changes to conventions across versions is quite possible, and has been done multiple times (e.g. JEP 322, JEP 223). JEP 322 is what we currently follow for 11u and above. If it insufficient for some reason, and we want to change it yet again for e.g. OpenJDK 14, that's something to discuss, I guess., But such changes should not affect existing Java SE versions (12 and below). > > - To include a package in a Linux distro, you have to use a monotonically > increasing version number, and you have to follow the versioning > constraints for the distro. So sometimes you have to juggle with the > version numbers. E.g. for Debian/Ubuntu a second dash is problematic > for version comparisons. I consider uploads to a development distro > as essential, so I have to plan for these version numbers as well. > Last time when I asked on the mailing lists, people seemed to be fine > with the versioning, however if needed, we could document such > versioning on the OpenJDK wiki? This is a good point (make sure your *package* names retain monotonically growing version numbers), but since these rules apply to the package names as seen by the distro (and not to the version strings) simple distro-specific file name conversion conventions seem to suffice. This is often necessary simply because conventions and file name requirements can vary widely between OSs (some don't like dots, some don't like dashes, some deal with capitalization in interesting ways). E.g. you can convert every dash in the version string to to an underscore in the .deb or .rpm package names. An interesting problem shows up if the parsing of the version string related fields appears to "go backwards" in your monotonic comparisons (e.g. if the sorting is text based rather than numeric, and 11.0.10 would be considered earlier than 11.0.9, or 8u92 was considered to come after 8u102). I can think of a few ways to resolve that with package name conventions, but I don't really know if this is a problem. Does debian compare numeric sequence substrings in package name numerically, or lexicographically? > > - It would be very helpful to see directly in the binary how the build > was configured. GCC is showing this information with > gcc -v > Python is showing that with > python -c 'import sysconfig; print(sysconfig.get_config_var("CONFIG_ARGS"))' > Or maybe this already exists? > > Usually binaries in a distro come with a changelog, however sometimes > even that is stripped away by re-distributors of binaries. > > - The configure system has some issues with invalid configure arguments, e.g. > configuring --with-version-build='' leads to a failing build. Setting --with-version-build="" works on 8u (it is a string). In 11u, you'd use --with-version-build=0 (it is an integer). > > Matthias From christoph.langer at sap.com Tue May 28 07:21:21 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 28 May 2019 07:21:21 +0000 Subject: [11u] RFR: 8208698: Improved ECC Implementation Message-ID: Hi, please review this backport of JDK-8208698: Improved ECC Implementation. Bug: https://bugs.openjdk.java.net/browse/JDK-8208698 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/752e57845ad2 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8208698.11u/ The patch did not apply cleanly because there were conflicts in src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java due to JDK-8205476 which is part of jdk/jdk but not of jdk11u-dev. Unfortunately, JDK-8205476 can not be downported as prerequisite because it brings a behavioral change and is associated with a CSR. So I resolved the rejects manually. I add the rejects below. Thanks Christoph --- ECDHKeyAgreement.java +++ ECDHKeyAgreement.java @@ -99,42 +104,74 @@ ("Key must be a PublicKey with algorithm EC"); } - ECPublicKey ecKey = (ECPublicKey)key; - ECParameterSpec params = ecKey.getParams(); + this.publicKey = (ECPublicKey) key; - if (ecKey instanceof ECPublicKeyImpl) { - publicValue = ((ECPublicKeyImpl)ecKey).getEncodedPublicValue(); - } else { // instanceof ECPublicKey - publicValue = - ECUtil.encodePoint(ecKey.getW(), params.getCurve()); - } + ECParameterSpec params = publicKey.getParams(); int keyLenBits = params.getCurve().getField().getFieldSize(); secretLen = (keyLenBits + 7) >> 3; return null; } + private static void validateCoordinate(BigInteger c, BigInteger mod) { + if (c.compareTo(BigInteger.ZERO) < 0) { + throw new ProviderException("invalid coordinate"); + } + + if (c.compareTo(mod) >= 0) { + throw new ProviderException("invalid coordinate"); + } + } + + /* + * Check whether a public key is valid. Throw ProviderException + * if it is not valid or could not be validated. + */ + private static void validate(ECOperations ops, ECPublicKey key) { + + // ensure that integers are in proper range + BigInteger x = key.getW().getAffineX(); + BigInteger y = key.getW().getAffineY(); + + BigInteger p = ops.getField().getSize(); + validateCoordinate(x, p); + validateCoordinate(y, p); + + // ensure the point is on the curve + EllipticCurve curve = key.getParams().getCurve(); + BigInteger rhs = x.modPow(BigInteger.valueOf(3), p).add(curve.getA() + .multiply(x)).add(curve.getB()).mod(p); + BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p); + if (!rhs.equals(lhs)) { + throw new ProviderException("point is not on curve"); + } + + // check the order of the point + ImmutableIntegerModuloP xElem = ops.getField().getElement(x); + ImmutableIntegerModuloP yElem = ops.getField().getElement(y); + AffinePoint affP = new AffinePoint(xElem, yElem); + byte[] order = key.getParams().getOrder().toByteArray(); + ArrayUtil.reverse(order); + Point product = ops.multiply(affP, order); + if (!ops.isNeutral(product)) { + throw new ProviderException("point has incorrect order"); + } + + } + // see JCE spec @Override protected byte[] engineGenerateSecret() throws IllegalStateException { - if ((privateKey == null) || (publicValue == null)) { + if ((privateKey == null) || (publicKey == null)) { throw new IllegalStateException("Not initialized correctly"); } - byte[] s = privateKey.getS().toByteArray(); - byte[] encodedParams = // DER OID - ECUtil.encodeECParameterSpec(null, privateKey.getParams()); - - try { - - byte[] result = deriveKey(s, publicValue, encodedParams); - publicValue = null; - return result; - - } catch (GeneralSecurityException e) { - throw new ProviderException("Could not derive key", e); - } - + Optional resultOpt = deriveKeyImpl(privateKey, publicKey); + byte[] result = resultOpt.orElseGet( + () -> deriveKeyNative(privateKey, publicKey) + ); + publicKey = null; + return result; } // see JCE spec From martijnverburg at gmail.com Tue May 28 08:51:49 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 28 May 2019 09:51:49 +0100 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <871s0kkwq7.fsf@oldenburg2.str.redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> <871s0kkwq7.fsf@oldenburg2.str.redhat.com> Message-ID: Hi Florian, > My understanding is that 8u212-b01 is a version identifier created by > > the jdk8u project, and based on a quick check, it matches what Debian > > identifies as its upstream sources (except for some stripping of system > > library components). But it's not the most current release. > > > > It's one of the challenges, the rest of the world doesn't necessarily > > know about the new `-ga ` tag that we use to designate releases, so we > > need to go and help them. > > Right. could > mention these tags and link to official tarball(s). I suspect this page > is the permanent, quasi-official release announcement due to the > openjdk.java.net limitations. > > It would also help to have a permanent location *anywhere* which is > compatible with distribution upstream watch files. > Right, you are - https://github.com/AdoptOpenJDK/openjdk-website/pull/501 raised to resolve this, thanks! Cheers, Martijn > > Thanks, > Florian > From martijnverburg at gmail.com Tue May 28 08:54:42 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 28 May 2019 09:54:42 +0100 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> Message-ID: Hi all, It's one of the challenges, the rest of the world doesn't necessarily know >> about the new `-ga` tag that we use to designate releases, so we need to go >> and help them. >> > > I've also replied separately to this thread (with a meeting request) but > cut out the OpenJDK mailing lists as it's really the Debian distro list > that we should be discussing this on. > If folks feel otherwise, let me know and I'll CC these lists back in. > FYI - I have a call (high bandwidth is required here) with Matthias next Monday (1100UK time) so I can learn more about the Debian process and what we can do to align going forward. I'll report back here or via a Debian ticket so the conversation and outcomes can be tracked. if anyone else wants to join on the call then please let me know! Cheers, Martijn From aph at redhat.com Tue May 28 09:12:43 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 10:12:43 +0100 Subject: Backport of 8217707 In-Reply-To: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> References: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> Message-ID: <20182023-29cb-cace-c072-52e38d4e2064@redhat.com> On 5/25/19 6:07 PM, Ali Ince wrote: > I would like to request backport of this fix to 11u and 12u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217707 > Fix: http://hg.openjdk.java.net/jdk/jdk/rev/3a217bbdd3a2 > > The patch itself applies cleanly to both repos. The patch is approved for 11u. However, there is no-one whose job it is to push it. I might be able to get to it today, but I'm not promising anything. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Tue May 28 09:16:00 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 May 2019 11:16:00 +0200 Subject: Backport of 8217707 In-Reply-To: <20182023-29cb-cace-c072-52e38d4e2064@redhat.com> References: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> <20182023-29cb-cace-c072-52e38d4e2064@redhat.com> Message-ID: <329be61e-07e5-0cb9-7e13-4a6201521237@redhat.com> On 5/28/19 11:12 AM, Andrew Haley wrote: > On 5/25/19 6:07 PM, Ali Ince wrote: >> I would like to request backport of this fix to 11u and 12u. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217707 >> Fix: http://hg.openjdk.java.net/jdk/jdk/rev/3a217bbdd3a2 >> >> The patch itself applies cleanly to both repos. > > The patch is approved for 11u. However, there is no-one whose job it > is to push it. I might be able to get to it today, but I'm not > promising anything. I'll push it to 11u, and I am able to run x86_32 builds too. -Aleksey From aph at redhat.com Tue May 28 09:31:19 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 10:31:19 +0100 Subject: Backport of 8217707 In-Reply-To: <329be61e-07e5-0cb9-7e13-4a6201521237@redhat.com> References: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> <20182023-29cb-cace-c072-52e38d4e2064@redhat.com> <329be61e-07e5-0cb9-7e13-4a6201521237@redhat.com> Message-ID: On 5/28/19 10:16 AM, Aleksey Shipilev wrote: > On 5/28/19 11:12 AM, Andrew Haley wrote: >> On 5/25/19 6:07 PM, Ali Ince wrote: >>> I would like to request backport of this fix to 11u and 12u. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217707 >>> Fix: http://hg.openjdk.java.net/jdk/jdk/rev/3a217bbdd3a2 >>> >>> The patch itself applies cleanly to both repos. >> >> The patch is approved for 11u. However, there is no-one whose job it >> is to push it. I might be able to get to it today, but I'm not >> promising anything. > > I'll push it to 11u, and I am able to run x86_32 builds too. OK, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Tue May 28 09:39:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 May 2019 11:39:01 +0200 Subject: Backport of 8217707 In-Reply-To: <329be61e-07e5-0cb9-7e13-4a6201521237@redhat.com> References: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> <20182023-29cb-cace-c072-52e38d4e2064@redhat.com> <329be61e-07e5-0cb9-7e13-4a6201521237@redhat.com> Message-ID: On 5/28/19 11:16 AM, Aleksey Shipilev wrote: > On 5/28/19 11:12 AM, Andrew Haley wrote: >> On 5/25/19 6:07 PM, Ali Ince wrote: >>> I would like to request backport of this fix to 11u and 12u. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217707 >>> Fix: http://hg.openjdk.java.net/jdk/jdk/rev/3a217bbdd3a2 >>> >>> The patch itself applies cleanly to both repos. >> >> The patch is approved for 11u. However, there is no-one whose job it >> is to push it. I might be able to get to it today, but I'm not >> promising anything. > > I'll push it to 11u, and I am able to run x86_32 builds too. And done: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/eb1e977b8126 -Aleksey From christoph.langer at sap.com Tue May 28 15:04:58 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 28 May 2019 15:04:58 +0000 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> References: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> Message-ID: Hi Andrew, I just took over your changes from the OpenJDK 8 Updates Wiki to the OpenJDK11 pages. Thanks for the nice update. Now the pages reflect the current process and their readability has significantly increased ?? As for the tagging then I think we have agreed to start with tagging in the dev branches the week after GA of the previous release. And when no changes occurred then we'd skip a tag and announce that on the mailing lists. This is what's written down in the Wiki. I fully share your arguments below. Best regards Christoph > -----Original Message----- > From: Andrew John Hughes > Sent: Donnerstag, 16. Mai 2019 21:44 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz > ; Andrew Haley > Subject: Re: JDK11/8 Updates: process, schedules and tagging > > On 16/05/2019 10:57, Langer, Christoph wrote: > > Hi, > > > > > > > > after we had the discussion about the OpenJDK 8/11 release process and > > schedule [0], I?d like to explicitly spell out the current status and > > update the Wiki pages. > > > > > > > > It seems like we have agreed to a 3 phase model > > > > > > > > 1. Development > > > > 2. Rampdown (RDP2) > > > > 3. Freeze > > > > > > > > I?ve updated the timelines on the Wiki pages [1], [2] now accordingly. > > Please check/review. > > > > Thanks. I'll review the 8u page and check it matches the process I'm > following. > > I do think "RDP2" should be avoided as there is no "RDP1". > > > > > > > I would short-summarize our process like this: > > > > During development phase, changes go into the development repositories > > (jdk8u-dev/jdk11u-dev) and weekly tagging will be done in there. When > > the release repositories (jdk8u/jdk11u) aren?t blocked by > > rampdown/freeze of the previous release, the tags will be synced on a > > weekly basis to the release repositories. When rampdown of a release > > starts, merges from dev to release repositories are suspended and RDP2 > > approved changes have to be pushed to the release repositories. From > > that time merges happen from release->dev. After the freeze tag, no > > changes must go into the release repository while the CPU is assembled > > non publicly. After release, the CPU is merged back to the open > > repositories. > > Yes: > > Dev phase: dev tagged, dev->master > Rampdown phase: master tagged, master->dev > Freeze phase: no changes to master > Release: CPU changes pushed to master, master->dev > > > > > > > > > Is that our common understanding? If I get no objections, I?ll update > > the process description pages [3] and [4] accordingly. > > > > > > > > I furthermore have 2 questions / things to clarify. > > > > > > > > a) Will we tag in the dev-repositories right from the start? E.g. will > > we start tagging 11.0.5 right after the 11.0.4 RDP2 integration from > > 11u-dev to 11u in the week after May 28? > > > > ??? - I would suggest to do so. > > We do tag that point as -b00, I believe. > > If you mean do we start weekly tags of release x+1 in dev once release x > is in rampdown, then no, I don't plan to for 8u. If you have the cycles > to do so for 11, you can, but I need that time - particularly the freeze > period - to prepare, build and test the imminent releases. > > Also, I don't really see the point when there is nowhere to promote the > build to, as master is still on release x. > > That does mean that b01 will run over a longer period than other tags, > but I don't see that as a particular problem. > > > > > b) Will we also do a weekly tag when no changes happened after the > > previous tag? This should probably be a rare case given the current > > activities but we should have a guideline for that. > > > > ??? - My feeling would be to skip the tag then. I can?t see any value in > > this. > > > > I agree with skipping such empty tags, with an appropriate list > announcement. > > I think the predictability argument is already lost in the final stages > where we may have to add multiple tags in secret during the addition of > the security patches. On the other hand, tagging periods with no changes > introduces the possibility of a lot of needless work testing unchanged > sources. > > I think it's easier to convey the message that a tag is being skipped - > which someone who notices the lack of a new tag may look for - than it > is to tag and have unknown users downstream building and testing > something with no changes. > > The problem with comparing with Oracle processes is that their process > is largely internal and so there are not the same potential > communication issues. > > I think this is unlikely during the development stage, but more likely > during the rampdown if nothing is critical enough to be included in the > imminent release. > > My answer to both questions is concerned more with the reality of the > workload involved than pointlessly sticking to an agreed protocol, when > our limited resources could be better utilised. > > > > > > > May I please have your feedback on that (especially from the Andrews ??) > > > > > > > > Thanks > > > > Christoph > > > > > > > > [0] > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/000996.html > > > > [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > > > [2] https://wiki.openjdk.java.net/display/jdk8u/Main > > > > [3] > > > https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Descri > ption > > > > > > [4] > https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description > > > > > > > > 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 aph at redhat.com Tue May 28 15:21:55 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 16:21:55 +0100 Subject: OpenJDK 8u/11u release information In-Reply-To: <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> References: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> Message-ID: <0020169d-e939-343c-ab9d-654bd55094ae@redhat.com> On 5/28/19 1:51 AM, Gil Tene wrote: > What is "new" (AFAIK), specifically in 8u and 11u (and not in other > projects thus far), is the posting of project-lead blessed, > TCK-tested builds of "vanilla" released (as well as EA) sources of > 8u and 11u (see > e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009105.html > and subsequent discussions) at some external location. This practice is not new, it's a continuation of what Oracle used to do with their OpenJDK build releases, and still do with OpenJDK 12: https://jdk.java.net/12/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gil at azul.com Tue May 28 15:58:47 2019 From: gil at azul.com (Gil Tene) Date: Tue, 28 May 2019 15:58:47 +0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <875zpwkxxj.fsf@oldenburg2.str.redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> Message-ID: <7A083937-34F3-4C55-85B6-D848DD0EC4AA@azul.com> > On May 27, 2019, at 3:13 AM, Florian Weimer wrote: > > * Gil Tene: > >> root at 020dc36b9046:/# java -version >> openjdk version "1.8.0_212" >> OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) >> OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) >> root at 020dc36b9046:/# > > I wonder if the core technical issue is this: Debian stretch currently > packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or > 8u212-b04 (which one isn't clear, the release announcement > > was for 8u212-b03, not for 8u212-b04 or 8u212-ga). > > My understanding is that 8u212-b01 is a version identifier created by > the jdk8u project, and based on a quick check, it matches what Debian > identifies as its upstream sources (except for some stripping of system > library components). But it's not the most current release. 8u212-b01 is NOT an OpenJDK 8u release. Not in any form, current or otherwise. Let's be very clear here since this is at the heart of these (misunderstandings?): Releases are identified with tags. Tags are not releases. "8u212-b01" was a tag (in mercurial) used during the active development of 8u212, well before it was released. It in no way identifies an OpenJDK 8u release, and has no "release with this tag exists" implications. An entire month of additional code development and integration followed this tag point, before an actual release was arrived at, declared, and tagged. The 8u project tags source code at various points in time on the way to eventual release, and has done so for many years. Tags are often chosen at arbitrary points in time (e.g. they might appear weekly during a rampdown period). See example of when tags are used in a weekly progression: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009309.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009360.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009388.html 8u212-b01 was used in e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008939.html and nothing in the 8u-dev list attempted to indicate any sort of release (not even an "EA" thing) at the time. > > Thanks, > Florian From gil at azul.com Tue May 28 16:09:26 2019 From: gil at azul.com (Gil Tene) Date: Tue, 28 May 2019 16:09:26 +0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> Message-ID: <0EDB372B-2A7E-49EA-9E45-0CD183BD3A99@azul.com> > On May 27, 2019, at 3:19 AM, Martijn Verburg wrote: > > On Mon, 27 May 2019 at 11:13, Florian Weimer > wrote: > * Gil Tene: > > > root at 020dc36b9046:/# java -version > > openjdk version "1.8.0_212" > > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > > root at 020dc36b9046:/# > > I wonder if the core technical issue is this: Debian stretch currently > packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or > 8u212-b04 (which one isn't clear, the release announcement > > > was for 8u212-b03, not for 8u212-b04 or 8u212-ga). > > My understanding is that 8u212-b01 is a version identifier created by > the jdk8u project, and based on a quick check, it matches what Debian > identifies as its upstream sources (except for some stripping of system > library components). But it's not the most current release. > > It's one of the challenges, the rest of the world doesn't necessarily know about the new `-ga` tag that we use to designate releases, so we need to go and help them. Let's be clear about what the new (as in "additional") -ga tag is, in order to avoid the misunderstanding (that you can see in other threads) that somehow OpenJDK has just now started declaring releases: The notion of a "-ga" tag was added recently as a convenience mechanism to help people "identify snapshots of GA releases in Mercurial history without having to know the build number of the GA release". (see https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/007940.html for initial discussion). To quote from there: "For example, to obtain JDK 10.0.2 GA sources today, one issues the `hg update -r jdk-10.0.2+13` command. With the proposed enhancement, `hg update -r jdk-10.0.2-ga` could have been used." [GA and other] Releases existed long before this tag was added, and every [GA and other] Release has a known tag number. The "-ga" tag is a welcome addition, and makes it much easier (fewer steps) to find the sources for a release, as well as programmatically watch for ones to appear. > > I've also replied separately to this thread (with a meeting request) but cut out the OpenJDK mailing lists as it's really the Debian distro list that we should be discussing this on. > If folks feel otherwise, let me know and I'll CC these lists back in. > > Cheers, > Martijn > > > Thanks, > Florian From ali.ince at gmail.com Tue May 28 16:36:03 2019 From: ali.ince at gmail.com (=?utf-8?Q?Ali_=C4=B0nce?=) Date: Tue, 28 May 2019 17:36:03 +0100 Subject: Backport of 8217707 In-Reply-To: References: <5ce9764f.1c69fb81.86df5.a0bb@mx.google.com> <20182023-29cb-cace-c072-52e38d4e2064@redhat.com> <329be61e-07e5-0cb9-7e13-4a6201521237@redhat.com> Message-ID: Thanks Aleksey. > On 28 May 2019, at 10:39, Aleksey Shipilev wrote: > >> On 5/28/19 11:16 AM, Aleksey Shipilev wrote: >>> On 5/28/19 11:12 AM, Andrew Haley wrote: >>>> On 5/25/19 6:07 PM, Ali Ince wrote: >>>> I would like to request backport of this fix to 11u and 12u. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217707 >>>> Fix: http://hg.openjdk.java.net/jdk/jdk/rev/3a217bbdd3a2 >>>> >>>> The patch itself applies cleanly to both repos. >>> >>> The patch is approved for 11u. However, there is no-one whose job it >>> is to push it. I might be able to get to it today, but I'm not >>> promising anything. >> >> I'll push it to 11u, and I am able to run x86_32 builds too. > > And done: > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/eb1e977b8126 > > -Aleksey > From goetz.lindenmaier at sap.com Tue May 28 16:46:19 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 28 May 2019 16:46:19 +0000 Subject: Reminder: jdk 11.0.4 rampdown starts Tuesday, May 28, 18:00 CET. In-Reply-To: References: Message-ID: Hi, Tag jdk-11.0.4+5 reached the repository jdk11u-dev. Jdk11u-dev is closed now until tag jdk-11.0.5+0 arrives there Within the next days. Please don't push to jdk11u-dev until that happened. Remember you need jdk11u-critical-yes tag to push to repository jdk11u. Best regards, Goetz. From: Lindenmaier, Goetz Sent: Thursday, May 23, 2019 4:54 PM To: jdk-updates-dev at openjdk.java.net Subject: Reminder: jdk 11.0.4 rampdown starts Tuesday, May 28, 18:00 CET. Hi, I would like to remind everybody who is working on jdk 11 updates that Rampdown of 11.0.4 starts next Tuesday, May 28, at 18:00 CET. At that point in time the last merge from jdk11u-dev to jdk11u will take place. Please push all changes you want to get to 11.0.4 before that date. After that, changes for jdk11u must be requested with jdk11u-critical-request tags, and they need to be pushed directly to jdk11u. Also, please don't push to jdk11u-dev after this date until tag 11.0.5+0 arrived in the repo. This should happen soon after, though. Best regards, Goetz From goetz.lindenmaier at sap.com Tue May 28 16:52:59 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 28 May 2019 16:52:59 +0000 Subject: Please trigger update of JBS 11 update version Message-ID: Hi Andrew, Could you please trigger the update of JBS to tag changes pushed to jdk11u-dev with 11.0.5? See also http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-May/001232.html Once this is done, I would push tag 11.0.5+0 and 8224838: Bump update version for OpenJDK: jdk-11.0.5 https://bugs.openjdk.java.net/browse/JDK-8224838 Thanks and best regards, Goetz. From gnu.andrew at redhat.com Tue May 28 17:02:57 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 18:02:57 +0100 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: References: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> Message-ID: On 28/05/2019 16:04, Langer, Christoph wrote: > Hi Andrew, > > I just took over your changes from the OpenJDK 8 Updates Wiki to the OpenJDK11 pages. Thanks for the nice update. Now the pages reflect the current process and their readability has significantly increased ?? > > As for the tagging then I think we have agreed to start with tagging in the dev branches the week after GA of the previous release. And when no changes occurred then we'd skip a tag and announce that on the mailing lists. This is what's written down in the Wiki. I fully share your arguments below. > > Best regards > Christoph > Thanks! :) I didn't want to make changes to the 11u version, as I think it's better that it reflects the mind of the person doing the work, but I'm glad you found my changes helpful in updating 11u. -- 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 May 28 17:06:54 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 18:06:54 +0100 Subject: [11u] RFR: 8224880: backport of AArch64: java/javac error with AllocatePrefetchDistance Message-ID: <1cb3bebc-2ac6-b3e3-bb28-6dc87bd7bfd8@redhat.com> Patch applies cleanly. Webrev: http://cr.openjdk.java.net/~aph/8224880/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue May 28 17:12:18 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 18:12:18 +0100 Subject: [11u] RFR: 8224671: AArch64: mauve System.arraycopy test failure Message-ID: Patch applies cleanly. https://bugs.openjdk.java.net/browse/JDK-8224671 http://cr.openjdk.java.net/~aph/8224671/jdk-test.changeset -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Tue May 28 22:08:16 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 23:08:16 +0100 Subject: [11u] RFR: 8224474: harfbuzz 2.3.1 code fails to compile with gcc 4.4.7 In-Reply-To: References: Message-ID: On 21/05/2019 10:33, Severin Gehwolf wrote: > Hi, > > Could I please get a review for this JDK 11u only fix? harfbuzz has > been upgraded to 2.3.1 between jdk-11.0.4+2 and jdk-11.0.4+3. > Unfortunately, this breaks the JDK 11u build on CentOS/RHEL 6 with > system GCC 4.4.7 which the upstream OpenJDK 11u builds machinery uses. > > The fix is rather trivial: Move GCC pragmas outside functions. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8224474/01/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8224474 > > Testing: release/slowdebug builds on Linux x86_64 with gcc 4.4.7. > fastdebug build on Linux x86_64 with gcc 8.3.1 > > Thoughts? > > Thanks, > Severin > The HarfBuzz update (JDK-8210782) went to 12 & 13 as well. Should this not go there as well, or do we not want to support this older GCC on > 11? -- 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 Wed May 29 15:39:01 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 May 2019 16:39:01 +0100 Subject: JDK11u tree is *NOT* open for pushes Message-ID: <743a32dc-92d3-3a4a-b245-3d886204377e@redhat.com> FYI. It's waiting for Goetz to merge into the master branch, and ops to change the JBS tag to 11.0.5. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu May 30 08:09:12 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 May 2019 09:09:12 +0100 Subject: jdk11u-dev is now switched to 11.0.5 Message-ID: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> jdk-updates/jdk11u-dev config updates to use 11.0.5. That is all. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martijnverburg at gmail.com Thu May 30 16:18:32 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 30 May 2019 17:18:32 +0100 Subject: OpenJDK 8u/11u release information In-Reply-To: <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> References: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> Message-ID: @Gil - this is the clearest answer I've seen yet, thank you! - would you be OK if we cribbed this and put it into a common wiki or in the README for OpenJDK? Cheers, Martijn On Tue, 28 May 2019 at 01:52, Gil Tene wrote: > > > > On May 27, 2019, at 6:34 AM, Matthias Klose wrote: > > > > Hi guys, > > The following is meant to be constructive and informational, so please > don't > read it as anything other than that. With that said, any and all "you are > plain > wrong, and here is why" followups to what I say below are welcome. > > > > > until recently we didn't have any source code releases for OpenJDK at > all. > > Not sure what you mean by this. Can you clarify what you mean when you > use the term "source code releases"? And how the thing you mean differs > from historical practice in OpenJDK? > > By my understanding OpenJDK, as a source code project, has been producing > source code releases pretty much since OpenJDK 6 was first > released, and has never stopped doing so, with continuing update releases > happening within major version project on a pretty regular basis. > > Version formats have changed across major java versions, tagging and > development processes going into a release also evolved and changed over > time. But at all points in the past several years, it's been pretty clear > when a > release happened, and what the source code for that release actually was. > > Binary builds of those released sources have been around for quite a > while as well. But in the past, these may not have been created > consistently > by the project lead for every update. > > What is "new" (AFAIK), specifically in 8u and 11u (and not in other > projects > thus far), is the posting of project-lead blessed, TCK-tested builds of > "vanilla" > released (as well as EA) sources of 8u and 11u (see e.g. > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009105.html > and subsequent discussions) at some external location. That's a very > positive > development, which I certainly hope will last and continue. But as noted in > that e-mail thread, those binaries are simply good, fully-TCK-tested > builds of > the released sources, posted to a known location. They did not change the > release process in any way. > > > I appreciate the effort to have source releases, however the gap to > produce > > binaries based on the source release is way to high. Instead of having > a dozen > > of configuration options to build a binary, please can we have a default > option > > which builds consumable packages by default? > > As things stand, across the various java version projects, the default > build modes > for all sources (including releases) produce consumable-by-the-builder > things, > intentionally labeled in ways that would scare people away from using the > bits as > a release. This is intentional, and is aimed to make sure that things that > look > like an actual release will only happen through intent, assertive actions > and > real choices about reported versions. > > E.g., when I build things using the defaults, I'd get stuff like: > > # bash ./configure > # make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-gil_2019_05_27_10_48-b00) > OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) > > And that's a good thing. It prevents the accidental leakage of unfinished > bits > to others. > > To produce things you would give other people ("consumable" by others), > you need to intentionally make assertive (non-default) choices about > configuration. Normally, stating your update version, build version, and > milestone (or "pre" version) at the very least, and likely things like > vendor version, etc. Non of those have good "defaults", as you don't > want any of those to appear "by accident" in a build. > > The same is true for the sources of the actual quarterly releases, which > are > no more than a snapshot of the sources at the release point. > > To create a binary build that does not carry the "-internal" > identification, and > that has specific update and build numbers, you have to assertively > declare those > in the build configuration. But that's not very complicated. E.g. > > # bash ./configure --with-update-version=972 --with-build-number=b41 > --with-milestone="snapshot" > # make clean; make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0_972-snapshot" > OpenJDK Runtime Environment (build 1.8.0_972-snapshot-b41) > OpenJDK 64-Bit Server VM (build 25.972-b41, mixed mode) > > And with the special milestone called "fcs": > > # bash ./configure --with-update-version=982 --with-build-number=b42 > --with-milestone="fcs" > # make clean; make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0_982" > OpenJDK Runtime Environment (build 1.8.0_982-b42) > OpenJDK 64-Bit Server VM (build 25.982-b42, mixed mode) > > Note: > For OpenJDK 8u "fcs" is a special milestone. It is the specific thing you > need to do to > get rid of the milestone part of the versions string. Any other value > (including "", which > will revert to "internal") will show up in the version, because of this in > common/autoconf/spec.gmk.in : > > # These variables need to be generated here so that MILESTONE and > # JDK_BUILD_NUMBER can be overridden on the make command line. > ifeq ($(MILESTONE), fcs) > RELEASE=$(JDK_VERSION)$(BUILD_VARIANT_RELEASE) > else > RELEASE=$(JDK_VERSION)-$(MILESTONE)$(BUILD_VARIANT_RELEASE) > endif > > 11u is a little different. The release versioning is more specifically > defined (JEP322), > and the term for that "disqualifier" part for the version that tells you > it is not an > actual release (what 8u sets using --with-milestone) is the "pre-release > identifier" > ($PRE) part of the version string (set --with-version-pre). > > The default behaves the same with regards to "-internal" in the sense that > $PRE defaults > to "internal", a =nd must be assertively set to "" to get rid of it. But > in 11u a default for the > UPDATE portion of the JEP322 version string is typically baked into > make/autoconf/version-numbers (as opposed to having to be set via > --with-update-version > in 8u) > > so e.g.: > > # bash ./configure > # make all > # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "11.0.3-internal" 2019-04-16 > OpenJDK Runtime Environment (build 11.0.3-internal+0-adhoc.gil.11u1103rel) > OpenJDK 64-Bit Server VM (build 11.0.3-internal+0-adhoc.gil.11u1103rel, > mixed mode) > > But when you build something that is fit for others to consume, you will > still want to provide > a build number with --with-build-number, use -with-version-pre="" if you > want to say it is an > actual release (use e.g. "ea", or just leave blank to make it "internal" > otherwise), and in > addition set --with-version-opt to control that thing that defaults to > "adhoc.$USERNAME.$basedirname". Finally, > --with-vendor-version-string="18.9" is > considered "vanilla" (the year.month for Java SE 11), and that's where > non-vanilla > distros tend put their name in. > > So e.g.: > > # bash ./configure --with-version-build=42 --with-version-opt="" > --with-version-pre="" --with-vendor-version-string="18.9" > # make all > # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment 18.9 (build 11.0.3+42) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+42, mixed mode) > > > > > OpenJDK doesn't have source releases until recently. Now we have, and > from my > > point of view, such a source release should only have a minimal set of > > configuration options to build a usable image. Things I would like to > see > > > > - I see it's important to display the version string as the first line > > of java -version. The source release should set that correctly. > > See above discussion about why (by long standing OpenJDK historical > practice) version strings are controlled by the build configuration, and > not > by the source code of a release. > > > > > - The OpenJDK source release ships with the vendor set to Oracle. > > Distributors set that to Azul, AdoptJDK, Debian, and probably other > > values. The binaries built by the OpenJDK itself set that to some > > sort of version string. An "unknown" vendor causes issue, because some > > software (LibreOffice, Gradle) uses or at least used that to check > > for a valid java installation. > > I'll assume you are referring to the "18.9" part in the version string > reported > by the "blessed by project lead" builds of the OpenJDK 11u 11.0.3 release: > > # ./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) > > That 18.9 part is the "vendor version string" as defined by JEP322 (a new > property that did not exist in 8u). The choice of "18.9" (the year.month > that > Java SE 11 was released) is both the actual example vendor version string > shown in the JEP, and follows the precedent already set for "vanilla" > OpenJDK > builds of 11, 11.0.1, and 11.0.2 produced by the previous project lead > during > the first 6 months of 11u. (note that those were the OpenJDK build posted > by > Oracle, not the Oracle JDK builds). > > Since "18.9" was there as a vendor version string form the very start of > OpenJDK 11, we can assume that anything that knows how to parse JEP322 > versions will not have a problem with it. > > > > > - The version number should be used for both the source release and the > > binary package. E.g. the 11.0.3 source release is missing the -ga > > modifier. > > I'll assume that you are referring to version string reported by the > binary, > e.g. in response to -version, and not to package names, file names, or tags > in source control. > > The version string conventions for each existing Java SE version are > already established, and they (unfortunately) differ by major version. Thus > far, for all Java SE versions I know of which had an OpenJDK project > (6, 7, 8, 9, 10, 11, 12), neither Oracle nor OpenJDK builds have included a > positive (e.g. "-ga") indicator in the version strings of actually-released > versions. Instead, the long standing convention has been to include a > disqualifier ("-ea", "-internal", "-rc1") in non-released builds. The build > system defaults to using the -internal qualifier in all versions to date. > > Thus the current output from the project-lead blessed builds of 8u212 is: > # java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-b04) > OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) > > (which, since there is no "disqualifier" in the version, means that it > reports as a build of an actual release). > > The technical term for this "disqualifier" has varied over the years. As > shown above, 8u calls it "milestone", 11u calls it a "pre-release > identifier". > But in all versions so far, *not* having it there means that it is a > release. > > Changing version string formats and conventions for indicating things > within a major java version is a generally bad idea. Adding "-ga" to actual > update releases of existing Java SE major versions is likely to blow up > a whole bunch of things. For one: a common ways to determine > that a version of OpenJDK or Oracle JDK is an actual released version > (as opposed to some ea/beta/rc1/internal/experimental thing) is to verify > that there is no "-XYZ" part (the milestone or $PRE) in the version string. > > Making changes to conventions across versions is quite possible, and > has been done multiple times (e.g. JEP 322, JEP 223). JEP 322 is what > we currently follow for 11u and above. If it insufficient for some reason, > and we want to change it yet again for e.g. OpenJDK 14, that's something > to discuss, I guess., But such changes should not affect existing Java SE > versions (12 and below). > > > > > - To include a package in a Linux distro, you have to use a monotonically > > increasing version number, and you have to follow the versioning > > constraints for the distro. So sometimes you have to juggle with the > > version numbers. E.g. for Debian/Ubuntu a second dash is problematic > > for version comparisons. I consider uploads to a development distro > > as essential, so I have to plan for these version numbers as well. > > Last time when I asked on the mailing lists, people seemed to be fine > > with the versioning, however if needed, we could document such > > versioning on the OpenJDK wiki? > > This is a good point (make sure your *package* names retain monotonically > growing version numbers), but since these rules apply to the package names > as seen by the distro (and not to the version strings) simple > distro-specific file > name conversion conventions seem to suffice. This is often necessary simply > because conventions and file name requirements can vary widely > between OSs (some don't like dots, some don't like dashes, some deal with > capitalization in interesting ways). > > E.g. you can convert every dash in the version string to to an underscore > in > the .deb or .rpm package names. > > An interesting problem shows up if the parsing of the version string > related fields appears to "go backwards" in your monotonic comparisons > (e.g. if the sorting is text based rather than numeric, and 11.0.10 would > be > considered earlier than 11.0.9, or 8u92 was considered to come after > 8u102). > I can think of a few ways to resolve that with package name conventions, > but I don't really know if this is a problem. Does debian compare > numeric sequence substrings in package name numerically, or > lexicographically? > > > > > - It would be very helpful to see directly in the binary how the build > > was configured. GCC is showing this information with > > gcc -v > > Python is showing that with > > python -c 'import sysconfig; > print(sysconfig.get_config_var("CONFIG_ARGS"))' > > Or maybe this already exists? > > > > Usually binaries in a distro come with a changelog, however sometimes > > even that is stripped away by re-distributors of binaries. > > > > - The configure system has some issues with invalid configure arguments, > e.g. > > configuring --with-version-build='' leads to a failing build. > > Setting --with-version-build="" works on 8u (it is a string). > > In 11u, you'd use --with-version-build=0 (it is an integer). > > > > > Matthias > > From gil at azul.com Thu May 30 16:32:32 2019 From: gil at azul.com (Gil Tene) Date: Thu, 30 May 2019 16:32:32 +0000 Subject: OpenJDK 8u/11u release information In-Reply-To: References: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> Message-ID: <26ACCD96-6EC2-417E-8307-03A8933A53D1@azul.com> Sure! > On May 30, 2019, at 9:18 AM, Martijn Verburg wrote: > > @Gil - this is the clearest answer I've seen yet, thank you! - would you be OK if we cribbed this and put it into a common wiki or in the README for OpenJDK? > > Cheers, > Martijn > > > On Tue, 28 May 2019 at 01:52, Gil Tene > wrote: > > > > On May 27, 2019, at 6:34 AM, Matthias Klose > wrote: > > > > Hi guys, > > The following is meant to be constructive and informational, so please don't > read it as anything other than that. With that said, any and all "you are plain > wrong, and here is why" followups to what I say below are welcome. > > > > > until recently we didn't have any source code releases for OpenJDK at all. > > Not sure what you mean by this. Can you clarify what you mean when you > use the term "source code releases"? And how the thing you mean differs > from historical practice in OpenJDK? > > By my understanding OpenJDK, as a source code project, has been producing > source code releases pretty much since OpenJDK 6 was first > released, and has never stopped doing so, with continuing update releases > happening within major version project on a pretty regular basis. > > Version formats have changed across major java versions, tagging and > development processes going into a release also evolved and changed over > time. But at all points in the past several years, it's been pretty clear when a > release happened, and what the source code for that release actually was. > > Binary builds of those released sources have been around for quite a > while as well. But in the past, these may not have been created consistently > by the project lead for every update. > > What is "new" (AFAIK), specifically in 8u and 11u (and not in other projects > thus far), is the posting of project-lead blessed, TCK-tested builds of "vanilla" > released (as well as EA) sources of 8u and 11u (see e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009105.html > and subsequent discussions) at some external location. That's a very positive > development, which I certainly hope will last and continue. But as noted in > that e-mail thread, those binaries are simply good, fully-TCK-tested builds of > the released sources, posted to a known location. They did not change the > release process in any way. > > > I appreciate the effort to have source releases, however the gap to produce > > binaries based on the source release is way to high. Instead of having a dozen > > of configuration options to build a binary, please can we have a default option > > which builds consumable packages by default? > > As things stand, across the various java version projects, the default build modes > for all sources (including releases) produce consumable-by-the-builder things, > intentionally labeled in ways that would scare people away from using the bits as > a release. This is intentional, and is aimed to make sure that things that look > like an actual release will only happen through intent, assertive actions and > real choices about reported versions. > > E.g., when I build things using the defaults, I'd get stuff like: > > # bash ./configure > # make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-gil_2019_05_27_10_48-b00) > OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) > > And that's a good thing. It prevents the accidental leakage of unfinished bits > to others. > > To produce things you would give other people ("consumable" by others), > you need to intentionally make assertive (non-default) choices about > configuration. Normally, stating your update version, build version, and > milestone (or "pre" version) at the very least, and likely things like > vendor version, etc. Non of those have good "defaults", as you don't > want any of those to appear "by accident" in a build. > > The same is true for the sources of the actual quarterly releases, which are > no more than a snapshot of the sources at the release point. > > To create a binary build that does not carry the "-internal" identification, and > that has specific update and build numbers, you have to assertively declare those > in the build configuration. But that's not very complicated. E.g. > > # bash ./configure --with-update-version=972 --with-build-number=b41 --with-milestone="snapshot" > # make clean; make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0_972-snapshot" > OpenJDK Runtime Environment (build 1.8.0_972-snapshot-b41) > OpenJDK 64-Bit Server VM (build 25.972-b41, mixed mode) > > And with the special milestone called "fcs": > > # bash ./configure --with-update-version=982 --with-build-number=b42 --with-milestone="fcs" > # make clean; make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0_982" > OpenJDK Runtime Environment (build 1.8.0_982-b42) > OpenJDK 64-Bit Server VM (build 25.982-b42, mixed mode) > > Note: > For OpenJDK 8u "fcs" is a special milestone. It is the specific thing you need to do to > get rid of the milestone part of the versions string. Any other value (including "", which > will revert to "internal") will show up in the version, because of this in common/autoconf/spec.gmk.in : > > # These variables need to be generated here so that MILESTONE and > # JDK_BUILD_NUMBER can be overridden on the make command line. > ifeq ($(MILESTONE), fcs) > RELEASE=$(JDK_VERSION)$(BUILD_VARIANT_RELEASE) > else > RELEASE=$(JDK_VERSION)-$(MILESTONE)$(BUILD_VARIANT_RELEASE) > endif > > 11u is a little different. The release versioning is more specifically defined (JEP322), > and the term for that "disqualifier" part for the version that tells you it is not an > actual release (what 8u sets using --with-milestone) is the "pre-release identifier" > ($PRE) part of the version string (set --with-version-pre). > > The default behaves the same with regards to "-internal" in the sense that $PRE defaults > to "internal", a =nd must be assertively set to "" to get rid of it. But in 11u a default for the > UPDATE portion of the JEP322 version string is typically baked into > make/autoconf/version-numbers (as opposed to having to be set via --with-update-version > in 8u) > > so e.g.: > > # bash ./configure > # make all > # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "11.0.3-internal" 2019-04-16 > OpenJDK Runtime Environment (build 11.0.3-internal+0-adhoc.gil.11u1103rel) > OpenJDK 64-Bit Server VM (build 11.0.3-internal+0-adhoc.gil.11u1103rel, mixed mode) > > But when you build something that is fit for others to consume, you will still want to provide > a build number with --with-build-number, use -with-version-pre="" if you want to say it is an > actual release (use e.g. "ea", or just leave blank to make it "internal" otherwise), and in > addition set --with-version-opt to control that thing that defaults to > "adhoc.$USERNAME.$basedirname". Finally, --with-vendor-version-string="18.9" is > considered "vanilla" (the year.month for Java SE 11), and that's where non-vanilla > distros tend put their name in. > > So e.g.: > > # bash ./configure --with-version-build=42 --with-version-opt="" --with-version-pre="" --with-vendor-version-string="18.9" > # make all > # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment 18.9 (build 11.0.3+42) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+42, mixed mode) > > > > > OpenJDK doesn't have source releases until recently. Now we have, and from my > > point of view, such a source release should only have a minimal set of > > configuration options to build a usable image. Things I would like to see > > > > - I see it's important to display the version string as the first line > > of java -version. The source release should set that correctly. > > See above discussion about why (by long standing OpenJDK historical > practice) version strings are controlled by the build configuration, and not > by the source code of a release. > > > > > - The OpenJDK source release ships with the vendor set to Oracle. > > Distributors set that to Azul, AdoptJDK, Debian, and probably other > > values. The binaries built by the OpenJDK itself set that to some > > sort of version string. An "unknown" vendor causes issue, because some > > software (LibreOffice, Gradle) uses or at least used that to check > > for a valid java installation. > > I'll assume you are referring to the "18.9" part in the version string reported > by the "blessed by project lead" builds of the OpenJDK 11u 11.0.3 release: > > # ./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) > > That 18.9 part is the "vendor version string" as defined by JEP322 (a new > property that did not exist in 8u). The choice of "18.9" (the year.month that > Java SE 11 was released) is both the actual example vendor version string > shown in the JEP, and follows the precedent already set for "vanilla" OpenJDK > builds of 11, 11.0.1, and 11.0.2 produced by the previous project lead during > the first 6 months of 11u. (note that those were the OpenJDK build posted by > Oracle, not the Oracle JDK builds). > > Since "18.9" was there as a vendor version string form the very start of > OpenJDK 11, we can assume that anything that knows how to parse JEP322 > versions will not have a problem with it. > > > > > - The version number should be used for both the source release and the > > binary package. E.g. the 11.0.3 source release is missing the -ga > > modifier. > > I'll assume that you are referring to version string reported by the binary, > e.g. in response to -version, and not to package names, file names, or tags > in source control. > > The version string conventions for each existing Java SE version are > already established, and they (unfortunately) differ by major version. Thus > far, for all Java SE versions I know of which had an OpenJDK project > (6, 7, 8, 9, 10, 11, 12), neither Oracle nor OpenJDK builds have included a > positive (e.g. "-ga") indicator in the version strings of actually-released > versions. Instead, the long standing convention has been to include a > disqualifier ("-ea", "-internal", "-rc1") in non-released builds. The build > system defaults to using the -internal qualifier in all versions to date. > > Thus the current output from the project-lead blessed builds of 8u212 is: > # java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-b04) > OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) > > (which, since there is no "disqualifier" in the version, means that it > reports as a build of an actual release). > > The technical term for this "disqualifier" has varied over the years. As > shown above, 8u calls it "milestone", 11u calls it a "pre-release identifier". > But in all versions so far, *not* having it there means that it is a release. > > Changing version string formats and conventions for indicating things > within a major java version is a generally bad idea. Adding "-ga" to actual > update releases of existing Java SE major versions is likely to blow up > a whole bunch of things. For one: a common ways to determine > that a version of OpenJDK or Oracle JDK is an actual released version > (as opposed to some ea/beta/rc1/internal/experimental thing) is to verify > that there is no "-XYZ" part (the milestone or $PRE) in the version string. > > Making changes to conventions across versions is quite possible, and > has been done multiple times (e.g. JEP 322, JEP 223). JEP 322 is what > we currently follow for 11u and above. If it insufficient for some reason, > and we want to change it yet again for e.g. OpenJDK 14, that's something > to discuss, I guess., But such changes should not affect existing Java SE > versions (12 and below). > > > > > - To include a package in a Linux distro, you have to use a monotonically > > increasing version number, and you have to follow the versioning > > constraints for the distro. So sometimes you have to juggle with the > > version numbers. E.g. for Debian/Ubuntu a second dash is problematic > > for version comparisons. I consider uploads to a development distro > > as essential, so I have to plan for these version numbers as well. > > Last time when I asked on the mailing lists, people seemed to be fine > > with the versioning, however if needed, we could document such > > versioning on the OpenJDK wiki? > > This is a good point (make sure your *package* names retain monotonically > growing version numbers), but since these rules apply to the package names > as seen by the distro (and not to the version strings) simple distro-specific file > name conversion conventions seem to suffice. This is often necessary simply > because conventions and file name requirements can vary widely > between OSs (some don't like dots, some don't like dashes, some deal with > capitalization in interesting ways). > > E.g. you can convert every dash in the version string to to an underscore in > the .deb or .rpm package names. > > An interesting problem shows up if the parsing of the version string > related fields appears to "go backwards" in your monotonic comparisons > (e.g. if the sorting is text based rather than numeric, and 11.0.10 would be > considered earlier than 11.0.9, or 8u92 was considered to come after 8u102). > I can think of a few ways to resolve that with package name conventions, > but I don't really know if this is a problem. Does debian compare > numeric sequence substrings in package name numerically, or > lexicographically? > > > > > - It would be very helpful to see directly in the binary how the build > > was configured. GCC is showing this information with > > gcc -v > > Python is showing that with > > python -c 'import sysconfig; print(sysconfig.get_config_var("CONFIG_ARGS"))' > > Or maybe this already exists? > > > > Usually binaries in a distro come with a changelog, however sometimes > > even that is stripped away by re-distributors of binaries. > > > > - The configure system has some issues with invalid configure arguments, e.g. > > configuring --with-version-build='' leads to a failing build. > > Setting --with-version-build="" works on 8u (it is a string). > > In 11u, you'd use --with-version-build=0 (it is an integer). > > > > > Matthias > From goetz.lindenmaier at sap.com Thu May 30 21:15:17 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 30 May 2019 21:15:17 +0000 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> Message-ID: Hi Andrew, (sorry for the double mail, resent this to all.) > The level of bureaucratic overhead in these projects is getting absurd. We're > going to have to do something about it before we all drown. Yes, there is some overhead, it does not make things more simple. You could delegate some tasks. E.g., * I would volunteer to trigger the update of the JBS version For 11 whenever needed. * You could allow to push the version bump without jdk11u-fix-yes tag. It's obvious we need it. Further, I would propose that we exclude all changes Oracle pushes to their 11.0.x from the tagging if pushed to the open 11.0.x (same x!). They have already been judged to be good for downport by Oracle. The "Fix Request" comment should be added to the change nevertheless. This way one can know that a change is being worked on. Maybe we should note in the bug that it is a downport that went to Oracle's 11.0.x, so it's clear why it is not tagged. Best regards, Goetz. > -----Original Message----- > From: Andrew Haley > Sent: Thursday, May 30, 2019 11:17 AM > To: Lindenmaier, Goetz > Subject: Re: jdk11u-dev is now switched to 11.0.5 > > On 5/30/19 9:44 AM, Lindenmaier, Goetz wrote: > > > Could you please tag > > https://bugs.openjdk.java.net/browse/JDK-8224838 > > 8224838: Bump update version for OpenJDK: jdk-11.0.5 > > Done. > > The level of bureaucratic overhead in these projects is getting absurd. We're > going to have to do something about it before we all drown. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Thu May 30 21:21:25 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 30 May 2019 21:21:25 +0000 Subject: jdk11u-dev open for pushes for jdk-11.0.5 Message-ID: Hi, Development of jdk-11.0.5 in jdk11u-dev is started. Tag 11.0.5+0 arrived there. Jdk11u is in rampdown now. Fixes pushed to jdk11u will be merged to jdk11u-dev with every new tag. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Tuesday, May 28, 2019 6:46 PM > To: 'jdk-updates-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: [CAUTION] RE: Reminder: jdk 11.0.4 rampdown starts Tuesday, May > 28, 18:00 CET. > > Hi, > > Tag jdk-11.0.4+5 reached the repository jdk11u-dev. > Jdk11u-dev is closed now until tag jdk-11.0.5+0 arrives there > Within the next days. > > Please don't push to jdk11u-dev until that happened. > > Remember you need jdk11u-critical-yes tag to push to > repository jdk11u. > > Best regards, > Goetz. > > > From: Lindenmaier, Goetz > Sent: Thursday, May 23, 2019 4:54 PM > To: jdk-updates-dev at openjdk.java.net > Subject: Reminder: jdk 11.0.4 rampdown starts Tuesday, May 28, 18:00 CET. > > Hi, > > I would like to remind everybody who is working on jdk 11 updates > that Rampdown of 11.0.4 starts next Tuesday, May 28, at 18:00 CET. > > At that point in time the last merge from jdk11u-dev to jdk11u > will take place. Please push all changes you want to get to 11.0.4 > before that date. > > After that, changes for jdk11u must be requested with jdk11u-critical- > request > tags, and they need to be pushed directly to jdk11u. > > Also, please don't push to jdk11u-dev after this date until tag 11.0.5+0 > arrived in the repo. This should happen soon after, though. > > Best regards, > Goetz > From christoph.langer at sap.com Thu May 30 21:56:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 30 May 2019 21:56:48 +0000 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> Message-ID: Hi, > > The level of bureaucratic overhead in these projects is getting absurd. > We're > > going to have to do something about it before we all drown. > > Yes, there is some overhead, it does not make things more > simple. You could delegate some tasks. > > E.g., > * I would volunteer to trigger the update of the JBS version > For 11 whenever needed. > * You could allow to push the version bump without > jdk11u-fix-yes tag. It's obvious we need it. > > Further, I would propose that we exclude all changes Oracle > pushes to their 11.0.x from the tagging if pushed to > the open 11.0.x (same x!). > They have already been judged to be good for downport by Oracle. > The "Fix Request" comment should be added to the change > nevertheless. This way one can know that a change is being > worked on. Maybe we should note in the bug that it is a downport > that went to Oracle's 11.0.x, so it's clear why it is not tagged. Those seem good suggestions to me. I also think that you could extend the group of maintainers, that is, people who can approve backports. Andrew (Hughes) is already listed for 8u but 11u could also use additional approvers. However, if you do that, you should give some rules and criteria that the approvers have to follow. Best regards Christoph From christoph.langer at sap.com Fri May 31 06:59:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 31 May 2019 06:59:27 +0000 Subject: RFR: [11u, 12u] JDK-8170639: [Linux] jsig is limited to a maximum of 64 signals In-Reply-To: References: Message-ID: Hi Ao Qi, I have reviewed your backport change and it looks good to me. The changes to os::Posix::init_2(void) seem correctly resolved. I have seen that you've set the fix-request label. So I will take the patch into our testing system and once there is approval in the bug and testing shows no regressions, I'll push this. Thanks for your contribution to OpenJDK 11 Updates ?? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ao Qi > Sent: Mittwoch, 27. M?rz 2019 11:00 > To: jdk-updates-dev at openjdk.java.net > Subject: RFR: [11u, 12u] JDK-8170639: [Linux] jsig is limited to a maximum of > 64 signals > > Hi, > > I'd like to backport this change to 11u and 12u: > > Original JBS: > https://bugs.openjdk.java.net/browse/JDK-8170639 > > Original change: > http://hg.openjdk.java.net/jdk/jdk/rev/3086f9259e97 > (http://cr.openjdk.java.net/~aoqi/8170639/webrev.03/) > > Original review threads: > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018- > December/031839.html > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019- > March/032909.html > > Patch does not apply cleanly, because of minor changes in > os::Posix::init_2(void) introduced by JDK-8194860. > > 12u change: > http://cr.openjdk.java.net/~aoqi/8170639/webrev.12u.03/ > > Tested: linux-x86_64-{server, minimal, zero}-{release, fastdebug} > build, solaris-x86_64-server-release build, > linux-mips64el-zero-release build, linux-x86_64-server-release tier1 > > May I also request to backport this fix to 11u? > http://cr.openjdk.java.net/~aoqi/8170639/webrev.12u.03 apply to > jdk11u-dev cleanly. > > jdk11u-dev tested: linux-x86_64-{server, minimal, zero}-{release, > fastdebug} build, solaris-x86_64-server-release build, > linux-x86_64-server-release tier1 > > Thanks, > Ao Qi From aoqi at loongson.cn Fri May 31 07:54:57 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 31 May 2019 15:54:57 +0800 Subject: RFR: [11u, 12u] JDK-8170639: [Linux] jsig is limited to a maximum of 64 signals In-Reply-To: References: Message-ID: On Fri, May 31, 2019 at 2:59 PM Langer, Christoph wrote: > Hi Ao Qi, > > I have reviewed your backport change and it looks good to me. The changes > to os::Posix::init_2(void) seem correctly resolved. > > I have seen that you've set the fix-request label. So I will take the > patch into our testing system and once there is approval in the bug and > testing shows no regressions, I'll push this. > Thank you very much, Christoph! Cheers, Ao Qi > > Thanks for your contribution to OpenJDK 11 Updates ?? > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Ao Qi > > Sent: Mittwoch, 27. M?rz 2019 11:00 > > To: jdk-updates-dev at openjdk.java.net > > Subject: RFR: [11u, 12u] JDK-8170639: [Linux] jsig is limited to a > maximum of > > 64 signals > > > > Hi, > > > > I'd like to backport this change to 11u and 12u: > > > > Original JBS: > > https://bugs.openjdk.java.net/browse/JDK-8170639 > > > > Original change: > > http://hg.openjdk.java.net/jdk/jdk/rev/3086f9259e97 > > (http://cr.openjdk.java.net/~aoqi/8170639/webrev.03/) > > > > Original review threads: > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018- > > December/031839.html > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019- > > March/032909.html > > > > Patch does not apply cleanly, because of minor changes in > > os::Posix::init_2(void) introduced by JDK-8194860. > > > > 12u change: > > http://cr.openjdk.java.net/~aoqi/8170639/webrev.12u.03/ > > > > Tested: linux-x86_64-{server, minimal, zero}-{release, fastdebug} > > build, solaris-x86_64-server-release build, > > linux-mips64el-zero-release build, linux-x86_64-server-release tier1 > > > > May I also request to backport this fix to 11u? > > http://cr.openjdk.java.net/~aoqi/8170639/webrev.12u.03 apply to > > jdk11u-dev cleanly. > > > > jdk11u-dev tested: linux-x86_64-{server, minimal, zero}-{release, > > fastdebug} build, solaris-x86_64-server-release build, > > linux-x86_64-server-release tier1 > > > > Thanks, > > Ao Qi > From martin.doerr at sap.com Fri May 31 09:51:10 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 31 May 2019 09:51:10 +0000 Subject: [11u] RFR (Backport): 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: Message-ID: Hi Christoph, backport looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Freitag, 24. Mai 2019 09:52 > To: jdk-updates-dev at openjdk.java.net > Cc: core-libs-dev > Subject: [11u] RFR (Backport): 8223553: Fix code constructs that > do not compile with the Eclipse Java Compiler > > Hi, > > I'd like to bring this fix down to jdk11 updates. Unfortunately, the webrev did > not apply cleanly in the imports section of > src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java, so > I had to resolve this part manually. I also updated the copyright year. Please > check. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.11u/ > > Thanks > Christoph From shade at redhat.com Fri May 31 12:11:19 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 31 May 2019 14:11:19 +0200 Subject: JDK11u tree is *NOT* open for pushes In-Reply-To: <743a32dc-92d3-3a4a-b245-3d886204377e@redhat.com> References: <743a32dc-92d3-3a4a-b245-3d886204377e@redhat.com> Message-ID: <3c73b54f-d4c2-973b-b0a9-062d2adda177@redhat.com> On 5/29/19 5:39 PM, Andrew Haley wrote: > FYI. It's waiting for Goetz to merge into the master branch, and ops to change the > JBS tag to 11.0.5. Just checking: jdk11u (not -dev) is open for critical fixes now, right? -Aleksey From martin.doerr at sap.com Fri May 31 12:39:34 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 31 May 2019 12:39:34 +0000 Subject: [11u] RFR: 8208698: Improved ECC Implementation In-Reply-To: References: Message-ID: Hi Christoph, looks like quite some manual resolution just because of a small conflicting change in one file. Backport looks good, but please backport it together with JDK-8217344. After that, ECDHKeyAgreement.java should be identical to the jdk13 version. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Dienstag, 28. Mai 2019 09:21 > To: jdk-updates-dev at openjdk.java.net > Cc: security-dev > Subject: [11u] RFR: 8208698: Improved ECC Implementation > > Hi, > > please review this backport of JDK-8208698: Improved ECC Implementation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208698 > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/752e57845ad2 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8208698.11u/ > > The patch did not apply cleanly because there were conflicts in > src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java > due to JDK-8205476 which is part of jdk/jdk but not of jdk11u-dev. > Unfortunately, JDK-8205476 can not be downported as prerequisite because > it brings a behavioral change and is associated with a CSR. So I resolved the > rejects manually. I add the rejects below. > > Thanks > Christoph > > > --- ECDHKeyAgreement.java > +++ ECDHKeyAgreement.java > @@ -99,42 +104,74 @@ > ("Key must be a PublicKey with algorithm EC"); > } > - ECPublicKey ecKey = (ECPublicKey)key; > - ECParameterSpec params = ecKey.getParams(); > + this.publicKey = (ECPublicKey) key; > - if (ecKey instanceof ECPublicKeyImpl) { > - publicValue = ((ECPublicKeyImpl)ecKey).getEncodedPublicValue(); > - } else { // instanceof ECPublicKey > - publicValue = > - ECUtil.encodePoint(ecKey.getW(), params.getCurve()); > - } > + ECParameterSpec params = publicKey.getParams(); > int keyLenBits = params.getCurve().getField().getFieldSize(); > secretLen = (keyLenBits + 7) >> 3; > return null; > } > + private static void validateCoordinate(BigInteger c, BigInteger mod) { > + if (c.compareTo(BigInteger.ZERO) < 0) { > + throw new ProviderException("invalid coordinate"); > + } > + > + if (c.compareTo(mod) >= 0) { > + throw new ProviderException("invalid coordinate"); > + } > + } > + > + /* > + * Check whether a public key is valid. Throw ProviderException > + * if it is not valid or could not be validated. > + */ > + private static void validate(ECOperations ops, ECPublicKey key) { > + > + // ensure that integers are in proper range > + BigInteger x = key.getW().getAffineX(); > + BigInteger y = key.getW().getAffineY(); > + > + BigInteger p = ops.getField().getSize(); > + validateCoordinate(x, p); > + validateCoordinate(y, p); > + > + // ensure the point is on the curve > + EllipticCurve curve = key.getParams().getCurve(); > + BigInteger rhs = x.modPow(BigInteger.valueOf(3), p).add(curve.getA() > + .multiply(x)).add(curve.getB()).mod(p); > + BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p); > + if (!rhs.equals(lhs)) { > + throw new ProviderException("point is not on curve"); > + } > + > + // check the order of the point > + ImmutableIntegerModuloP xElem = ops.getField().getElement(x); > + ImmutableIntegerModuloP yElem = ops.getField().getElement(y); > + AffinePoint affP = new AffinePoint(xElem, yElem); > + byte[] order = key.getParams().getOrder().toByteArray(); > + ArrayUtil.reverse(order); > + Point product = ops.multiply(affP, order); > + if (!ops.isNeutral(product)) { > + throw new ProviderException("point has incorrect order"); > + } > + > + } > + > // see JCE spec > @Override > protected byte[] engineGenerateSecret() throws IllegalStateException { > - if ((privateKey == null) || (publicValue == null)) { > + if ((privateKey == null) || (publicKey == null)) { > throw new IllegalStateException("Not initialized correctly"); > } > - byte[] s = privateKey.getS().toByteArray(); > - byte[] encodedParams = // DER OID > - ECUtil.encodeECParameterSpec(null, privateKey.getParams()); > - > - try { > - > - byte[] result = deriveKey(s, publicValue, encodedParams); > - publicValue = null; > - return result; > - > - } catch (GeneralSecurityException e) { > - throw new ProviderException("Could not derive key", e); > - } > - > + Optional resultOpt = deriveKeyImpl(privateKey, publicKey); > + byte[] result = resultOpt.orElseGet( > + () -> deriveKeyNative(privateKey, publicKey) > + ); > + publicKey = null; > + return result; > } > // see JCE spec From goetz.lindenmaier at sap.com Fri May 31 13:17:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 31 May 2019 13:17:42 +0000 Subject: JDK11u tree is *NOT* open for pushes -- both repos are open!! Message-ID: Hi, Jdk11u-dev is open for changes for 11.0.**5**. Tag jdk11u-fix-yes required! Jdk11u is open for **critical fixes** for 11.0.**4**. Tag jdk11u-critical-yes required! Jdk11u wasn't really closed. It was just pointless to push there as both repos were in complete sync for four weeks. But jdk11u-critical-yes was required all the time to push to jdk11u. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Friday, May 31, 2019 2:11 PM > To: Andrew Haley ; jdk-updates-dev at openjdk.java.net > Subject: Re: JDK11u tree is *NOT* open for pushes > > On 5/29/19 5:39 PM, Andrew Haley wrote: > > FYI. It's waiting for Goetz to merge into the master branch, and ops to > change the > > JBS tag to 11.0.5. > > Just checking: jdk11u (not -dev) is open for critical fixes now, right? > > -Aleksey From sgehwolf at redhat.com Fri May 31 14:49:41 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 31 May 2019 16:49:41 +0200 Subject: [11u] RFR: 8224474: harfbuzz 2.3.1 code fails to compile with gcc 4.4.7 In-Reply-To: References: Message-ID: <3bbcc23f9f6d2db140d855dffad47a54c38e91e2.camel@redhat.com> Hi Andrew, On Tue, 2019-05-28 at 23:08 +0100, Andrew John Hughes wrote: > > On 21/05/2019 10:33, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review for this JDK 11u only fix? harfbuzz has > > been upgraded to 2.3.1 between jdk-11.0.4+2 and jdk-11.0.4+3. > > Unfortunately, this breaks the JDK 11u build on CentOS/RHEL 6 with > > system GCC 4.4.7 which the upstream OpenJDK 11u builds machinery > > uses. > > > > The fix is rather trivial: Move GCC pragmas outside functions. > > > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8224474/01/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8224474 > > > > Testing: release/slowdebug builds on Linux x86_64 with gcc 4.4.7. > > fastdebug build on Linux x86_64 with gcc 8.3.1 > > > > Thoughts? > > > > Thanks, > > Severin > > > > The HarfBuzz update (JDK-8210782) went to 12 & 13 as well. Should this > not go there as well, or do we not want to support this older GCC on > 11? My thinking was it's a JDK 11 only change. Considering JDK-8224087 and others which push towards newer toolchains for later JDK releases this change is add odds with that. Only taking JDK-8224087 into account, gcc 4.4.7 has *incomplete* support for -std=c99[1]. I'd be reluctant to push for it in JDK 13 for this reason. Thoughts? Thanks, Severin [1] https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Standards.html From christoph.langer at sap.com Fri May 31 15:02:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 31 May 2019 15:02:05 +0000 Subject: JDK11u tree is *NOT* open for pushes In-Reply-To: <3c73b54f-d4c2-973b-b0a9-062d2adda177@redhat.com> References: <743a32dc-92d3-3a4a-b245-3d886204377e@redhat.com> <3c73b54f-d4c2-973b-b0a9-062d2adda177@redhat.com> Message-ID: > Just checking: jdk11u (not -dev) is open for critical fixes now, right? Yes, it is. I updated the Wiki page to show correct status ?? /Christoph From christoph.langer at sap.com Fri May 31 15:09:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 31 May 2019 15:09:29 +0000 Subject: [11u] RFR: 8208698: Improved ECC Implementation In-Reply-To: References: Message-ID: Hi Martin, thanks for the review. Makes sense to take the fix regarding the overflow check along. I requested approval for JDK-8217344, too, and will push both patches together. Best regards Christoph > -----Original Message----- > From: Doerr, Martin > Sent: Freitag, 31. Mai 2019 14:40 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: security-dev > Subject: RE: [11u] RFR: 8208698: Improved ECC Implementation > > Hi Christoph, > > looks like quite some manual resolution just because of a small conflicting > change in one file. > Backport looks good, but please backport it together with JDK-8217344. > After that, ECDHKeyAgreement.java should be identical to the jdk13 version. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Langer, Christoph > > Sent: Dienstag, 28. Mai 2019 09:21 > > To: jdk-updates-dev at openjdk.java.net > > Cc: security-dev > > Subject: [11u] RFR: 8208698: Improved ECC Implementation > > > > Hi, > > > > please review this backport of JDK-8208698: Improved ECC > Implementation. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208698 > > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/752e57845ad2 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8208698.11u/ > > > > The patch did not apply cleanly because there were conflicts in > > src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java > > due to JDK-8205476 which is part of jdk/jdk but not of jdk11u-dev. > > Unfortunately, JDK-8205476 can not be downported as prerequisite > because > > it brings a behavioral change and is associated with a CSR. So I resolved the > > rejects manually. I add the rejects below. > > > > Thanks > > Christoph > > > > > > --- ECDHKeyAgreement.java > > +++ ECDHKeyAgreement.java > > @@ -99,42 +104,74 @@ > > ("Key must be a PublicKey with algorithm EC"); > > } > > - ECPublicKey ecKey = (ECPublicKey)key; > > - ECParameterSpec params = ecKey.getParams(); > > + this.publicKey = (ECPublicKey) key; > > - if (ecKey instanceof ECPublicKeyImpl) { > > - publicValue = ((ECPublicKeyImpl)ecKey).getEncodedPublicValue(); > > - } else { // instanceof ECPublicKey > > - publicValue = > > - ECUtil.encodePoint(ecKey.getW(), params.getCurve()); > > - } > > + ECParameterSpec params = publicKey.getParams(); > > int keyLenBits = params.getCurve().getField().getFieldSize(); > > secretLen = (keyLenBits + 7) >> 3; > > return null; > > } > > + private static void validateCoordinate(BigInteger c, BigInteger mod) { > > + if (c.compareTo(BigInteger.ZERO) < 0) { > > + throw new ProviderException("invalid coordinate"); > > + } > > + > > + if (c.compareTo(mod) >= 0) { > > + throw new ProviderException("invalid coordinate"); > > + } > > + } > > + > > + /* > > + * Check whether a public key is valid. Throw ProviderException > > + * if it is not valid or could not be validated. > > + */ > > + private static void validate(ECOperations ops, ECPublicKey key) { > > + > > + // ensure that integers are in proper range > > + BigInteger x = key.getW().getAffineX(); > > + BigInteger y = key.getW().getAffineY(); > > + > > + BigInteger p = ops.getField().getSize(); > > + validateCoordinate(x, p); > > + validateCoordinate(y, p); > > + > > + // ensure the point is on the curve > > + EllipticCurve curve = key.getParams().getCurve(); > > + BigInteger rhs = x.modPow(BigInteger.valueOf(3), > p).add(curve.getA() > > + .multiply(x)).add(curve.getB()).mod(p); > > + BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p); > > + if (!rhs.equals(lhs)) { > > + throw new ProviderException("point is not on curve"); > > + } > > + > > + // check the order of the point > > + ImmutableIntegerModuloP xElem = ops.getField().getElement(x); > > + ImmutableIntegerModuloP yElem = ops.getField().getElement(y); > > + AffinePoint affP = new AffinePoint(xElem, yElem); > > + byte[] order = key.getParams().getOrder().toByteArray(); > > + ArrayUtil.reverse(order); > > + Point product = ops.multiply(affP, order); > > + if (!ops.isNeutral(product)) { > > + throw new ProviderException("point has incorrect order"); > > + } > > + > > + } > > + > > // see JCE spec > > @Override > > protected byte[] engineGenerateSecret() throws IllegalStateException { > > - if ((privateKey == null) || (publicValue == null)) { > > + if ((privateKey == null) || (publicKey == null)) { > > throw new IllegalStateException("Not initialized correctly"); > > } > > - byte[] s = privateKey.getS().toByteArray(); > > - byte[] encodedParams = // DER OID > > - ECUtil.encodeECParameterSpec(null, privateKey.getParams()); > > - > > - try { > > - > > - byte[] result = deriveKey(s, publicValue, encodedParams); > > - publicValue = null; > > - return result; > > - > > - } catch (GeneralSecurityException e) { > > - throw new ProviderException("Could not derive key", e); > > - } > > - > > + Optional resultOpt = deriveKeyImpl(privateKey, publicKey); > > + byte[] result = resultOpt.orElseGet( > > + () -> deriveKeyNative(privateKey, publicKey) > > + ); > > + publicKey = null; > > + return result; > > } > > // see JCE spec From christoph.langer at sap.com Fri May 31 15:41:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 31 May 2019 15:41:15 +0000 Subject: RFR: [11u, 12u] JDK-8170639: [Linux] jsig is limited to a maximum of 64 signals In-Reply-To: References: Message-ID: You?re very welcome ?? Next time please consider exporting the patch from jdk/jdk and applying it to jdk11u-dev with mercurial queues. If you need to do modifications, you can then do a qrefresh. This will keep changeset meta info such as author, description and Reviewed-by attributions. Best Christoph From: Ao Qi Sent: Freitag, 31. Mai 2019 09:55 To: Langer, Christoph Cc: jdk-updates-dev at openjdk.java.net Subject: Re: RFR: [11u, 12u] JDK-8170639: [Linux] jsig is limited to a maximum of 64 signals On Fri, May 31, 2019 at 2:59 PM Langer, Christoph > wrote: Hi Ao Qi, I have reviewed your backport change and it looks good to me. The changes to os::Posix::init_2(void) seem correctly resolved. I have seen that you've set the fix-request label. So I will take the patch into our testing system and once there is approval in the bug and testing shows no regressions, I'll push this. Thank you very much, Christoph! Cheers, Ao Qi Thanks for your contribution to OpenJDK 11 Updates ?? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Ao Qi > Sent: Mittwoch, 27. M?rz 2019 11:00 > To: jdk-updates-dev at openjdk.java.net > Subject: RFR: [11u, 12u] JDK-8170639: [Linux] jsig is limited to a maximum of > 64 signals > > Hi, > > I'd like to backport this change to 11u and 12u: > > Original JBS: > https://bugs.openjdk.java.net/browse/JDK-8170639 > > Original change: > http://hg.openjdk.java.net/jdk/jdk/rev/3086f9259e97 > (http://cr.openjdk.java.net/~aoqi/8170639/webrev.03/) > > Original review threads: > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018- > December/031839.html > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019- > March/032909.html > > Patch does not apply cleanly, because of minor changes in > os::Posix::init_2(void) introduced by JDK-8194860. > > 12u change: > http://cr.openjdk.java.net/~aoqi/8170639/webrev.12u.03/ > > Tested: linux-x86_64-{server, minimal, zero}-{release, fastdebug} > build, solaris-x86_64-server-release build, > linux-mips64el-zero-release build, linux-x86_64-server-release tier1 > > May I also request to backport this fix to 11u? > http://cr.openjdk.java.net/~aoqi/8170639/webrev.12u.03 apply to > jdk11u-dev cleanly. > > jdk11u-dev tested: linux-x86_64-{server, minimal, zero}-{release, > fastdebug} build, solaris-x86_64-server-release build, > linux-x86_64-server-release tier1 > > Thanks, > Ao Qi From gnu.andrew at redhat.com Fri May 31 16:44:41 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 31 May 2019 17:44:41 +0100 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> Message-ID: <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> On 30/05/2019 22:56, Langer, Christoph wrote: > Hi, > >>> The level of bureaucratic overhead in these projects is getting absurd. >> We're >>> going to have to do something about it before we all drown. >> >> Yes, there is some overhead, it does not make things more >> simple. You could delegate some tasks. >> >> E.g., >> * I would volunteer to trigger the update of the JBS version >> For 11 whenever needed. Do you mean the hgupdater changes via ops? I think usually both 8u & 11u should be handled at the same time to minimise such updates. I'm not sure if anyone but the lead would be accepted for such a request. >> * You could allow to push the version bump without >> jdk11u-fix-yes tag. It's obvious we need it. >> That makes sense to me, given we have no such approval process for the equivalent process of tagging the repository. I've been thinking about this for 8u too [0] and, as both 8u & 11u allow multiple changesets to use the same bug ID, I think keeping such bumps under the same bug ID is a better idea than creating numerous bug IDs just for version updates. That also elegantly solves the approval process issue without the need for exceptional cases. >> Further, I would propose that we exclude all changes Oracle >> pushes to their 11.0.x from the tagging if pushed to >> the open 11.0.x (same x!). >> They have already been judged to be good for downport by Oracle. >> The "Fix Request" comment should be added to the change >> nevertheless. This way one can know that a change is being >> worked on. Maybe we should note in the bug that it is a downport >> that went to Oracle's 11.0.x, so it's clear why it is not tagged. I strongly disagree with this. It would amount to most of the changes not going through the approval process. I can see that with 11u, in its present state, this may mean a lot of rubber stamping of clean backports, because 11u has not diverged much from trunk. However, with 8u, the backported patch can frequently be quite different, and approval should be of that reviewed patch, not based on a decision at Oracle we know nothing about. I expect, with time, 11u will diverge in a similar way and so the approval process will be more involved. I definitely think the solution here is more hands on deck, not effectively removing the process altogether. > > Those seem good suggestions to me. I also think that you could extend the group of maintainers, that is, people who can approve backports. Andrew (Hughes) is already listed for 8u but 11u could also use additional approvers. However, if you do that, you should give some rules and criteria that the approvers have to follow. I'm open to doing 11u as well. I often have to remind myself I can't do that one when something comes up for both 8 & 11. I also think we should have at least a third maintainer on both projects, ideally from outside Red Hat. The primary things I look at for approval is the potential effect it has. Test cases are pretty unproblematic as are arch-specific changes coming from those maintaining that architecture. I'm more critical of general changes and try to ensure that there's nothing in there that will alter API compatibility. Also, ensuring the correct process is followed ends up being part of approval, so e.g. I will ask for a review if one isn't listed and seems needed, and other such sanity checks. > > Best regards > Christoph > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009508.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 aph at redhat.com Fri May 31 17:25:17 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 31 May 2019 18:25:17 +0100 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> Message-ID: <9559ed45-2226-75fd-4b85-867d1a71895f@redhat.com> On 5/31/19 5:44 PM, Andrew John Hughes wrote: > On 30/05/2019 22:56, Langer, Christoph wrote: >> Hi, >> >>>> The level of bureaucratic overhead in these projects is getting absurd. >>> We're >>>> going to have to do something about it before we all drown. >>> >>> Yes, there is some overhead, it does not make things more >>> simple. You could delegate some tasks. But that won't reduce the overhead: all it will do is spread it out. >>> E.g., >>> * I would volunteer to trigger the update of the JBS version >>> For 11 whenever needed. > > Do you mean the hgupdater changes via ops? I think usually both 8u & 11u > should be handled at the same time to minimise such updates. But how? It's not as if the projects are perfectly synchronized. Sure, if they happen to need changing at the same time, then we can do so. > I'm not > sure if anyone but the lead would be accepted for such a request. I'm sure I can delegate anyone to do it. >>> * You could allow to push the version bump without >>> jdk11u-fix-yes tag. It's obvious we need it. > > That makes sense to me, given we have no such approval process for the > equivalent process of tagging the repository. Yes. > I've been thinking about this for 8u too [0] and, as both 8u & 11u allow > multiple changesets to use the same bug ID, I think keeping such bumps > under the same bug ID is a better idea than creating numerous bug IDs > just for version updates. That also elegantly solves the approval > process issue without the need for exceptional cases. > >>> Further, I would propose that we exclude all changes Oracle >>> pushes to their 11.0.x from the tagging if pushed to >>> the open 11.0.x (same x!). >>> They have already been judged to be good for downport by Oracle. >>> The "Fix Request" comment should be added to the change >>> nevertheless. This way one can know that a change is being >>> worked on. Maybe we should note in the bug that it is a downport >>> that went to Oracle's 11.0.x, so it's clear why it is not tagged. > > I strongly disagree with this. It would amount to most of the changes > not going through the approval process. > > I can see that with 11u, in its present state, this may mean a lot of > rubber stamping of clean backports, because 11u has not diverged much > from trunk. However, with 8u, the backported patch can frequently be > quite different, and approval should be of that reviewed patch, not > based on a decision at Oracle we know nothing about. The backported patch, if different from the patch applied at head, will have to be reviewed. That's when the code walkthrough and the impact should be assessed. On the other hand, approval says that, in principle at least, this change is one that we want in the release branch. > I expect, with time, 11u will diverge in a similar way and so the > approval process will be more involved. I definitely think the solution > here is more hands on deck, not effectively removing the process altogether. > >> Those seem good suggestions to me. I also think that you could >> extend the group of maintainers, that is, people who can approve >> backports. Andrew (Hughes) is already listed for 8u but 11u could >> also use additional approvers. However, if you do that, you should >> give some rules and criteria that the approvers have to follow. Definitely, yes. The thing holding me back from appointing more maintainers, still, is that I perceive a lack of consensus about the criteria by which a backport should be judged. I personally would be strict about this: serious bugs and regressions, plus perhaps some important performance improvements. However, there seems to be a general sentiment that we don't want to diverge from Oracle, so some pretty trivial backports have been approved. To some extent I accept the "don't diverge" reasoning because feature differences between OpenJDK and Oracle are to be avoided if possible: we don't want to confuser our users unnecessarily. > I'm open to doing 11u as well. I often have to remind myself I can't > do that one when something comes up for both 8 & 11. I also think we > should have at least a third maintainer on both projects, ideally > from outside Red Hat. > > The primary things I look at for approval is the potential effect it > has. Test cases are pretty unproblematic as are arch-specific > changes coming from those maintaining that architecture. I'm more > critical of general changes and try to ensure that there's nothing > in there that will alter API compatibility. This is a good start. If we can agree what criteria we should apply when approving a backport then we can share the maintainer's role. > Also, ensuring the correct process is followed ends up being part of > approval, so e.g. I will ask for a review if one isn't listed and > seems needed, and other such sanity checks. That imposes a strict ordering: review first, then approval. I think that approval and review can run in parallel: we don't want to fully review every backport patch twice. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671