From christoph.langer at sap.com  Mon Jul  1 09:39:57 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 1 Jul 2019 09:39:57 +0000
Subject: [11u] RFR (S): 8226880: Backport of JDK-8208698 (Improved ECC
 Implementation) should not bring parts of JDK-8205476
 (KeyAgreement#generateSecret is not reset for ECDH based algorithm)
In-Reply-To: <a477fad9-6db9-1309-d68e-0c97ccd8d1b6@redhat.com>
References: <DB7PR02MB5193FC431773A39DFD46DCC98AFD0@DB7PR02MB5193.eurprd02.prod.outlook.com>
 <a477fad9-6db9-1309-d68e-0c97ccd8d1b6@redhat.com>
Message-ID: <AM6PR02MB51924D461460CFCEAA0D37768AF90@AM6PR02MB5192.eurprd02.prod.outlook.com>

Thanks, pushed.

> -----Original Message-----
> From: Andrew John Hughes <gnu.andrew at redhat.com>
> Sent: Donnerstag, 27. Juni 2019 18:45
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: security-dev <security-dev at openjdk.java.net>
> Subject: Re: [11u] RFR (S): 8226880: Backport of JDK-8208698 (Improved ECC
> Implementation) should not bring parts of JDK-8205476
> (KeyAgreement#generateSecret is not reset for ECDH based algorithm)
> 
> 
> 
> On 27/06/2019 11:12, Langer, Christoph wrote:
> > Hi,
> >
> >
> >
> > I made a mistake when bringing JDK-8226880 to 11u. The patch introduced
> > coding of JDK-8205476 that should not be there. Here is a patch to fix this.
> >
> >
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8226880
> >
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8226880.11u.0/
> >
> >
> >
> > As the backport is in 11.0.4, this fix needs to be applied there during
> > closed rampdown.
> >
> >
> >
> > Thanks
> >
> > Christoph
> >
> >
> >
> 
> Looks good to me.
> 
> 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  Mon Jul  1 14:01:06 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 1 Jul 2019 14:01:06 +0000
Subject: [11u] Code Freeze Exception
In-Reply-To: <6c423d3c-7d46-505f-cb48-dea54730ee0d@redhat.com>
References: <473a0340-60f3-3b27-de62-784c8f8b4978@redhat.com>
 <AM6PR02MB5192B1E00382A19BFAF088358AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5347613B4DA33AEE1EAD697AECFC0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <AM6PR02MB5192F496D37E10C0B01B013C8AFC0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <6c423d3c-7d46-505f-cb48-dea54730ee0d@redhat.com>
Message-ID: <AM6PR02MB53475EAAC9882B2535E0ADA2ECF90@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi Andrew, 

I pushed the tag to jdk11u.

I'll push it tomorrow, after further testing of the merge, to jdk11u-dev.

Best regards,
  Goetz.

> -----Original Message-----
> From: Andrew John Hughes <gnu.andrew at redhat.com>
> Sent: Montag, 1. Juli 2019 01:25
> To: Langer, Christoph <christoph.langer at sap.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; 'jdk-updates-dev at openjdk.java.net' <jdk-
> updates-dev at openjdk.java.net>
> Subject: Re: [11u] Code Freeze Exception
> 
> 
> 
> On 28/06/2019 07:41, Langer, Christoph wrote:
> > Hi,
> >
> >> Yes, we should fix these issues.
> >> Andrew, should I add another tag once the changes are in?
> >
> > That would be preferrable because we can then merge it down to jdk11u-dev
> and have the fixes there, too. Otherwise they'd be missing for another 2-3
> weeks.
> >
> >>>> 2. Roll back JDK-8218960 backport due to JDK-8226876. This is targeted
> >>>> as 11.0.5 for Oracle anyway.
> >>>> https://bugs.openjdk.java.net/browse/JDK-8226876
> >>>
> >>> Seems, there is a simple fix upcoming for the regression:
> >>> https://mail.openjdk.java.net/pipermail/i18n-dev/2019-June/002870.html
> >>> I'd vote for taking the fix over to 11.0.4. Then we don't need to care for re-
> >>> applying the fix and the patch.
> >>>
> >>> Andrew, shall I push both things to jdk11u? When is your deadline to not
> >>> unduly hold up your CPU work?
> >> To me, it seems more simple to roll back 8218960, as we can do this
> >> right now. Or do you expect other follow up issues if we roll it back,
> >> Christoph?   But if your schedule admits it, Andrew, we can also
> >> go for the fix.
> >
> > Naoto plans to push the fix to jdk13 tonight as per
> https://mail.openjdk.java.net/pipermail/i18n-dev/2019-June/002875.html
> >
> > So, we could run another testcycle with both fixes here during the weekend
> and then push and tag Monday morning. Andrew, is that the plan we should go
> for?
> >
> > /Christoph
> >
> 
> Sorry for the late reply. I've been busy wrapping up 8u.
> 
> Yes, that sounds good to me. I'll keep an eye out for the new tag.
> 
> Thanks,
> --
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew


From christoph.langer at sap.com  Mon Jul  1 14:25:45 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 1 Jul 2019 14:25:45 +0000
Subject: [11u]: RFR: Backport of 8215694: keytool cannot generate
 RSASSA-PSS certificates
In-Reply-To: <63478A16-049F-4B16-A76C-4B1BB6AFF6F5@amazon.com>
References: <AM6PR02MB5192073F13232DE3CE497B368AE20@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB519298720FBD023ABBE5733C8AFC0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <63478A16-049F-4B16-A76C-4B1BB6AFF6F5@amazon.com>
Message-ID: <AM6PR02MB5192807A255B70CAF33D4DFA8AF90@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Paul,

thanks for your review.

> In CertAndKeyGen.java, does generate() need a throws declaration?

It doesn't. IllegalArgumentException is a RuntimeException and as such doesn't need a throws declaration. And InvalidKeyException is obviously not needed and was removed in the original changeset as well.

> Otherwise looks good.

Thanks. I also asked Max Wang to have a look off list and he seems to agree as well.

> We've been talking about backporting patches with CSRs and have done at
> least one. Imo, 8076190 and 8213400 are good backport candidates since the
> spec changes are minor.

Yes, a CSR is not necessarily a showstopper for a backport. But as it is not my area of expertise and there's no other reason that makes backports of these bugs important to me, I don't want to take the additional work and responsibility for these backports. But feel free to do this ??

So, I guess I'm good to push this, once approved.

Cheers,
Christoph


From christoph.langer at sap.com  Mon Jul  1 14:44:41 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 1 Jul 2019 14:44:41 +0000
Subject: [11u] RFR 8209186: Rename SimpleThresholdPolicy to
 TieredThresholdPolicy
In-Reply-To: <6539471b-ca99-a4f4-47f2-a1aa73b85eea@redhat.com>
References: <6539471b-ca99-a4f4-47f2-a1aa73b85eea@redhat.com>
Message-ID: <AM6PR02MB5192CBA943F58AA68BC5A2DB8AF90@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Aleksey,

I eyeballed this and it looks good to me. The changes of JDK-8222670 were transported. So: +1.

Thanks
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Mittwoch, 26. Juni 2019 12:34
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR 8209186: Rename SimpleThresholdPolicy to
> TieredThresholdPolicy
> 
> Original RFE:
>   https://bugs.openjdk.java.net/browse/JDK-8209186
>   http://hg.openjdk.java.net/jdk/jdk/rev/f32e61253792
> 
> Patch does not apply to 11u cleanly, because JDK-8222670 backport went in
> first. This actually
> highlights the benefit for making the rename early, to fit any future
> backports (notably JDK-8076988
> and JDK-8216375).
> 
> So, I had to recreate the patch by hand. As in original patch, we move
> .inline.hpp into .cpp, along
> with includes. Then we rename SimpleThresholdPolicy ->
> TieredThresholdPolicy.
> 
> 11u webrev:
>   http://cr.openjdk.java.net/~shade/8209186/webrev.11u.01/
> 
> Testing: tier1
> 
> --
> Thanks,
> -Aleksey


From christoph.langer at sap.com  Mon Jul  1 14:50:07 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 1 Jul 2019 14:50:07 +0000
Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal
 classes made accessible to jdk.unsupported
In-Reply-To: <AM6PR02MB51921F3E60A43635C01525CF8AE20@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB51921F3E60A43635C01525CF8AE20@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB5192FCAE8B4F13AEDF694AB78AF90@AM6PR02MB5192.eurprd02.prod.outlook.com>

Ping...

This backport is needed as prerequisite for further items ??

> -----Original Message-----
> From: Langer, Christoph
> Sent: Mittwoch, 26. Juni 2019 17:04
> To: jdk-updates-dev at openjdk.java.net
> Cc: AWT-DEV Mailing List <awt-dev at openjdk.java.net>; Java Core Libs
> <core-libs-dev at openjdk.java.net>
> Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal
> classes made accessible to jdk.unsupported
> 
> Hi,
> 
> next try, here we go again...
> 
> I'd like to backport "JDK-8211122: Reduce the number of internal classes
> made accessible to jdk.unsupported". The main reason for backporting this
> item is that it'll ease further backports which base on that changeset (e.g.
> JDK-8216039). The patch is quite extensive and so doesn't fully apply. I had to
> resolve some rejects and also modify a few other places. Lots of the rejects
> were about copyright years (especially in the hotspot tests) which could be
> dropped. Find below the link for a full webrev and an incremental one which
> only contains my manual changes. Testing in SAP's test system does not
> show regressions.
> 
> My initial proposal for the backport of this change assumed that we could
> take JDK-8205537 and JDK-8211121 as prerequisites [0]. I have to step back
> from that idea because both changes would remove stuff which you
> probably don't want to remove in an update release. The modifications to
> this patch to accommodate for the missing prerequisites are quite minor,
> though. In java.desktop's sun.applet.AppletSecurity.java we only have to
> include the SharedSecrets from the new package jdk.internal.access instead
> of jdk.internal.misc. To keep jdk.unsupported's
> sun.reflect.ReflectionFactory::newInstanceForSerialization method working
> without having to open up jdk.internal.access for jdk.unsupported (which
> was the whole purpose of this change) we need to keep little wrapper stubs
> for jdk.internal.misc.JavaSecurityAccess and jdk.internal.misc.SharedSecrets.
> 
> Here are the links:
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8211122
> Original review discussion: https://mail.openjdk.java.net/pipermail/core-
> libs-dev/2018-November/056397.html
> Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/3c6aa484536c
> Full webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8211122.11u.full.1/
> Incremental Webrev of manual changes:
> http://cr.openjdk.java.net/~clanger/webrevs/8211122.11u.manual.1/
> Rejects of the original apply:
> http://cr.openjdk.java.net/~clanger/webrevs/8211122.rejects.patch
> 
> Thanks
> Christoph
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-
> June/001316.html


From shade at redhat.com  Mon Jul  1 15:02:27 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Jul 2019 17:02:27 +0200
Subject: [11u] RFR 8209186: Rename SimpleThresholdPolicy to
 TieredThresholdPolicy
In-Reply-To: <AM6PR02MB5192CBA943F58AA68BC5A2DB8AF90@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <6539471b-ca99-a4f4-47f2-a1aa73b85eea@redhat.com>
 <AM6PR02MB5192CBA943F58AA68BC5A2DB8AF90@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <67e83c46-bf4e-5229-2fe6-3dc7811f4bb3@redhat.com>

On 7/1/19 4:44 PM, Langer, Christoph wrote:
> I eyeballed this and it looks good to me. The changes of JDK-8222670 were transported. So: +1.

Thank you!

-Aleksey


From hohensee at amazon.com  Mon Jul  1 15:36:59 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 1 Jul 2019 15:36:59 +0000
Subject: [11u]: RFR: Backport of 8215694: keytool cannot generate
 RSASSA-PSS certificates
In-Reply-To: <AM6PR02MB5192807A255B70CAF33D4DFA8AF90@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192073F13232DE3CE497B368AE20@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB519298720FBD023ABBE5733C8AFC0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <63478A16-049F-4B16-A76C-4B1BB6AFF6F5@amazon.com>
 <AM6PR02MB5192807A255B70CAF33D4DFA8AF90@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <E22575C9-50AF-4EEB-BEE8-EB26926E2650@amazon.com>

Yes.  Thanks, Paul.

?On 7/1/19, 7:26 AM, "Langer, Christoph" <christoph.langer at sap.com> wrote:

    Hi Paul,
    
    thanks for your review.
    
    > In CertAndKeyGen.java, does generate() need a throws declaration?
    
    It doesn't. IllegalArgumentException is a RuntimeException and as such doesn't need a throws declaration. And InvalidKeyException is obviously not needed and was removed in the original changeset as well.
    
    > Otherwise looks good.
    
    Thanks. I also asked Max Wang to have a look off list and he seems to agree as well.
    
    > We've been talking about backporting patches with CSRs and have done at
    > least one. Imo, 8076190 and 8213400 are good backport candidates since the
    > spec changes are minor.
    
    Yes, a CSR is not necessarily a showstopper for a backport. But as it is not my area of expertise and there's no other reason that makes backports of these bugs important to me, I don't want to take the additional work and responsibility for these backports. But feel free to do this ??
    
    So, I guess I'm good to push this, once approved.
    
    Cheers,
    Christoph
    
    


From aph at redhat.com  Tue Jul  2 13:37:25 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 2 Jul 2019 14:37:25 +0100
Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal
 classes made accessible to jdk.unsupported
In-Reply-To: <AM6PR02MB5192FCAE8B4F13AEDF694AB78AF90@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB51921F3E60A43635C01525CF8AE20@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192FCAE8B4F13AEDF694AB78AF90@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <fb66b890-50ca-9df7-e489-fe808ba1b507@redhat.com>

On 7/1/19 3:50 PM, Langer, Christoph wrote:
> Ping...
> 
> This backport is needed as prerequisite for further items ??

Yeah. All this makes me very nervous. This is the kind of wholesale
reorganization that would normally be inappropriate in a backport. I
do appreciate that this is your second attempt at making something
appropriate, but it's difficult.

I note that Oracle has not backported this to 11, and presumably has
had to work around the JDK-8216039 problem in some other way.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From christoph.langer at sap.com  Tue Jul  2 14:18:30 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 2 Jul 2019 14:18:30 +0000
Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal
 classes made accessible to jdk.unsupported
In-Reply-To: <fb66b890-50ca-9df7-e489-fe808ba1b507@redhat.com>
References: <AM6PR02MB51921F3E60A43635C01525CF8AE20@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192FCAE8B4F13AEDF694AB78AF90@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <fb66b890-50ca-9df7-e489-fe808ba1b507@redhat.com>
Message-ID: <AM6PR02MB51922CB32264F0A753762B158AF80@AM6PR02MB5192.eurprd02.prod.outlook.com>

> > This backport is needed as prerequisite for further items ??
> 
> Yeah. All this makes me very nervous. This is the kind of wholesale
> reorganization that would normally be inappropriate in a backport. I
> do appreciate that this is your second attempt at making something
> appropriate, but it's difficult.
> 
> I note that Oracle has not backported this to 11, and presumably has
> had to work around the JDK-8216039 problem in some other way.

Ok, it's probably a wise decision not to approve it. Modifying 8216039 to fit into 11u without 8211122 shouldn't be too hard... I just thought it might be beneficial for other possible backports, too.

Thanks
Christoph


From takiguc at linux.vnet.ibm.com  Wed Jul  3 10:59:38 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 03 Jul 2019 19:59:38 +0900
Subject: Do you have any plan to provide OpenJDK 11.0.4+x EA build ?
Message-ID: <dd77f029ff00f3649926c730f89dc090@linux.vnet.ibm.com>

Hello jdk update team.

Do you have any plan to provide OpenJDK 11.0.4+10 or later EA build, 
like 11.0.3 [1] ?

[1] 
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000910.html

Thanks,
Ichiroh Takiguchi
IBM Japan Ltd.

From shade at redhat.com  Wed Jul  3 11:01:26 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Jul 2019 13:01:26 +0200
Subject: Do you have any plan to provide OpenJDK 11.0.4+x EA build ?
In-Reply-To: <dd77f029ff00f3649926c730f89dc090@linux.vnet.ibm.com>
References: <dd77f029ff00f3649926c730f89dc090@linux.vnet.ibm.com>
Message-ID: <8f335d3c-8b6a-f733-dba0-2d5fea5880c3@redhat.com>

On 7/3/19 12:59 PM, Ichiroh Takiguchi wrote:
> Hello jdk update team.
> 
> Do you have any plan to provide OpenJDK 11.0.4+10 or later EA build, like 11.0.3 [1] ?

I believe some builds would appear here:
  https://adoptopenjdk.net/upstream.html

There is 11.0.4-ea+9 already.

-- 
Thanks,
-Aleksey


From christoph.langer at sap.com  Thu Jul  4 13:11:17 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 4 Jul 2019 13:11:17 +0000
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
 ECDHServerKeyExchange
Message-ID: <AM6PR02MB5192494FA880B35B22BF1B288AFA0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

please help reviewing the backport of JDK-8216039 to jdk11u-dev.

Since predecessor patch JDK-8211122 could not be applied to JDK 11 updates, some manual work is necessary.

In src/java.base/share/classes/java/security/Signature.java and src/java.base/share/classes/sun/security/util/SignatureUtil.java the imports of jdk.internal.access have to be changed into jdk.internal.misc. The update that originally went to src/java.base/share/classes/jdk/internal/access/SharedSecrets.java obviously needs to be applied to src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The new file src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java needs to be src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java in 11u.

See the full webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/
The webrev for manual changes only: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/
Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039

Thanks
Christoph


From christoph.langer at sap.com  Tue Jul  9 12:35:15 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 9 Jul 2019 12:35:15 +0000
Subject: [11u, 8u]: OpenJDK update releases 11.0.6 and 8u242: Created JBS
 filter views and published preliminary timeline on Wiki
Message-ID: <AM6PR02MB51926723A4476CFBA6394FF08AF10@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

I just wanted to notify everybody that I've just created JBS backport issue filters for the January 2020 releases 11.0.6 and 8u242. The Wiki pages [1],[2] were updated accordingly along with a preliminary timeline for these releases. The date for the CPU code freeze falls into the Christmas holidays so we'll probably have to adjust this a bit eventually.

The filters also received a small bugfix. In the backport view, one will now only see issues that Oracle has already resolved for the relevant update release. When the query finds backport items that are still unresolved or marked as "Won't fix", the according bug will not appear in the list.

Best regards
Christoph

[1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
[2] https://wiki.openjdk.java.net/display/jdk8u


From shade at redhat.com  Thu Jul 11 10:04:52 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 11 Jul 2019 12:04:52 +0200
Subject: [11u, 8u]: OpenJDK update releases 11.0.6 and 8u242: Created JBS
 filter views and published preliminary timeline on Wiki
In-Reply-To: <AM6PR02MB51926723A4476CFBA6394FF08AF10@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB51926723A4476CFBA6394FF08AF10@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <fbdfb1cd-53d6-cb8a-fd48-ae56d4fb27e2@redhat.com>

On 7/9/19 2:35 PM, Langer, Christoph wrote:
> I just wanted to notify everybody that I've just created JBS backport issue filters for the
> January 2020 releases 11.0.6 and 8u242. The Wiki pages [1],[2] were updated accordingly along
> with a preliminary timeline for these releases. The date for the CPU code freeze falls into the
> Christmas holidays so we'll probably have to adjust this a bit eventually.

I added the relevant filter dumps here:
  https://builds.shipilev.net/backports-monitor/filter-oracle-missing-8u242.txt
  https://builds.shipilev.net/backports-monitor/filter-oracle-missing-11.0.6.txt
  https://builds.shipilev.net/backports-monitor/filter-openjdk-missing-8u242.txt
  https://builds.shipilev.net/backports-monitor/filter-openjdk-missing-11.0.6.txt

-- 
Thanks,
-Aleksey


From christoph.langer at sap.com  Thu Jul 11 21:08:14 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 11 Jul 2019 21:08:14 +0000
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
 ECDHServerKeyExchange
In-Reply-To: <AM6PR02MB5192197FCDF6C7991D135E838AFA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192197FCDF6C7991D135E838AFA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB519277504F98DB6FEB219C1D8AF30@AM6PR02MB5192.eurprd02.prod.outlook.com>

Ping...

would somebody please eyeball this backport? No regressions seen in testing...

Thanks
Christoph

From: Langer, Christoph
Sent: Donnerstag, 4. Juli 2019 15:11
To: jdk-updates-dev at openjdk.java.net
Cc: security-dev <security-dev at openjdk.java.net>
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange

Hi,

please help reviewing the backport of JDK-8216039 to jdk11u-dev.

Since predecessor patch JDK-8211122 could not be applied to JDK 11 updates, some manual work is necessary.

In src/java.base/share/classes/java/security/Signature.java and src/java.base/share/classes/sun/security/util/SignatureUtil.java the imports of jdk.internal.access have to be changed into jdk.internal.misc. The update that originally went to src/java.base/share/classes/jdk/internal/access/SharedSecrets.java obviously needs to be applied to src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The new file src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java needs to be src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java in 11u.

See the full webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/
The webrev for manual changes only: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/
Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039

Thanks
Christoph


From christoph.langer at sap.com  Thu Jul 11 21:11:46 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 11 Jul 2019 21:11:46 +0000
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
 ECDHServerKeyExchange
In-Reply-To: <AM6PR02MB5192197FCDF6C7991D135E838AFA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192197FCDF6C7991D135E838AFA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB51922F6378CAFFF50EF2C4568AF30@AM6PR02MB5192.eurprd02.prod.outlook.com>

Ping...

Can somebody please have a look at this backport? Regression testing shows no problems...

Thanks
Christoph

From: Langer, Christoph
Sent: Donnerstag, 4. Juli 2019 15:11
To: jdk-updates-dev at openjdk.java.net
Cc: security-dev <security-dev at openjdk.java.net>
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange

Hi,

please help reviewing the backport of JDK-8216039 to jdk11u-dev.

Since predecessor patch JDK-8211122 could not be applied to JDK 11 updates, some manual work is necessary.

In src/java.base/share/classes/java/security/Signature.java and src/java.base/share/classes/sun/security/util/SignatureUtil.java the imports of jdk.internal.access have to be changed into jdk.internal.misc. The update that originally went to src/java.base/share/classes/jdk/internal/access/SharedSecrets.java obviously needs to be applied to src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The new file src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java needs to be src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java in 11u.

See the full webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/
The webrev for manual changes only: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/
Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039

Thanks
Christoph


From valerie.peng at oracle.com  Thu Jul 11 23:33:35 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 11 Jul 2019 16:33:35 -0700
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
 ECDHServerKeyExchange
In-Reply-To: <AM6PR02MB51922F6378CAFFF50EF2C4568AF30@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192197FCDF6C7991D135E838AFA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB51922F6378CAFFF50EF2C4568AF30@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <94780af5-378f-bb1d-9d46-a56dcd9f9722@oracle.com>

I will take a look.

Thanks,
Valerie
On 7/11/2019 2:11 PM, Langer, Christoph wrote:
> Ping...
>
> Can somebody please have a look at this backport? Regression testing shows no problems...
>
> Thanks
> Christoph
>
> From: Langer, Christoph
> Sent: Donnerstag, 4. Juli 2019 15:11
> To: jdk-updates-dev at openjdk.java.net
> Cc: security-dev <security-dev at openjdk.java.net>
> Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange
>
> Hi,
>
> please help reviewing the backport of JDK-8216039 to jdk11u-dev.
>
> Since predecessor patch JDK-8211122 could not be applied to JDK 11 updates, some manual work is necessary.
>
> In src/java.base/share/classes/java/security/Signature.java and src/java.base/share/classes/sun/security/util/SignatureUtil.java the imports of jdk.internal.access have to be changed into jdk.internal.misc. The update that originally went to src/java.base/share/classes/jdk/internal/access/SharedSecrets.java obviously needs to be applied to src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The new file src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java needs to be src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java in 11u.
>
> See the full webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/
> The webrev for manual changes only: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/
> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039
>
> Thanks
> Christoph
>

From valerie.peng at oracle.com  Thu Jul 11 23:37:43 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 11 Jul 2019 16:37:43 -0700
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
 ECDHServerKeyExchange
In-Reply-To: <94780af5-378f-bb1d-9d46-a56dcd9f9722@oracle.com>
References: <AM6PR02MB5192197FCDF6C7991D135E838AFA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB51922F6378CAFFF50EF2C4568AF30@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <94780af5-378f-bb1d-9d46-a56dcd9f9722@oracle.com>
Message-ID: <50cd9f32-e8fc-07af-57f9-c09d16a39c0c@oracle.com>

BTW, I have just integrated a relevant fix 
(https://bugs.openjdk.java.net/browse/JDK-8225745) which should probably 
be backported as well...

Thanks,
Valerie
On 7/11/2019 4:33 PM, Valerie Peng wrote:
> I will take a look.
>
> Thanks,
> Valerie
> On 7/11/2019 2:11 PM, Langer, Christoph wrote:
>> Ping...
>>
>> Can somebody please have a look at this backport? Regression testing 
>> shows no problems...
>>
>> Thanks
>> Christoph
>>
>> From: Langer, Christoph
>> Sent: Donnerstag, 4. Juli 2019 15:11
>> To: jdk-updates-dev at openjdk.java.net
>> Cc: security-dev <security-dev at openjdk.java.net>
>> Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks 
>> ECDHServerKeyExchange
>>
>> Hi,
>>
>> please help reviewing the backport of JDK-8216039 to jdk11u-dev.
>>
>> Since predecessor patch JDK-8211122 could not be applied to JDK 11 
>> updates, some manual work is necessary.
>>
>> In src/java.base/share/classes/java/security/Signature.java and 
>> src/java.base/share/classes/sun/security/util/SignatureUtil.java the 
>> imports of jdk.internal.access have to be changed into 
>> jdk.internal.misc. The update that originally went to 
>> src/java.base/share/classes/jdk/internal/access/SharedSecrets.java 
>> obviously needs to be applied to 
>> src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The 
>> new file 
>> src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java 
>> needs to be 
>> src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java 
>> in 11u.
>>
>> See the full webrev here: 
>> http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/
>> The webrev for manual changes only: 
>> http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/
>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039
>>
>> Thanks
>> Christoph
>>

From hohensee at amazon.com  Thu Jul 11 23:44:10 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 11 Jul 2019 23:44:10 +0000
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
 ECDHServerKeyExchange
In-Reply-To: <AM6PR02MB51922F6378CAFFF50EF2C4568AF30@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192197FCDF6C7991D135E838AFA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB51922F6378CAFFF50EF2C4568AF30@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <22D9906C-9FD2-4525-9C41-393431A96682@amazon.com>

Looks good.

Paul

?On 7/11/19, 2:14 PM, "jdk-updates-dev on behalf of Langer, Christoph" <jdk-updates-dev-bounces at openjdk.java.net on behalf of christoph.langer at sap.com> wrote:

    Ping...
    
    Can somebody please have a look at this backport? Regression testing shows no problems...
    
    Thanks
    Christoph
    
    From: Langer, Christoph
    Sent: Donnerstag, 4. Juli 2019 15:11
    To: jdk-updates-dev at openjdk.java.net
    Cc: security-dev <security-dev at openjdk.java.net>
    Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange
    
    Hi,
    
    please help reviewing the backport of JDK-8216039 to jdk11u-dev.
    
    Since predecessor patch JDK-8211122 could not be applied to JDK 11 updates, some manual work is necessary.
    
    In src/java.base/share/classes/java/security/Signature.java and src/java.base/share/classes/sun/security/util/SignatureUtil.java the imports of jdk.internal.access have to be changed into jdk.internal.misc. The update that originally went to src/java.base/share/classes/jdk/internal/access/SharedSecrets.java obviously needs to be applied to src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The new file src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java needs to be src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java in 11u.
    
    See the full webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/
    The webrev for manual changes only: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/
    Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039
    
    Thanks
    Christoph
    
    


From valerie.peng at oracle.com  Fri Jul 12 00:51:25 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 11 Jul 2019 17:51:25 -0700
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
 ECDHServerKeyExchange
In-Reply-To: <94780af5-378f-bb1d-9d46-a56dcd9f9722@oracle.com>
References: <AM6PR02MB5192197FCDF6C7991D135E838AFA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB51922F6378CAFFF50EF2C4568AF30@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <94780af5-378f-bb1d-9d46-a56dcd9f9722@oracle.com>
Message-ID: <a6277c73-328f-d276-a28d-2bbef801cdb6@oracle.com>

To expedite the review, I looked at the manual changes. The changes look 
fine.

Thanks,
Valerie
On 7/11/2019 4:33 PM, Valerie Peng wrote:
> I will take a look.
>
> Thanks,
> Valerie
> On 7/11/2019 2:11 PM, Langer, Christoph wrote:
>> Ping...
>>
>> Can somebody please have a look at this backport? Regression testing 
>> shows no problems...
>>
>> Thanks
>> Christoph
>>
>> From: Langer, Christoph
>> Sent: Donnerstag, 4. Juli 2019 15:11
>> To: jdk-updates-dev at openjdk.java.net
>> Cc: security-dev <security-dev at openjdk.java.net>
>> Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks 
>> ECDHServerKeyExchange
>>
>> Hi,
>>
>> please help reviewing the backport of JDK-8216039 to jdk11u-dev.
>>
>> Since predecessor patch JDK-8211122 could not be applied to JDK 11 
>> updates, some manual work is necessary.
>>
>> In src/java.base/share/classes/java/security/Signature.java and 
>> src/java.base/share/classes/sun/security/util/SignatureUtil.java the 
>> imports of jdk.internal.access have to be changed into 
>> jdk.internal.misc. The update that originally went to 
>> src/java.base/share/classes/jdk/internal/access/SharedSecrets.java 
>> obviously needs to be applied to 
>> src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The 
>> new file 
>> src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java 
>> needs to be 
>> src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java 
>> in 11u.
>>
>> See the full webrev here: 
>> http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/
>> The webrev for manual changes only: 
>> http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/
>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039
>>
>> Thanks
>> Christoph
>>

From christoph.langer at sap.com  Fri Jul 12 09:16:53 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 12 Jul 2019 09:16:53 +0000
Subject: Result: New JDK Updates Reviewer: Matthias Baesken
Message-ID: <AM6PR02MB5192497C0FB3E784624B4BAA8AF20@AM6PR02MB5192.eurprd02.prod.outlook.com>

The voting for Matthias Baesken [1] is now closed.



Yes: 9

Veto: 0

Abstain: 0



According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination.



Thanks,

/Jesper



[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-June/001312.html



From christoph.langer at sap.com  Fri Jul 12 09:20:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 12 Jul 2019 09:20:34 +0000
Subject: Result: New JDK Updates Reviewer: Severin Gehwolf
Message-ID: <AM6PR02MB51923EBCE4647C2E998841BB8AF20@AM6PR02MB5192.eurprd02.prod.outlook.com>

The voting for Severin Gehwolf [1] is now closed.



Yes: 11

Veto: 0

Abstain: 0



According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination.



Thanks,

Christoph



[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-June/001343.html



From christoph.langer at sap.com  Fri Jul 12 09:23:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 12 Jul 2019 09:23:39 +0000
Subject: Result: New JDK Updates Committer: Gustavo Romero
Message-ID: <AM6PR02MB5192DAA4C9A5B6EF0AA890A78AF20@AM6PR02MB5192.eurprd02.prod.outlook.com>

The voting for Gustavo Romero [1] is now closed.



Yes: 14

Veto: 0

Abstain: 0



According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination.



Thanks,

Christoph



[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-June/001334.html

From christoph.langer at sap.com  Fri Jul 12 11:47:35 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 12 Jul 2019 11:47:35 +0000
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
 ECDHServerKeyExchange
In-Reply-To: <22D9906C-9FD2-4525-9C41-393431A96682@amazon.com>
References: <AM6PR02MB5192197FCDF6C7991D135E838AFA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB51922F6378CAFFF50EF2C4568AF30@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <22D9906C-9FD2-4525-9C41-393431A96682@amazon.com>
Message-ID: <AM6PR02MB51929629E4939547DB6B72038AF20@AM6PR02MB5192.eurprd02.prod.outlook.com>

Thank you, Paul and Valerie for the reviews.

@Valerie: I'll take a look whether https://bugs.openjdk.java.net/browse/JDK-8225745 can/should be backported and if yes, take care of the backport ??

> -----Original Message-----
> From: Hohensee, Paul <hohensee at amazon.com>
> Sent: Freitag, 12. Juli 2019 01:44
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: security-dev <security-dev at openjdk.java.net>
> Subject: Re: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
> ECDHServerKeyExchange
> 
> Looks good.
> 
> Paul
> 
> ?On 7/11/19, 2:14 PM, "jdk-updates-dev on behalf of Langer, Christoph" <jdk-
> updates-dev-bounces at openjdk.java.net on behalf of
> christoph.langer at sap.com> wrote:
> 
>     Ping...
> 
>     Can somebody please have a look at this backport? Regression testing
> shows no problems...
> 
>     Thanks
>     Christoph
> 
>     From: Langer, Christoph
>     Sent: Donnerstag, 4. Juli 2019 15:11
>     To: jdk-updates-dev at openjdk.java.net
>     Cc: security-dev <security-dev at openjdk.java.net>
>     Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
> ECDHServerKeyExchange
> 
>     Hi,
> 
>     please help reviewing the backport of JDK-8216039 to jdk11u-dev.
> 
>     Since predecessor patch JDK-8211122 could not be applied to JDK 11
> updates, some manual work is necessary.
> 
>     In src/java.base/share/classes/java/security/Signature.java and
> src/java.base/share/classes/sun/security/util/SignatureUtil.java the imports
> of jdk.internal.access have to be changed into jdk.internal.misc. The update
> that originally went to
> src/java.base/share/classes/jdk/internal/access/SharedSecrets.java
> obviously needs to be applied to
> src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The new
> file
> src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAcces
> s.java needs to be
> src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.j
> ava in 11u.
> 
>     See the full webrev here:
> http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/
>     The webrev for manual changes only:
> http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/
>     Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039
> 
>     Thanks
>     Christoph
> 
> 


From peter.levart at gmail.com  Sat Jul 13 16:09:07 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 13 Jul 2019 18:09:07 +0200
Subject: [11u]: RFR 8227650: EnumSet.class serialization broken in JDK 9+
Message-ID: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com>

Hi,

This is a review request for JDK-8227368 [1] originally applied to JDK 
13, to be backported to JDK 11 update release, tracked by JDK-8227650 [2].

The proposed patch is unchanged at first [3], but since the original 
patch required CSR [4], it might be necessary to change it a bit for JDK 
11 update release. Changes introduced in JDK 9 timeframe broke 
serialization of EnumSet.class (java.lang.Class<EnumSet>) objects, so 
this patch is trying to bring back the compatibility across all 
currently maintained releases (JDK 8, JDK 11 u, JDK 13). There will be 
no backport to JDK 8 u, since we are restoring the behavior of that 
release. Nevertheless this is a change to the serialization format and 
the published specification of it (serialized-form.html), so I'm asking 
if this is allowed in an update release. If the published specification 
matters, the patch could be tweaked so that the published 
serialized-form.html wouldn't change, only the behavior would. But this 
sounds like cheating. Please advise.

Regards, Peter

[1] https://bugs.openjdk.java.net/browse/JDK-8227368
[2] https://bugs.openjdk.java.net/browse/JDK-8227650
[3] 
http://cr.openjdk.java.net/~plevart/jdk11u-dev/8227650_EnumSet.class_serialization/webrev.01/
[4] https://bugs.openjdk.java.net/browse/JDK-8227432


From sgehwolf at redhat.com  Mon Jul 15 14:19:21 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 15 Jul 2019 16:19:21 +0200
Subject: [11u] RFR: 8227127: Era designator not displayed correctly using
 the COMPAT provider
Message-ID: <e4a93155a8e14aa7c2c72aed0e9216e45e5547ea.camel@redhat.com>

Hi,

Could I please get a review of this 11u backport? The JDK 14 patch
doesn't apply as is due to JDK-8221432 (CLDR data update) not being
present. I've fixed LocaleDataTest.java's @bug line manually. Otherwise
the patch is the same.

Bug: https://bugs.openjdk.java.net/browse/JDK-8227127
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227127/01/webrev/

Testing: tier1 and manual test from the bug on Linux x86_64.

Thanks,
Severin




From naoto.sato at oracle.com  Mon Jul 15 16:35:07 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 15 Jul 2019 09:35:07 -0700
Subject: [11u] RFR: 8227127: Era designator not displayed correctly using
 the COMPAT provider
In-Reply-To: <e4a93155a8e14aa7c2c72aed0e9216e45e5547ea.camel@redhat.com>
References: <e4a93155a8e14aa7c2c72aed0e9216e45e5547ea.camel@redhat.com>
Message-ID: <054de3bb-2d10-9167-f2b2-d74a795510c5@oracle.com>

Looks good to me.

Naoto

On 7/15/19 7:19 AM, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get a review of this 11u backport? The JDK 14 patch
> doesn't apply as is due to JDK-8221432 (CLDR data update) not being
> present. I've fixed LocaleDataTest.java's @bug line manually. Otherwise
> the patch is the same.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227127
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227127/01/webrev/
> 
> Testing: tier1 and manual test from the bug on Linux x86_64.
> 
> Thanks,
> Severin
> 
> 
> 

From stuart.marks at oracle.com  Tue Jul 16 18:09:34 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 16 Jul 2019 11:09:34 -0700
Subject: [11u]: RFR 8227650: EnumSet.class serialization broken in JDK 9+
In-Reply-To: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com>
References: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com>
Message-ID: <0bb07139-762d-1f4a-690d-2ce25a20148e@oracle.com>

On 7/13/19 9:09 AM, Peter Levart wrote:
> This is a review request for JDK-8227368 [1] originally applied to JDK 13, to 
> be backported to JDK 11 update release, tracked by JDK-8227650 [2].
>
> The proposed patch is unchanged at first [3], but since the original patch 
> required CSR [4], it might be necessary to change it a bit for JDK 11 update 
> release. Changes introduced in JDK 9 timeframe broke serialization of 
> EnumSet.class (java.lang.Class<EnumSet>) objects, so this patch is trying to 
> bring back the compatibility across all currently maintained releases (JDK 8, 
> JDK 11 u, JDK 13). There will be no backport to JDK 8 u, since we are 
> restoring the behavior of that release. Nevertheless this is a change to the 
> serialization format and the published specification of it 
> (serialized-form.html), so I'm asking if this is allowed in an update release. 
> If the published specification matters, the patch could be tweaked so that the 
> published serialized-form.html wouldn't change, only the behavior would. But 
> this sounds like cheating. Please advise.
>
> Regards, Peter
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8227368
> [2] https://bugs.openjdk.java.net/browse/JDK-8227650
> [3] 
> http://cr.openjdk.java.net/~plevart/jdk11u-dev/8227650_EnumSet.class_serialization/webrev.01/
> [4] https://bugs.openjdk.java.net/browse/JDK-8227432
>
Hi Peter,

First, thanks for finding and fixing this bug in JDK 13. I think we all learned 
a bunch more than we ever expected to about serialVersionUID!

I've been doing some investigation about how this fix can be applied to the 
backports. A straight backport as you've posted in [3] is indeed a specification 
change. It's not so much a matter of whether it's allowed or disallowed; it's 
indeed possible to make specification changes in update releases. However, doing 
so requires a JCP Maintenance Release (MR) of the corresponding Java SE 
specification JSR.

My understanding is that in the past we (Oracle) have only done MRs when it's 
been absolutely necessary and when there's no alternative. The actual decision 
though is in the hands of the update leads (Andrew Haley for JDK 11, and Rob 
McKenna for JDK 12).

In this message I'll make the case that an MR is not absolutely necessary, and 
I'll outline an alternative.

First, a bit more background.

The essence of the JDK 13 fix is that it adds the line

private static final long serialVersionUID = 1009687484059888093L;

to EnumSet.java. This changes the javadoc output of serialized-form.html. In an 
earlier message [5] I had suggested a "sleazy hack" (or, as Peter put it more 
gently, "cheating"), doing something like the following in order to avoid 
changing serialized-form.html:

private static final long serialVersionUID; static { serialVersionUID = 
1009687484059888093L; }

Indeed, this avoids changing serialized-form.html. However, there's still a 
problem. I ran JCK 11 with this patch applied to my JDK 11 build, and the result 
is that the api/serializabletypes test failed. So, cheating or sleazy hack, this 
approach doesn't really work. Although this technique avoids changing the /text/ 
of the specification output, it really is changing the specification, as far as 
the JCK is concerned.

The good news is that it's possible to change EnumSet's serialVersionUID back to 
what it was in JDK 8, without changing the specification. In effect, I reverted 
the post-JDK 8 changes that had caused changes to the svuid. These were the 
following:

1) A couple fields had been made transient.

I removed the transient modifiers. This has no practical effect on the 
serialized output, since EnumSet uses a serialization proxy. However, it had the 
effect of making those fields documented in serialized-form.html. I was able to 
suppress that by adding a serialPersistentFields field with a zero-length array.

2) The <clinit> method was removed.

The svuid computation includes the presence of a <clinit> (static initializer) 
method on the class. A non-constant expression as the initializer of a static 
field effectively creates a <clinit> even though there's no static block. The 
JDK 8 code initialized one static field with a non-constant expression. A 
post-JDK 8 change removed this, thereby removing <clinit>, thus affecting the 
svuid. The addition of the zero-length array creation for serialPersistentFields 
(above) is sufficient to reintroduce <clinit>.

3) The svuid computation includes synthetic methods, including one named access$000.

The JDK 8 code defined a private field in EnumSet that was referenced from a 
nested class, the serialization proxy. This required the addition of a bridge 
method, in this case named access$000. (This predates nestmates, which removes 
the need for such bridge methods.) A post-JDK 8 change moved this private field 
into the nested class, which removed the need for the bridge method. I was able 
to "revert" the effect of this change by adding a no-op method named access$000. 
Yes, another sleazy hack, my specialty!

**

The webrev for this changeset is [6]. I've adjusted the BogusEnumSet test 
accordingly. I didn't change the EnumSetClassSerialization test from the JDK 13 
patch. This passes the regression tests, the JCK tests, and the 
serialized-form.html is unchanged as far as I can see (except for some 
incidental markup). And of course the svuid matches that of JDK 8 -- which is 
tested by the EnumSetClassSerialization test.

This gives up some of the performance gain introduced by the intervening 
changesets. This probably causes loading of ObjectStreamField.class and 
ObjectStreamField[].class, and it (re-)introduces a static initializer. This is 
unfortunate, but it doesn't seem too terrible to me. (I haven't measured it though.)

What do you think?

s'marks


[5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-June/061114.html

[6] http://cr.openjdk.java.net/~smarks/reviews/8227368.jdk11u/webrev.0/




From gnu.andrew at redhat.com  Tue Jul 16 20:27:26 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 16 Jul 2019 21:27:26 +0100
Subject: [RFR] [11u] 11.0.4+11
Message-ID: <24c2b2f4-e8db-0267-eedc-e009dd48db5c@redhat.com>

Here are the remaining changes for the jdk11u repository:

Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.4/

Changes:
  - S8212328, CVE-2019-2762: Exceptional throw cases
  - S8213431, CVE-2019-2766: Improve file protocol handling
  - S8213432, CVE-2019-2769: Better copies of CopiesList
  - S8216381, CVE-2019-2786: More limited privilege usage
  - S8217563: Improve realm maintenance
  - S8218863: Better endpoint checks
  - S8218873: Improve JSSE endpoint checking
  - S8218876, CVE-2019-7317: Improve PNG support options
  - S8219775: Certificate validation improvements
  - S8220517: Enhanced GIF support
  - S8221345, CVE-2019-2818: Better Poly1305 support
  - S8221518, CVE-2019-2816: Normalize normalization
  - S8222678, CVE-2019-2821: Improve TLS negotiation

The result is tagged 11.0.4+11 and 11.0.4-ga.

Ok to push?

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 shade at redhat.com  Tue Jul 16 20:34:02 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Jul 2019 22:34:02 +0200
Subject: [RFR] [11u] 11.0.4+11
In-Reply-To: <24c2b2f4-e8db-0267-eedc-e009dd48db5c@redhat.com>
References: <24c2b2f4-e8db-0267-eedc-e009dd48db5c@redhat.com>
Message-ID: <7c2c36b6-254d-9738-d192-18657f0c2ba0@redhat.com>

On 7/16/19 10:27 PM, Andrew John Hughes wrote:
> Here are the remaining changes for the jdk11u repository:
> 
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.4/

Looks fine to me.

> Ok to push?

I think so.

-- 
Thanks,
-Aleksey


From gnu.andrew at redhat.com  Tue Jul 16 20:50:03 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 16 Jul 2019 21:50:03 +0100
Subject: [RFR] [11u] 11.0.4+11
In-Reply-To: <7c2c36b6-254d-9738-d192-18657f0c2ba0@redhat.com>
References: <24c2b2f4-e8db-0267-eedc-e009dd48db5c@redhat.com>
 <7c2c36b6-254d-9738-d192-18657f0c2ba0@redhat.com>
Message-ID: <7949dd4d-4f04-a78c-3c5b-2403cac40762@redhat.com>



On 16/07/2019 21:34, Aleksey Shipilev wrote:
> On 7/16/19 10:27 PM, Andrew John Hughes wrote:
>> Here are the remaining changes for the jdk11u repository:
>>
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.4/
> 
> Looks fine to me.
> 
>> Ok to push?
> 
> I think so.
> 

Thanks. Pushed.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From gnu.andrew at redhat.com  Wed Jul 17 03:44:46 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 17 Jul 2019 04:44:46 +0100
Subject: OpenJDK 11.0.4 Released
Message-ID: <6dd29be1-6a6d-1d5b-771e-03cbc439ddde@redhat.com>

We are pleased to announce the release of OpenJDK 11.0.4.

The source tarball is available from:

* https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.tar.xz

The tarball is accompanied by a digital signature available at:

* https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

d138f10168e4929ed992be99c2059b0ea46c648e1b0080ce1c44a526e498fc05
openjdk-11.0.4+11.tar.xz
afdd3f4c7cc9ad8e8e96a6929c51dfff83d41958bb004618e7bea43a1fd7d939
openjdk-11.0.4+11.tar.xz.sig

The checksums can be downloaded from:

* https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.sha256

What's New?
===========
* Security fixes
  - S8208698, CVE-2019-2745: Improved ECC Implementation
  - S8212328, CVE-2019-2762: Exceptional throw cases
  - S8213431, CVE-2019-2766: Improve file protocol handling
  - S8213432, CVE-2019-2769: Better copies of CopiesList
  - S8216381, CVE-2019-2786: More limited privilege usage
  - S8217563: Improve realm maintenance
  - S8218863: Better endpoint checks
  - S8218873: Improve JSSE endpoint checking
  - S8218876, CVE-2019-7317: Improve PNG support options
  - S8219775: Certificate validation improvements
  - S8220517: Enhanced GIF support
  - S8221345, CVE-2019-2818: Better Poly1305 support
  - S8221518, CVE-2019-2816: Normalize normalization
  - S8222678, CVE-2019-2821: Improve TLS negotiation
* Other fixes
  - S6913047: Long term memory leak when using PKCS11 and JCE exceeds 32
bit process address space
  - S8139178: Wrong fontMetrics when printing in Landscape (OpenJDK)
  - S8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java
failed with timed out
  - S8170494: JNI exception pending in PlainDatagramSocketImpl.c
  - S8174691: [TESTBUG] A number of native hotspot unit tests fail when
executed in stand-alone mode
  - S8179098: Crypto AES/ECB encryption/decryption performance
regression (introduced in jdk9b73)
  - S8181143: Introduce diagnostic flag to abort VM on too long VM
operations
  - S8188133: C2: Static field accesses in clinit can trigger
deoptimizations
  - S8190361: Incorrect version info in jaccessinspector.exe and
jaccesswalker.exe
  - S8195793: Remove GTE CyberTrust Global Root
  - S8200286: (testbug) MOptionTest test fails with
java.lang.AssertionError: Classfiles too old!
  - S8200613: SA: jstack throws UnmappedAddressException with a CDS core
file
  - S8201317: X25519/X448 code improvements
  - S8201633: Problems with AES-GCM native acceleration
  - S8202353: os::readdir should use readdir instead of readdir_r
  - S8202414: Unsafe write after primitive array creation may result in
array length change
  - S8202651: Test ComodoCA.java fails
  - S8202794: Native Unix code should use readdir rather than readdir_r
  - S8202884: SA: Attach/detach might fail on Linux if debugee
application create/destroy threads during attaching
  - S8203627: Swing applications with JRadioButton and JCheckbox fail to
render correctly when using GTK3 and the GTK L&F
  - S8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails
when running in CDS mode
  - S8205574: Loop predication "assert(f <= 1 && f >= 0) failed
Incorrect frequency"
  - S8205611: Improve the wording of LinkageErrors to include module and
class loader information
  - S8206955: MethodHandleProxies.asInterfaceInstance does not support
default methods
  - S8207340: (fs) UnixNativeDispatcher close and readdir usages should
be fixed
  - S8207748: Fix for 8202794 breaks tier1 builds
  - S8207760: SAXException: Invalid UTF-16 surrogate detected: d83c ?
  - S8208634: Add x-IBM-1129 charset
  - S8208648: ECC Field Arithmetic Enhancements
  - S8208702:
javax/swing/reliability/HangDuringStaticInitialization.java may hang on
macos
  - S8208996: X11 icon window color handing bug
  - S8209055: c.s.t.javac.code.DeferredCompletionFailureHandler seems to
use WeakHashMap incorrectly
  - S8209414: AArch64: method handle invocation does not respect JVMTI
interp_only mode
  - S8209415: Fix JVMTI test failure HS202
  - S8209573: [TESTBUG] gc/epsilon/TestMemoryMXBeans should retry on failure
  - S8209914: javadoc search sometimes generates bad URIs
  - S8209951: Problematic sparc intrinsic:
com.sun.crypto.provider.CipherBlockChaining
  - S8210008: custom extension for make/SourceRevision.gmk
  - S8210197: javac can't tell during speculative attribution if a
diamond expression is creating an anonymous inner class or not
  - S8210283: Support git as an SCM alternative in the build
  - S8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code
  - S8210457: JVM crash in ResolvedMethodTable::add_method(Handle)
  - S8210483: AssertionError in DeferredAttr at setOverloadKind caused
by JDK-8203679
  - S8210519: build/releaseFile/CheckSource.java failed additional
sources found
  - S8210739: Calling JSpinner's setFont with null throws
NullPointerException
  - S8210782: Upgrade HarfBuzz to the latest 2.3.1
  - S8210803: Compilation failure in codeBlob.cpp for Windows 32-bit
  - S8210837: Add libXrandr-devel to the Linux devkits
  - S8210863: Remove Xrandr include files from JDK sources
  - S8210880: Remove HPKeysym.h from JDK sources
  - S8210886: Remove references in xwindows.md to non-existent files.
  - S8210899: (zipfs) ZipFileSystem.EntryOutputStreamCRC32 mistakenly
set the crc32 value into size field
  - S8211266: [TESTBUG] ZipFSTester.java failed intermittently in
ZipFSTester.checkRead(): bound must be positive
  - S8211350: Remove jprt support
  - S8211393: Memory leak issue on awt_InputMethod.c
  - S8211435: Exception in thread "AWT-EventQueue-1"
java.lang.IllegalArgumentException: null source
  - S8211698: Crash in C2 compiled code during execution of double array
heavy processing code
  - S8211810: X11 Time stamp data should be unsigned
  - S8211826: StringIndexOutOfBoundsException happens via
GetStringUTFRegion()
  - S8211841: [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix)
  - S8211969: test/jdk/lib/security/CheckBlacklistedCerts.java searching
for wrong paths
  - S8211971: Move security/cacerts/VerifyCACerts.java and
security/CheckBlacklistedCerts.java
  - S8212202: [Windows] Exception if no printers are installed.
  - S8212205: VM asserts after CDS archive has been unmapped
  - S8212562: To remove lib/security from test/jdk/TEST.groups
  - S8212676: AWT SystemColor setting on CDE
  - S8212677: X11 default visual support for IM status window on VNC
  - S8212678: Windows IME related patch
  - S8212794: IBM-964 is required for AIX default charset
  - S8212828: (process) Provide a way for Runtime.exec to use
posix_spawn on linux
  - S8213015: Inconsistent settings between JFR.configure and
-XX:FlightRecorderOptions
  - S8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h
  - S8213232: Unix/X11 setCompositionEnableNative issue
  - S8213292: Input freezes after MacOS key-selector (press&hold) usage
on macOS Mojave
  - S8213294: Upgrade IANA LSR data
  - S8213515: Improve freetype detection on linux/ppc64/ppc64le/s390x
  - S8213614: DnD operation change feature does not work with 64bit big
endian CPU
  - S8213617: JFR should record the PID of the recorded process
  - S8213618: IBM970 charset has missing entry and remove unexpected entries
  - S8213825: assert(false) failed: Non-balanced monitor enter/exit!
Likely JNI locking
  - S8213944: Fix AIX build after the removal of Xrandr.h and add a
configure check for it
  - S8214002: Cannot use italic font style if the font has embedded bitmap
  - S8214109: XToolkit is not correctly displayed color on 16-bit high
color setting
  - S8214111: There is no icon in all JOptionPane target image
  - S8214112: The whole text in target JPasswordField image are not selected
  - S8214252: Expanded & Collapsed nodes of a JTree look the same on GTK3
  - S8214253: Tooltip is transparent rather than having a black background
  - S8214468: jQuery UI upgrade from 1.11.4 to 1.12.1
  - S8214533: IBM-29626C is required for AIX default charset
  - S8214765: All TrayIcon MessageType icons does not show up with gtk3
option set
  - S8214935: Upgrade IANA LSR data
  - S8215026: Incorrect amount of memory unmapped with
ImageFileReader::close()
  - S8215123: Crash in runtime image built with jlink --compress=2
  - S8215284: Reduce noise induced by periodic task getFileSize()
  - S8215296: do not disable c99 on Solaris
  - S8215342: [Zero] Build fails after JDK-8200613
  - S8215364: JavaFX crashes on Ubuntu 18.04 with Wayland while using
Swing-FX interop
  - S8215374: 32-bit build failures after JDK-8181143 (Introduce
diagnostic flag to abort VM on too long VM operations)
  - S8215398: -Xlog option usage => Invalid decorator '\temp\app_cds.log'.
  - S8215443: The use of TransportContext.fatal() leads to bad coding style
  - S8215472: (zipfs) Cleanups in implementation classes of jdk.zipfs
and tests
  - S8215707: [macosx] fix pthread_getschedparam and
pthread_setschedparam calls
  - S8215757: C2: PhaseIdealLoop::create_new_if_for_predicate() computes
wrong IDOM
  - S8215790: Delegated task created by SSLEngine throws
java.nio.BufferUnderflowException
  - S8216045: The size of key_exchange may be wrong on FFDHE
  - S8216355: missing NULL checks in libnet in interface iteration and
potential resource leak in getMacAddress
  - S8216556: Unnecessary liveness computation with JVMTI
  - S8216577: Add GlobalSign's R6 Root certificate
  - S8216597: SIGBUS in
Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047
  - S8216970: condy causes JVM crash
  - S8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after
JDK-8216597 (SIGBUS error in getNativeKeyInfo)
  - S8217094: HttpClient SSL race if a socket IOException is raised
before ALPN is available
  - S8217263: Automate DashOffset test
  - S8217311: Improve Exception thrown when MulticastSocket.setInterface
fails on AIX(Unix)
  - S8217564: idempotent protection missing in crc32c.h
  - S8217647: JFR: recordings on 32-bit systems unreadable
  - S8217690: Update public suffix version
  - S8217707: JNICALL declaration breaks Splash screen functions
  - S8217765: Internal Error (javaCalls.cpp:61)
guarantee(thread->can_call_java()) failed
  - S8217786: Provide virtualization related info in the hs_error file
on linux s390x
  - S8217878: ENVELOPING XML signature no longer works in JDK 11
  - S8217879: hs_err should print more instructions in hex dump
  - S8217880: AIX build issue after JDK-8214533
  - S8218020: Fix version number in mesa.md 3rd party legal file
  - S8218060: JDK-8217786 breaks build due to remaining unused function
  - S8218063: JDK-8218060 breaks build for S390
  - S8218152: [javac] fails and exits with no error if a bad annotation
processor provided
  - S8218469: JSlider display issue with slider for GTKLookAndFeel
  - S8218470: JScrollBar display issue with GTKLookAndFeel
  - S8218472: JProgressBar display issue with GTKLookAndFeel
  - S8218473: JOptionPane display issue with GTKLookAndFeel
  - S8218479: JTextPane display issue with GTKLookAndFeel
  - S8218618: Program fails when using JDK addressed by UNC path and
using Security Manager
  - S8218629: XML Digital Signature throws NAMESPACE_ERR exception on
OpenJDK 11, works 8/9/10
  - S8218674: HTML Tooltip with "img=src" on component doesn't show
  - S8218733: SA: CollectedHeap provides broken implementation for
used() and capacity()
  - S8218781: Localized names for Japanese era Reiwa in COMPAT provider
  - S8218811: replace open by os::open in hotspot coding
  - S8218854: FontMetrics.getMaxAdvance may be less than the maximum
FontMetrics.charWidth
  - S8218960: CONFIG level logging statements printed in
CLDRCalendarDataProviderImpl.java even when default log Level is INFO
  - S8218991: s390: Add intrinsic for GHASH algorithm
  - S8219006: AArch64: Register corruption in slow subtype check
  - S8219011: Implement MacroAssembler::warn method on AArch64
  - S8219112: name_and_sig_as_C_string usages in frame_s390 miss
ResourceMark
  - S8219335: "failed: unexpected type" assert failure in
ConnectionGraph::split_unique_types() with unsafe accesses
  - S8219389: Delegated task created by SSLEngine throws
BufferUnderflowException
  - S8219414: SA: jhsdb jsnap throws UnmappedAddressException with core
generated by gcore
  - S8219448: split-if update_uses accesses stale idom data
  - S8219460: ppc: adjust NativeGeneralJump::insert_unconditional to
stack allocated MacroAssembler
  - S8219566: JFR did not collect call stacks when
MaxJavaStackTraceDepth is set to zero
  - S8219574: Minimal VM build failure after JDK-8219414
  - S8219582: PPC: Crash after C1 checkcast patched and GC
  - S8219584: Try to dump error file by thread which causes safepoint
timeout
  - S8219698: aarch64: SIGILL triggered when specifying unsupported
hardware features
  - S8219710: Bump update version for OpenJDK: jdk11.0.4
  - S8219746: Provide virtualization related info in the hs_error file
on linux ppc64 / ppc64le

  - S8219915: [TESTBUG] Fix test
langtools/tools/javac/processing/model/completionfailure/SymbolsDontCumulate.java
in Standalone mode
  - S8219918: ProblemList hotspot tests failing in SAP testing.
  - S8220165: Encryption using GCM results in RuntimeException- input
length out of bound
  - S8220166: Performance regression in deserialization (4-6% in SPECjbb)
  - S8220198: Lots of com/sun/crypto/provider/Cipher tests fail on
x86_32 due to missing SHA512 stubs
  - S8220281: IBM-858 alias name is missing on IBM00858 charset
  - S8220293: Deadlock in JFR string pool
  - S8220349: The fix done for JDK-8214253 have caused issues in JTree
behaviour
  - S8220353: [TESTBUG] TestRegisterRestoring uses SafepointALot without
UnlockDiagnosticVMOptions
  - S8220374: C2: LoopStripMining doesn't strip as expected
  - S8220441: [PPC64] Clobber memory effect missing for memory barriers
in atomics
  - S8220495: Update GIFlib library to the 5.1.8
  - S8220513: Wrapper Key may get deleted when closing sessions in
SunPKCS11 crypto provider
  - S8220625: tools/javac/classreader/8171132/BadConstantValue.java
failed with "did not see expected error"
  - S8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java
fails with jtreg -vmoption:-Xmx < 8g
  - S8220714: C2 Compilation failure when accessing off-heap memory
using Unsafe
  - S8220718: Missing ResourceMark in nmethod::metadata_do
  - S8220781: linux-s390 : os::get_summary_cpu_info gives bad output
  - S8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal
address
  - S8221083: [ppc64] Wrong oop compare in C1-generated code
  - S8221175: Fix bad function case for controlled JVM crash on PPC64
big-endian
  - S8221244: Unexpected behavior of PropertyDescription.getReadMethod
for boolean properties
  - S8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use
  - S8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java
  - S8221400: java/lang/String/StringRepeat.java test requests too much heap
  - S8221401: java/math/BigInteger/LargeValueExceptions.java test should
be disabled on 32-bit platforms
  - S8221412: lookupPrintServices() does not always update the list of
Windows remote printers
  - S8221437:
assert(java_lang_invoke_ResolvedMethodName::vmtarget(resolved_method())
== m()) failed: Should not change after link resolution
  - S8221470: Print methods in exception messages in java-like Syntax.
  - S8221479: Fix JFR profiling on s390
  - S8221483: TestOopCmp.java fails due to "Multiple garbage collectors
selected"
  - S8221535: add steal tick related information to hs_error file [linux]
  - S8221610: Resurrect (legacy) JRE bundle target
  - S8221639: [i386] expand_exec_shield_cs_limit workaround is undefined
code after JDK-8199717
  - S8221833: Readability check in Symbol::is_valid not performed for
some addresses
  - S8221870: use driver to run CtwRunner in applications/ctw tests
  - S8221880: Better customization for Windows RC properties
FileDescription and ProductName
  - S8221915: cleanup ticks related coding in os_perf_aix.cpp [aix]
  - S8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms
  - S8221924: get(null) on single-entry unmodifiable Map returns null
instead of throwing NPE
  - S8222027: java/util/logging/LogManager/TestLoggerNames.java
generates intermittent ClassCastException
  - S8222032: x86_32 fails with "wrong size of mach node" on AVX-512 machine
  - S8222089: [TESTBUG] sun/security/lib/cacerts/VerifyCACerts.java
fails due to cert within 90-day expiry window
  - S8222133: Add temporary exceptions for root certs that are due to
expire soon
  - S8222136: Remove two Comodo root CA certificates that are expiring
  - S8222137: Remove T-Systems root CA certificate
  - S8222397: x86_32 tests with UseSHA1Intrinsics SEGV due to garbled
registers
  - S8222410:
java/nio/file/attribute/BasicFileAttributeView/UnixSocketFile hangs when
"nc" does not accept "-U"
  - S8222522: Add configure options for Mac Bundle creation
  - S8222532: (zipfs) Performance regression when writing ZipFileSystem
entries in parallel
  - S8222913: Add Jib support for VERSION_EXTRA*
  - S8222930: ConcurrentSkipListMap.clone() shares size variable between
original and clone
  - S8223266: PPC64: Check for branch to illegal address before checking
for mem serialization
  - S8223395: PPC64: Improve comments in the JVM signal handler to match
ISA text
  - S8223499: Remove two DocuSign root certificates that are expiring
  - S8223555: Cleanups in cacerts tests
  - S8223597: jdk/nio/zipfs/ZipFSTester.java RuntimeException:
CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)
  - S8223665: SA: debugd options should follow jhsdb style
  - S8224474: harfbuzz 2.3.1 code fails to compile with gcc 4.4.7
  - S8224671: AArch64: mauve System.arraycopy test failure
  - S8224727: Problem list test
security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java
  - S8224828: aarch64: rflags is not correct after safepoint poll
  - S8224880: AArch64: java/javac error with AllocatePrefetchDistance
  - S8225402: events logging in deoptimization.cpp should go to deopt-log
  - S8225716: G1 GC: Undefined behaviour in
G1BlockOffsetTablePart::block_at_or_preceding
  - S8226876: Assertion in sun/util/locale/provider/CalendarDataUtility
on Windows after JDK-8218960
  - S8226880: Backport of JDK-8208698 (Improved ECC Implementation)
should not bring parts of JDK-8205476 (KeyAgreement#generateSecret is
not reset for ECDH based algorithm)

-- 
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 martijnverburg at gmail.com  Wed Jul 17 07:56:14 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 17 Jul 2019 08:56:14 +0100
Subject: 12.0.2-ga and 13.0.0-ga tags?
Message-ID: <CAP7YuARctZMQCrC0E05E=d6aAajVAxMcfZOTV5bygwQyynMYwQ@mail.gmail.com>

Hi all,

I suspect I'm being really dense but were there 12.0.2-ga and 13.0.0-ga
tags due to be pushed yesterday or today?

Cheers,
Martijn

From shade at redhat.com  Wed Jul 17 08:04:34 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Jul 2019 10:04:34 +0200
Subject: 12.0.2-ga and 13.0.0-ga tags?
In-Reply-To: <CAP7YuARctZMQCrC0E05E=d6aAajVAxMcfZOTV5bygwQyynMYwQ@mail.gmail.com>
References: <CAP7YuARctZMQCrC0E05E=d6aAajVAxMcfZOTV5bygwQyynMYwQ@mail.gmail.com>
Message-ID: <37ff7003-aaec-ddc0-0053-869dc23057a4@redhat.com>

On 7/17/19 9:56 AM, Martijn Verburg wrote:
> I suspect I'm being really dense but were there 12.0.2-ga and 13.0.0-ga
> tags due to be pushed yesterday or today?

13 is due to release in September, you cannot expect GA at this time.

12 repo does not even have the security patches pushed in, AFAICS. I believe the tag would follow in
the same push. I'd wait for Rob to push those,

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jul 17 08:15:28 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Jul 2019 10:15:28 +0200
Subject: 12.0.2-ga and 13.0.0-ga tags?
In-Reply-To: <37ff7003-aaec-ddc0-0053-869dc23057a4@redhat.com>
References: <CAP7YuARctZMQCrC0E05E=d6aAajVAxMcfZOTV5bygwQyynMYwQ@mail.gmail.com>
 <37ff7003-aaec-ddc0-0053-869dc23057a4@redhat.com>
Message-ID: <84b23d87-842d-2bba-fb15-3defe0ced93a@redhat.com>

On 7/17/19 10:04 AM, Aleksey Shipilev wrote:
> On 7/17/19 9:56 AM, Martijn Verburg wrote:
>> I suspect I'm being really dense but were there 12.0.2-ga and 13.0.0-ga
>> tags due to be pushed yesterday or today?
> 
> 13 is due to release in September, you cannot expect GA at this time.
> 
> 12 repo does not even have the security patches pushed in, AFAICS. I believe the tag would follow in
> the same push. I'd wait for Rob to push those,

...after Robs wakes up and has his morning coffee. (Sent the note too early. Clearly, I should have
had my own coffee first).

-- 
Thanks,
-Aleksey


From peter.levart at gmail.com  Wed Jul 17 09:23:21 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 17 Jul 2019 11:23:21 +0200
Subject: [11u]: RFR 8227650: EnumSet.class serialization broken in JDK 9+
In-Reply-To: <0bb07139-762d-1f4a-690d-2ce25a20148e@oracle.com>
References: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com>
 <0bb07139-762d-1f4a-690d-2ce25a20148e@oracle.com>
Message-ID: <a763a2f6-d3c2-5170-a806-a1b3359048fc@gmail.com>

Hi Stuart,

On 7/16/19 8:09 PM, Stuart Marks wrote:
>
> doing something like the following in order to avoid changing 
> serialized-form.html:
>
> private static final long serialVersionUID; static { serialVersionUID 
> = 1009687484059888093L; }
>
> Indeed, this avoids changing serialized-form.html. However, there's 
> still a problem. I ran JCK 11 with this patch applied to my JDK 11 
> build, and the result is that the api/serializabletypes test failed. 
> So, cheating or sleazy hack, this approach doesn't really work. 
> Although this technique avoids changing the /text/ of the 
> specification output, it really is changing the specification, as far 
> as the JCK is concerned.
>

It would be interesting to know what the api/serializabletypes JCK 11 
test does. Why does it fail when svuid field is introduced?

Otherwise, your "sleazy hacks" to fabricate the correct (as of JDK 8) 
computed svuid seem OK. The only gripe is that should any further 
changes to EnumSet be necessary in JDK 11 u, they would have to be 
carefully constructed to not break the serialization again. At least 
there is a test for that now :-)

Regards, Peter


From martijnverburg at gmail.com  Wed Jul 17 09:23:20 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 17 Jul 2019 10:23:20 +0100
Subject: 12.0.2-ga and 13.0.0-ga tags?
In-Reply-To: <84b23d87-842d-2bba-fb15-3defe0ced93a@redhat.com>
References: <CAP7YuARctZMQCrC0E05E=d6aAajVAxMcfZOTV5bygwQyynMYwQ@mail.gmail.com>
 <37ff7003-aaec-ddc0-0053-869dc23057a4@redhat.com>
 <84b23d87-842d-2bba-fb15-3defe0ced93a@redhat.com>
Message-ID: <CAP7YuAR6nA8Lk3iamCOGWGtc438Dac6+mLG++Dun98ZVSVS=Cg@mail.gmail.com>

Thanks, Aleksey - I figured I'd gotten my dates wrong!

Cheers,
Martijn


On Wed, 17 Jul 2019 at 09:15, Aleksey Shipilev <shade at redhat.com> wrote:

> On 7/17/19 10:04 AM, Aleksey Shipilev wrote:
> > On 7/17/19 9:56 AM, Martijn Verburg wrote:
> >> I suspect I'm being really dense but were there 12.0.2-ga and 13.0.0-ga
> >> tags due to be pushed yesterday or today?
> >
> > 13 is due to release in September, you cannot expect GA at this time.
> >
> > 12 repo does not even have the security patches pushed in, AFAICS. I
> believe the tag would follow in
> > the same push. I'd wait for Rob to push those,
>
> ...after Robs wakes up and has his morning coffee. (Sent the note too
> early. Clearly, I should have
> had my own coffee first).
>
> --
> Thanks,
> -Aleksey
>
>

From goetz.lindenmaier at sap.com  Wed Jul 17 10:26:55 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 17 Jul 2019 10:26:55 +0000
Subject: OpenJDK 11.0.4 Released
In-Reply-To: <6dd29be1-6a6d-1d5b-771e-03cbc439ddde@redhat.com>
References: <6dd29be1-6a6d-1d5b-771e-03cbc439ddde@redhat.com>
Message-ID: <3923E2C5-783E-4A32-96B5-3A8A81718531@sap.com>

Hi Andrew,

Thanks for porting the closed changes and 
pushing them such timely again!
Great job!

Best regards,
  G?tz

> Am 17.07.2019 um 05:46 schrieb Andrew John Hughes <gnu.andrew at redhat.com>:
> 
> We are pleased to announce the release of OpenJDK 11.0.4.
> 
> The source tarball is available from:
> 
> * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.tar.xz
> 
> The tarball is accompanied by a digital signature available at:
> 
> * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.tar.xz.sig
> 
> This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):
> 
> PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
> Fingerprint = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F
> 
> SHA256 checksums:
> 
> d138f10168e4929ed992be99c2059b0ea46c648e1b0080ce1c44a526e498fc05
> openjdk-11.0.4+11.tar.xz
> afdd3f4c7cc9ad8e8e96a6929c51dfff83d41958bb004618e7bea43a1fd7d939
> openjdk-11.0.4+11.tar.xz.sig
> 
> The checksums can be downloaded from:
> 
> * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.sha256
> 
> What's New?
> ===========
> * Security fixes
>  - S8208698, CVE-2019-2745: Improved ECC Implementation
>  - S8212328, CVE-2019-2762: Exceptional throw cases
>  - S8213431, CVE-2019-2766: Improve file protocol handling
>  - S8213432, CVE-2019-2769: Better copies of CopiesList
>  - S8216381, CVE-2019-2786: More limited privilege usage
>  - S8217563: Improve realm maintenance
>  - S8218863: Better endpoint checks
>  - S8218873: Improve JSSE endpoint checking
>  - S8218876, CVE-2019-7317: Improve PNG support options
>  - S8219775: Certificate validation improvements
>  - S8220517: Enhanced GIF support
>  - S8221345, CVE-2019-2818: Better Poly1305 support
>  - S8221518, CVE-2019-2816: Normalize normalization
>  - S8222678, CVE-2019-2821: Improve TLS negotiation
> * Other fixes
>  - S6913047: Long term memory leak when using PKCS11 and JCE exceeds 32
> bit process address space
>  - S8139178: Wrong fontMetrics when printing in Landscape (OpenJDK)
>  - S8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java
> failed with timed out
>  - S8170494: JNI exception pending in PlainDatagramSocketImpl.c
>  - S8174691: [TESTBUG] A number of native hotspot unit tests fail when
> executed in stand-alone mode
>  - S8179098: Crypto AES/ECB encryption/decryption performance
> regression (introduced in jdk9b73)
>  - S8181143: Introduce diagnostic flag to abort VM on too long VM
> operations
>  - S8188133: C2: Static field accesses in clinit can trigger
> deoptimizations
>  - S8190361: Incorrect version info in jaccessinspector.exe and
> jaccesswalker.exe
>  - S8195793: Remove GTE CyberTrust Global Root
>  - S8200286: (testbug) MOptionTest test fails with
> java.lang.AssertionError: Classfiles too old!
>  - S8200613: SA: jstack throws UnmappedAddressException with a CDS core
> file
>  - S8201317: X25519/X448 code improvements
>  - S8201633: Problems with AES-GCM native acceleration
>  - S8202353: os::readdir should use readdir instead of readdir_r
>  - S8202414: Unsafe write after primitive array creation may result in
> array length change
>  - S8202651: Test ComodoCA.java fails
>  - S8202794: Native Unix code should use readdir rather than readdir_r
>  - S8202884: SA: Attach/detach might fail on Linux if debugee
> application create/destroy threads during attaching
>  - S8203627: Swing applications with JRadioButton and JCheckbox fail to
> render correctly when using GTK3 and the GTK L&F
>  - S8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails
> when running in CDS mode
>  - S8205574: Loop predication "assert(f <= 1 && f >= 0) failed
> Incorrect frequency"
>  - S8205611: Improve the wording of LinkageErrors to include module and
> class loader information
>  - S8206955: MethodHandleProxies.asInterfaceInstance does not support
> default methods
>  - S8207340: (fs) UnixNativeDispatcher close and readdir usages should
> be fixed
>  - S8207748: Fix for 8202794 breaks tier1 builds
>  - S8207760: SAXException: Invalid UTF-16 surrogate detected: d83c ?
>  - S8208634: Add x-IBM-1129 charset
>  - S8208648: ECC Field Arithmetic Enhancements
>  - S8208702:
> javax/swing/reliability/HangDuringStaticInitialization.java may hang on
> macos
>  - S8208996: X11 icon window color handing bug
>  - S8209055: c.s.t.javac.code.DeferredCompletionFailureHandler seems to
> use WeakHashMap incorrectly
>  - S8209414: AArch64: method handle invocation does not respect JVMTI
> interp_only mode
>  - S8209415: Fix JVMTI test failure HS202
>  - S8209573: [TESTBUG] gc/epsilon/TestMemoryMXBeans should retry on failure
>  - S8209914: javadoc search sometimes generates bad URIs
>  - S8209951: Problematic sparc intrinsic:
> com.sun.crypto.provider.CipherBlockChaining
>  - S8210008: custom extension for make/SourceRevision.gmk
>  - S8210197: javac can't tell during speculative attribution if a
> diamond expression is creating an anonymous inner class or not
>  - S8210283: Support git as an SCM alternative in the build
>  - S8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code
>  - S8210457: JVM crash in ResolvedMethodTable::add_method(Handle)
>  - S8210483: AssertionError in DeferredAttr at setOverloadKind caused
> by JDK-8203679
>  - S8210519: build/releaseFile/CheckSource.java failed additional
> sources found
>  - S8210739: Calling JSpinner's setFont with null throws
> NullPointerException
>  - S8210782: Upgrade HarfBuzz to the latest 2.3.1
>  - S8210803: Compilation failure in codeBlob.cpp for Windows 32-bit
>  - S8210837: Add libXrandr-devel to the Linux devkits
>  - S8210863: Remove Xrandr include files from JDK sources
>  - S8210880: Remove HPKeysym.h from JDK sources
>  - S8210886: Remove references in xwindows.md to non-existent files.
>  - S8210899: (zipfs) ZipFileSystem.EntryOutputStreamCRC32 mistakenly
> set the crc32 value into size field
>  - S8211266: [TESTBUG] ZipFSTester.java failed intermittently in
> ZipFSTester.checkRead(): bound must be positive
>  - S8211350: Remove jprt support
>  - S8211393: Memory leak issue on awt_InputMethod.c
>  - S8211435: Exception in thread "AWT-EventQueue-1"
> java.lang.IllegalArgumentException: null source
>  - S8211698: Crash in C2 compiled code during execution of double array
> heavy processing code
>  - S8211810: X11 Time stamp data should be unsigned
>  - S8211826: StringIndexOutOfBoundsException happens via
> GetStringUTFRegion()
>  - S8211841: [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix)
>  - S8211969: test/jdk/lib/security/CheckBlacklistedCerts.java searching
> for wrong paths
>  - S8211971: Move security/cacerts/VerifyCACerts.java and
> security/CheckBlacklistedCerts.java
>  - S8212202: [Windows] Exception if no printers are installed.
>  - S8212205: VM asserts after CDS archive has been unmapped
>  - S8212562: To remove lib/security from test/jdk/TEST.groups
>  - S8212676: AWT SystemColor setting on CDE
>  - S8212677: X11 default visual support for IM status window on VNC
>  - S8212678: Windows IME related patch
>  - S8212794: IBM-964 is required for AIX default charset
>  - S8212828: (process) Provide a way for Runtime.exec to use
> posix_spawn on linux
>  - S8213015: Inconsistent settings between JFR.configure and
> -XX:FlightRecorderOptions
>  - S8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h
>  - S8213232: Unix/X11 setCompositionEnableNative issue
>  - S8213292: Input freezes after MacOS key-selector (press&hold) usage
> on macOS Mojave
>  - S8213294: Upgrade IANA LSR data
>  - S8213515: Improve freetype detection on linux/ppc64/ppc64le/s390x
>  - S8213614: DnD operation change feature does not work with 64bit big
> endian CPU
>  - S8213617: JFR should record the PID of the recorded process
>  - S8213618: IBM970 charset has missing entry and remove unexpected entries
>  - S8213825: assert(false) failed: Non-balanced monitor enter/exit!
> Likely JNI locking
>  - S8213944: Fix AIX build after the removal of Xrandr.h and add a
> configure check for it
>  - S8214002: Cannot use italic font style if the font has embedded bitmap
>  - S8214109: XToolkit is not correctly displayed color on 16-bit high
> color setting
>  - S8214111: There is no icon in all JOptionPane target image
>  - S8214112: The whole text in target JPasswordField image are not selected
>  - S8214252: Expanded & Collapsed nodes of a JTree look the same on GTK3
>  - S8214253: Tooltip is transparent rather than having a black background
>  - S8214468: jQuery UI upgrade from 1.11.4 to 1.12.1
>  - S8214533: IBM-29626C is required for AIX default charset
>  - S8214765: All TrayIcon MessageType icons does not show up with gtk3
> option set
>  - S8214935: Upgrade IANA LSR data
>  - S8215026: Incorrect amount of memory unmapped with
> ImageFileReader::close()
>  - S8215123: Crash in runtime image built with jlink --compress=2
>  - S8215284: Reduce noise induced by periodic task getFileSize()
>  - S8215296: do not disable c99 on Solaris
>  - S8215342: [Zero] Build fails after JDK-8200613
>  - S8215364: JavaFX crashes on Ubuntu 18.04 with Wayland while using
> Swing-FX interop
>  - S8215374: 32-bit build failures after JDK-8181143 (Introduce
> diagnostic flag to abort VM on too long VM operations)
>  - S8215398: -Xlog option usage => Invalid decorator '\temp\app_cds.log'.
>  - S8215443: The use of TransportContext.fatal() leads to bad coding style
>  - S8215472: (zipfs) Cleanups in implementation classes of jdk.zipfs
> and tests
>  - S8215707: [macosx] fix pthread_getschedparam and
> pthread_setschedparam calls
>  - S8215757: C2: PhaseIdealLoop::create_new_if_for_predicate() computes
> wrong IDOM
>  - S8215790: Delegated task created by SSLEngine throws
> java.nio.BufferUnderflowException
>  - S8216045: The size of key_exchange may be wrong on FFDHE
>  - S8216355: missing NULL checks in libnet in interface iteration and
> potential resource leak in getMacAddress
>  - S8216556: Unnecessary liveness computation with JVMTI
>  - S8216577: Add GlobalSign's R6 Root certificate
>  - S8216597: SIGBUS in
> Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047
>  - S8216970: condy causes JVM crash
>  - S8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after
> JDK-8216597 (SIGBUS error in getNativeKeyInfo)
>  - S8217094: HttpClient SSL race if a socket IOException is raised
> before ALPN is available
>  - S8217263: Automate DashOffset test
>  - S8217311: Improve Exception thrown when MulticastSocket.setInterface
> fails on AIX(Unix)
>  - S8217564: idempotent protection missing in crc32c.h
>  - S8217647: JFR: recordings on 32-bit systems unreadable
>  - S8217690: Update public suffix version
>  - S8217707: JNICALL declaration breaks Splash screen functions
>  - S8217765: Internal Error (javaCalls.cpp:61)
> guarantee(thread->can_call_java()) failed
>  - S8217786: Provide virtualization related info in the hs_error file
> on linux s390x
>  - S8217878: ENVELOPING XML signature no longer works in JDK 11
>  - S8217879: hs_err should print more instructions in hex dump
>  - S8217880: AIX build issue after JDK-8214533
>  - S8218020: Fix version number in mesa.md 3rd party legal file
>  - S8218060: JDK-8217786 breaks build due to remaining unused function
>  - S8218063: JDK-8218060 breaks build for S390
>  - S8218152: [javac] fails and exits with no error if a bad annotation
> processor provided
>  - S8218469: JSlider display issue with slider for GTKLookAndFeel
>  - S8218470: JScrollBar display issue with GTKLookAndFeel
>  - S8218472: JProgressBar display issue with GTKLookAndFeel
>  - S8218473: JOptionPane display issue with GTKLookAndFeel
>  - S8218479: JTextPane display issue with GTKLookAndFeel
>  - S8218618: Program fails when using JDK addressed by UNC path and
> using Security Manager
>  - S8218629: XML Digital Signature throws NAMESPACE_ERR exception on
> OpenJDK 11, works 8/9/10
>  - S8218674: HTML Tooltip with "img=src" on component doesn't show
>  - S8218733: SA: CollectedHeap provides broken implementation for
> used() and capacity()
>  - S8218781: Localized names for Japanese era Reiwa in COMPAT provider
>  - S8218811: replace open by os::open in hotspot coding
>  - S8218854: FontMetrics.getMaxAdvance may be less than the maximum
> FontMetrics.charWidth
>  - S8218960: CONFIG level logging statements printed in
> CLDRCalendarDataProviderImpl.java even when default log Level is INFO
>  - S8218991: s390: Add intrinsic for GHASH algorithm
>  - S8219006: AArch64: Register corruption in slow subtype check
>  - S8219011: Implement MacroAssembler::warn method on AArch64
>  - S8219112: name_and_sig_as_C_string usages in frame_s390 miss
> ResourceMark
>  - S8219335: "failed: unexpected type" assert failure in
> ConnectionGraph::split_unique_types() with unsafe accesses
>  - S8219389: Delegated task created by SSLEngine throws
> BufferUnderflowException
>  - S8219414: SA: jhsdb jsnap throws UnmappedAddressException with core
> generated by gcore
>  - S8219448: split-if update_uses accesses stale idom data
>  - S8219460: ppc: adjust NativeGeneralJump::insert_unconditional to
> stack allocated MacroAssembler
>  - S8219566: JFR did not collect call stacks when
> MaxJavaStackTraceDepth is set to zero
>  - S8219574: Minimal VM build failure after JDK-8219414
>  - S8219582: PPC: Crash after C1 checkcast patched and GC
>  - S8219584: Try to dump error file by thread which causes safepoint
> timeout
>  - S8219698: aarch64: SIGILL triggered when specifying unsupported
> hardware features
>  - S8219710: Bump update version for OpenJDK: jdk11.0.4
>  - S8219746: Provide virtualization related info in the hs_error file
> on linux ppc64 / ppc64le
> 
>  - S8219915: [TESTBUG] Fix test
> langtools/tools/javac/processing/model/completionfailure/SymbolsDontCumulate.java
> in Standalone mode
>  - S8219918: ProblemList hotspot tests failing in SAP testing.
>  - S8220165: Encryption using GCM results in RuntimeException- input
> length out of bound
>  - S8220166: Performance regression in deserialization (4-6% in SPECjbb)
>  - S8220198: Lots of com/sun/crypto/provider/Cipher tests fail on
> x86_32 due to missing SHA512 stubs
>  - S8220281: IBM-858 alias name is missing on IBM00858 charset
>  - S8220293: Deadlock in JFR string pool
>  - S8220349: The fix done for JDK-8214253 have caused issues in JTree
> behaviour
>  - S8220353: [TESTBUG] TestRegisterRestoring uses SafepointALot without
> UnlockDiagnosticVMOptions
>  - S8220374: C2: LoopStripMining doesn't strip as expected
>  - S8220441: [PPC64] Clobber memory effect missing for memory barriers
> in atomics
>  - S8220495: Update GIFlib library to the 5.1.8
>  - S8220513: Wrapper Key may get deleted when closing sessions in
> SunPKCS11 crypto provider
>  - S8220625: tools/javac/classreader/8171132/BadConstantValue.java
> failed with "did not see expected error"
>  - S8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java
> fails with jtreg -vmoption:-Xmx < 8g
>  - S8220714: C2 Compilation failure when accessing off-heap memory
> using Unsafe
>  - S8220718: Missing ResourceMark in nmethod::metadata_do
>  - S8220781: linux-s390 : os::get_summary_cpu_info gives bad output
>  - S8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal
> address
>  - S8221083: [ppc64] Wrong oop compare in C1-generated code
>  - S8221175: Fix bad function case for controlled JVM crash on PPC64
> big-endian
>  - S8221244: Unexpected behavior of PropertyDescription.getReadMethod
> for boolean properties
>  - S8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use
>  - S8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java
>  - S8221400: java/lang/String/StringRepeat.java test requests too much heap
>  - S8221401: java/math/BigInteger/LargeValueExceptions.java test should
> be disabled on 32-bit platforms
>  - S8221412: lookupPrintServices() does not always update the list of
> Windows remote printers
>  - S8221437:
> assert(java_lang_invoke_ResolvedMethodName::vmtarget(resolved_method())
> == m()) failed: Should not change after link resolution
>  - S8221470: Print methods in exception messages in java-like Syntax.
>  - S8221479: Fix JFR profiling on s390
>  - S8221483: TestOopCmp.java fails due to "Multiple garbage collectors
> selected"
>  - S8221535: add steal tick related information to hs_error file [linux]
>  - S8221610: Resurrect (legacy) JRE bundle target
>  - S8221639: [i386] expand_exec_shield_cs_limit workaround is undefined
> code after JDK-8199717
>  - S8221833: Readability check in Symbol::is_valid not performed for
> some addresses
>  - S8221870: use driver to run CtwRunner in applications/ctw tests
>  - S8221880: Better customization for Windows RC properties
> FileDescription and ProductName
>  - S8221915: cleanup ticks related coding in os_perf_aix.cpp [aix]
>  - S8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms
>  - S8221924: get(null) on single-entry unmodifiable Map returns null
> instead of throwing NPE
>  - S8222027: java/util/logging/LogManager/TestLoggerNames.java
> generates intermittent ClassCastException
>  - S8222032: x86_32 fails with "wrong size of mach node" on AVX-512 machine
>  - S8222089: [TESTBUG] sun/security/lib/cacerts/VerifyCACerts.java
> fails due to cert within 90-day expiry window
>  - S8222133: Add temporary exceptions for root certs that are due to
> expire soon
>  - S8222136: Remove two Comodo root CA certificates that are expiring
>  - S8222137: Remove T-Systems root CA certificate
>  - S8222397: x86_32 tests with UseSHA1Intrinsics SEGV due to garbled
> registers
>  - S8222410:
> java/nio/file/attribute/BasicFileAttributeView/UnixSocketFile hangs when
> "nc" does not accept "-U"
>  - S8222522: Add configure options for Mac Bundle creation
>  - S8222532: (zipfs) Performance regression when writing ZipFileSystem
> entries in parallel
>  - S8222913: Add Jib support for VERSION_EXTRA*
>  - S8222930: ConcurrentSkipListMap.clone() shares size variable between
> original and clone
>  - S8223266: PPC64: Check for branch to illegal address before checking
> for mem serialization
>  - S8223395: PPC64: Improve comments in the JVM signal handler to match
> ISA text
>  - S8223499: Remove two DocuSign root certificates that are expiring
>  - S8223555: Cleanups in cacerts tests
>  - S8223597: jdk/nio/zipfs/ZipFSTester.java RuntimeException:
> CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)
>  - S8223665: SA: debugd options should follow jhsdb style
>  - S8224474: harfbuzz 2.3.1 code fails to compile with gcc 4.4.7
>  - S8224671: AArch64: mauve System.arraycopy test failure
>  - S8224727: Problem list test
> security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java
>  - S8224828: aarch64: rflags is not correct after safepoint poll
>  - S8224880: AArch64: java/javac error with AllocatePrefetchDistance
>  - S8225402: events logging in deoptimization.cpp should go to deopt-log
>  - S8225716: G1 GC: Undefined behaviour in
> G1BlockOffsetTablePart::block_at_or_preceding
>  - S8226876: Assertion in sun/util/locale/provider/CalendarDataUtility
> on Windows after JDK-8218960
>  - S8226880: Backport of JDK-8208698 (Improved ECC Implementation)
> should not bring parts of JDK-8205476 (KeyAgreement#generateSecret is
> not reset for ECDH based algorithm)
> 
> -- 
> 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 neugens at redhat.com  Wed Jul 17 10:51:52 2019
From: neugens at redhat.com (Mario Torre)
Date: Wed, 17 Jul 2019 12:51:52 +0200
Subject: OpenJDK 11.0.4 Released
In-Reply-To: <3923E2C5-783E-4A32-96B5-3A8A81718531@sap.com>
References: <6dd29be1-6a6d-1d5b-771e-03cbc439ddde@redhat.com>
 <3923E2C5-783E-4A32-96B5-3A8A81718531@sap.com>
Message-ID: <b2b9a106-3a5d-1e69-1293-c9faec6136e8@redhat.com>

On 17/07/2019 12:26, Lindenmaier, Goetz wrote:
> Hi Andrew,
> 
> Thanks for porting the closed changes and 
> pushing them such timely again!
> Great job!

Yes, thanks!

Cheers,
Mario

> Best regards,
>   G?tz
> 
>> Am 17.07.2019 um 05:46 schrieb Andrew John Hughes <gnu.andrew at redhat.com>:
>>
>> We are pleased to announce the release of OpenJDK 11.0.4.
>>
>> The source tarball is available from:
>>
>> * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.tar.xz
>>
>> The tarball is accompanied by a digital signature available at:
>>
>> * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.tar.xz.sig
>>
>> This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):
>>
>> PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
>> Fingerprint = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F
>>
>> SHA256 checksums:
>>
>> d138f10168e4929ed992be99c2059b0ea46c648e1b0080ce1c44a526e498fc05
>> openjdk-11.0.4+11.tar.xz
>> afdd3f4c7cc9ad8e8e96a6929c51dfff83d41958bb004618e7bea43a1fd7d939
>> openjdk-11.0.4+11.tar.xz.sig
>>
>> The checksums can be downloaded from:
>>
>> * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.sha256
>>
>> What's New?
>> ===========
>> * Security fixes
>>  - S8208698, CVE-2019-2745: Improved ECC Implementation
>>  - S8212328, CVE-2019-2762: Exceptional throw cases
>>  - S8213431, CVE-2019-2766: Improve file protocol handling
>>  - S8213432, CVE-2019-2769: Better copies of CopiesList
>>  - S8216381, CVE-2019-2786: More limited privilege usage
>>  - S8217563: Improve realm maintenance
>>  - S8218863: Better endpoint checks
>>  - S8218873: Improve JSSE endpoint checking
>>  - S8218876, CVE-2019-7317: Improve PNG support options
>>  - S8219775: Certificate validation improvements
>>  - S8220517: Enhanced GIF support
>>  - S8221345, CVE-2019-2818: Better Poly1305 support
>>  - S8221518, CVE-2019-2816: Normalize normalization
>>  - S8222678, CVE-2019-2821: Improve TLS negotiation
>> * Other fixes
>>  - S6913047: Long term memory leak when using PKCS11 and JCE exceeds 32
>> bit process address space
>>  - S8139178: Wrong fontMetrics when printing in Landscape (OpenJDK)
>>  - S8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java
>> failed with timed out
>>  - S8170494: JNI exception pending in PlainDatagramSocketImpl.c
>>  - S8174691: [TESTBUG] A number of native hotspot unit tests fail when
>> executed in stand-alone mode
>>  - S8179098: Crypto AES/ECB encryption/decryption performance
>> regression (introduced in jdk9b73)
>>  - S8181143: Introduce diagnostic flag to abort VM on too long VM
>> operations
>>  - S8188133: C2: Static field accesses in clinit can trigger
>> deoptimizations
>>  - S8190361: Incorrect version info in jaccessinspector.exe and
>> jaccesswalker.exe
>>  - S8195793: Remove GTE CyberTrust Global Root
>>  - S8200286: (testbug) MOptionTest test fails with
>> java.lang.AssertionError: Classfiles too old!
>>  - S8200613: SA: jstack throws UnmappedAddressException with a CDS core
>> file
>>  - S8201317: X25519/X448 code improvements
>>  - S8201633: Problems with AES-GCM native acceleration
>>  - S8202353: os::readdir should use readdir instead of readdir_r
>>  - S8202414: Unsafe write after primitive array creation may result in
>> array length change
>>  - S8202651: Test ComodoCA.java fails
>>  - S8202794: Native Unix code should use readdir rather than readdir_r
>>  - S8202884: SA: Attach/detach might fail on Linux if debugee
>> application create/destroy threads during attaching
>>  - S8203627: Swing applications with JRadioButton and JCheckbox fail to
>> render correctly when using GTK3 and the GTK L&F
>>  - S8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails
>> when running in CDS mode
>>  - S8205574: Loop predication "assert(f <= 1 && f >= 0) failed
>> Incorrect frequency"
>>  - S8205611: Improve the wording of LinkageErrors to include module and
>> class loader information
>>  - S8206955: MethodHandleProxies.asInterfaceInstance does not support
>> default methods
>>  - S8207340: (fs) UnixNativeDispatcher close and readdir usages should
>> be fixed
>>  - S8207748: Fix for 8202794 breaks tier1 builds
>>  - S8207760: SAXException: Invalid UTF-16 surrogate detected: d83c ?
>>  - S8208634: Add x-IBM-1129 charset
>>  - S8208648: ECC Field Arithmetic Enhancements
>>  - S8208702:
>> javax/swing/reliability/HangDuringStaticInitialization.java may hang on
>> macos
>>  - S8208996: X11 icon window color handing bug
>>  - S8209055: c.s.t.javac.code.DeferredCompletionFailureHandler seems to
>> use WeakHashMap incorrectly
>>  - S8209414: AArch64: method handle invocation does not respect JVMTI
>> interp_only mode
>>  - S8209415: Fix JVMTI test failure HS202
>>  - S8209573: [TESTBUG] gc/epsilon/TestMemoryMXBeans should retry on failure
>>  - S8209914: javadoc search sometimes generates bad URIs
>>  - S8209951: Problematic sparc intrinsic:
>> com.sun.crypto.provider.CipherBlockChaining
>>  - S8210008: custom extension for make/SourceRevision.gmk
>>  - S8210197: javac can't tell during speculative attribution if a
>> diamond expression is creating an anonymous inner class or not
>>  - S8210283: Support git as an SCM alternative in the build
>>  - S8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code
>>  - S8210457: JVM crash in ResolvedMethodTable::add_method(Handle)
>>  - S8210483: AssertionError in DeferredAttr at setOverloadKind caused
>> by JDK-8203679
>>  - S8210519: build/releaseFile/CheckSource.java failed additional
>> sources found
>>  - S8210739: Calling JSpinner's setFont with null throws
>> NullPointerException
>>  - S8210782: Upgrade HarfBuzz to the latest 2.3.1
>>  - S8210803: Compilation failure in codeBlob.cpp for Windows 32-bit
>>  - S8210837: Add libXrandr-devel to the Linux devkits
>>  - S8210863: Remove Xrandr include files from JDK sources
>>  - S8210880: Remove HPKeysym.h from JDK sources
>>  - S8210886: Remove references in xwindows.md to non-existent files.
>>  - S8210899: (zipfs) ZipFileSystem.EntryOutputStreamCRC32 mistakenly
>> set the crc32 value into size field
>>  - S8211266: [TESTBUG] ZipFSTester.java failed intermittently in
>> ZipFSTester.checkRead(): bound must be positive
>>  - S8211350: Remove jprt support
>>  - S8211393: Memory leak issue on awt_InputMethod.c
>>  - S8211435: Exception in thread "AWT-EventQueue-1"
>> java.lang.IllegalArgumentException: null source
>>  - S8211698: Crash in C2 compiled code during execution of double array
>> heavy processing code
>>  - S8211810: X11 Time stamp data should be unsigned
>>  - S8211826: StringIndexOutOfBoundsException happens via
>> GetStringUTFRegion()
>>  - S8211841: [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix)
>>  - S8211969: test/jdk/lib/security/CheckBlacklistedCerts.java searching
>> for wrong paths
>>  - S8211971: Move security/cacerts/VerifyCACerts.java and
>> security/CheckBlacklistedCerts.java
>>  - S8212202: [Windows] Exception if no printers are installed.
>>  - S8212205: VM asserts after CDS archive has been unmapped
>>  - S8212562: To remove lib/security from test/jdk/TEST.groups
>>  - S8212676: AWT SystemColor setting on CDE
>>  - S8212677: X11 default visual support for IM status window on VNC
>>  - S8212678: Windows IME related patch
>>  - S8212794: IBM-964 is required for AIX default charset
>>  - S8212828: (process) Provide a way for Runtime.exec to use
>> posix_spawn on linux
>>  - S8213015: Inconsistent settings between JFR.configure and
>> -XX:FlightRecorderOptions
>>  - S8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h
>>  - S8213232: Unix/X11 setCompositionEnableNative issue
>>  - S8213292: Input freezes after MacOS key-selector (press&hold) usage
>> on macOS Mojave
>>  - S8213294: Upgrade IANA LSR data
>>  - S8213515: Improve freetype detection on linux/ppc64/ppc64le/s390x
>>  - S8213614: DnD operation change feature does not work with 64bit big
>> endian CPU
>>  - S8213617: JFR should record the PID of the recorded process
>>  - S8213618: IBM970 charset has missing entry and remove unexpected entries
>>  - S8213825: assert(false) failed: Non-balanced monitor enter/exit!
>> Likely JNI locking
>>  - S8213944: Fix AIX build after the removal of Xrandr.h and add a
>> configure check for it
>>  - S8214002: Cannot use italic font style if the font has embedded bitmap
>>  - S8214109: XToolkit is not correctly displayed color on 16-bit high
>> color setting
>>  - S8214111: There is no icon in all JOptionPane target image
>>  - S8214112: The whole text in target JPasswordField image are not selected
>>  - S8214252: Expanded & Collapsed nodes of a JTree look the same on GTK3
>>  - S8214253: Tooltip is transparent rather than having a black background
>>  - S8214468: jQuery UI upgrade from 1.11.4 to 1.12.1
>>  - S8214533: IBM-29626C is required for AIX default charset
>>  - S8214765: All TrayIcon MessageType icons does not show up with gtk3
>> option set
>>  - S8214935: Upgrade IANA LSR data
>>  - S8215026: Incorrect amount of memory unmapped with
>> ImageFileReader::close()
>>  - S8215123: Crash in runtime image built with jlink --compress=2
>>  - S8215284: Reduce noise induced by periodic task getFileSize()
>>  - S8215296: do not disable c99 on Solaris
>>  - S8215342: [Zero] Build fails after JDK-8200613
>>  - S8215364: JavaFX crashes on Ubuntu 18.04 with Wayland while using
>> Swing-FX interop
>>  - S8215374: 32-bit build failures after JDK-8181143 (Introduce
>> diagnostic flag to abort VM on too long VM operations)
>>  - S8215398: -Xlog option usage => Invalid decorator '\temp\app_cds.log'.
>>  - S8215443: The use of TransportContext.fatal() leads to bad coding style
>>  - S8215472: (zipfs) Cleanups in implementation classes of jdk.zipfs
>> and tests
>>  - S8215707: [macosx] fix pthread_getschedparam and
>> pthread_setschedparam calls
>>  - S8215757: C2: PhaseIdealLoop::create_new_if_for_predicate() computes
>> wrong IDOM
>>  - S8215790: Delegated task created by SSLEngine throws
>> java.nio.BufferUnderflowException
>>  - S8216045: The size of key_exchange may be wrong on FFDHE
>>  - S8216355: missing NULL checks in libnet in interface iteration and
>> potential resource leak in getMacAddress
>>  - S8216556: Unnecessary liveness computation with JVMTI
>>  - S8216577: Add GlobalSign's R6 Root certificate
>>  - S8216597: SIGBUS in
>> Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047
>>  - S8216970: condy causes JVM crash
>>  - S8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after
>> JDK-8216597 (SIGBUS error in getNativeKeyInfo)
>>  - S8217094: HttpClient SSL race if a socket IOException is raised
>> before ALPN is available
>>  - S8217263: Automate DashOffset test
>>  - S8217311: Improve Exception thrown when MulticastSocket.setInterface
>> fails on AIX(Unix)
>>  - S8217564: idempotent protection missing in crc32c.h
>>  - S8217647: JFR: recordings on 32-bit systems unreadable
>>  - S8217690: Update public suffix version
>>  - S8217707: JNICALL declaration breaks Splash screen functions
>>  - S8217765: Internal Error (javaCalls.cpp:61)
>> guarantee(thread->can_call_java()) failed
>>  - S8217786: Provide virtualization related info in the hs_error file
>> on linux s390x
>>  - S8217878: ENVELOPING XML signature no longer works in JDK 11
>>  - S8217879: hs_err should print more instructions in hex dump
>>  - S8217880: AIX build issue after JDK-8214533
>>  - S8218020: Fix version number in mesa.md 3rd party legal file
>>  - S8218060: JDK-8217786 breaks build due to remaining unused function
>>  - S8218063: JDK-8218060 breaks build for S390
>>  - S8218152: [javac] fails and exits with no error if a bad annotation
>> processor provided
>>  - S8218469: JSlider display issue with slider for GTKLookAndFeel
>>  - S8218470: JScrollBar display issue with GTKLookAndFeel
>>  - S8218472: JProgressBar display issue with GTKLookAndFeel
>>  - S8218473: JOptionPane display issue with GTKLookAndFeel
>>  - S8218479: JTextPane display issue with GTKLookAndFeel
>>  - S8218618: Program fails when using JDK addressed by UNC path and
>> using Security Manager
>>  - S8218629: XML Digital Signature throws NAMESPACE_ERR exception on
>> OpenJDK 11, works 8/9/10
>>  - S8218674: HTML Tooltip with "img=src" on component doesn't show
>>  - S8218733: SA: CollectedHeap provides broken implementation for
>> used() and capacity()
>>  - S8218781: Localized names for Japanese era Reiwa in COMPAT provider
>>  - S8218811: replace open by os::open in hotspot coding
>>  - S8218854: FontMetrics.getMaxAdvance may be less than the maximum
>> FontMetrics.charWidth
>>  - S8218960: CONFIG level logging statements printed in
>> CLDRCalendarDataProviderImpl.java even when default log Level is INFO
>>  - S8218991: s390: Add intrinsic for GHASH algorithm
>>  - S8219006: AArch64: Register corruption in slow subtype check
>>  - S8219011: Implement MacroAssembler::warn method on AArch64
>>  - S8219112: name_and_sig_as_C_string usages in frame_s390 miss
>> ResourceMark
>>  - S8219335: "failed: unexpected type" assert failure in
>> ConnectionGraph::split_unique_types() with unsafe accesses
>>  - S8219389: Delegated task created by SSLEngine throws
>> BufferUnderflowException
>>  - S8219414: SA: jhsdb jsnap throws UnmappedAddressException with core
>> generated by gcore
>>  - S8219448: split-if update_uses accesses stale idom data
>>  - S8219460: ppc: adjust NativeGeneralJump::insert_unconditional to
>> stack allocated MacroAssembler
>>  - S8219566: JFR did not collect call stacks when
>> MaxJavaStackTraceDepth is set to zero
>>  - S8219574: Minimal VM build failure after JDK-8219414
>>  - S8219582: PPC: Crash after C1 checkcast patched and GC
>>  - S8219584: Try to dump error file by thread which causes safepoint
>> timeout
>>  - S8219698: aarch64: SIGILL triggered when specifying unsupported
>> hardware features
>>  - S8219710: Bump update version for OpenJDK: jdk11.0.4
>>  - S8219746: Provide virtualization related info in the hs_error file
>> on linux ppc64 / ppc64le
>>
>>  - S8219915: [TESTBUG] Fix test
>> langtools/tools/javac/processing/model/completionfailure/SymbolsDontCumulate.java
>> in Standalone mode
>>  - S8219918: ProblemList hotspot tests failing in SAP testing.
>>  - S8220165: Encryption using GCM results in RuntimeException- input
>> length out of bound
>>  - S8220166: Performance regression in deserialization (4-6% in SPECjbb)
>>  - S8220198: Lots of com/sun/crypto/provider/Cipher tests fail on
>> x86_32 due to missing SHA512 stubs
>>  - S8220281: IBM-858 alias name is missing on IBM00858 charset
>>  - S8220293: Deadlock in JFR string pool
>>  - S8220349: The fix done for JDK-8214253 have caused issues in JTree
>> behaviour
>>  - S8220353: [TESTBUG] TestRegisterRestoring uses SafepointALot without
>> UnlockDiagnosticVMOptions
>>  - S8220374: C2: LoopStripMining doesn't strip as expected
>>  - S8220441: [PPC64] Clobber memory effect missing for memory barriers
>> in atomics
>>  - S8220495: Update GIFlib library to the 5.1.8
>>  - S8220513: Wrapper Key may get deleted when closing sessions in
>> SunPKCS11 crypto provider
>>  - S8220625: tools/javac/classreader/8171132/BadConstantValue.java
>> failed with "did not see expected error"
>>  - S8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java
>> fails with jtreg -vmoption:-Xmx < 8g
>>  - S8220714: C2 Compilation failure when accessing off-heap memory
>> using Unsafe
>>  - S8220718: Missing ResourceMark in nmethod::metadata_do
>>  - S8220781: linux-s390 : os::get_summary_cpu_info gives bad output
>>  - S8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal
>> address
>>  - S8221083: [ppc64] Wrong oop compare in C1-generated code
>>  - S8221175: Fix bad function case for controlled JVM crash on PPC64
>> big-endian
>>  - S8221244: Unexpected behavior of PropertyDescription.getReadMethod
>> for boolean properties
>>  - S8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use
>>  - S8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java
>>  - S8221400: java/lang/String/StringRepeat.java test requests too much heap
>>  - S8221401: java/math/BigInteger/LargeValueExceptions.java test should
>> be disabled on 32-bit platforms
>>  - S8221412: lookupPrintServices() does not always update the list of
>> Windows remote printers
>>  - S8221437:
>> assert(java_lang_invoke_ResolvedMethodName::vmtarget(resolved_method())
>> == m()) failed: Should not change after link resolution
>>  - S8221470: Print methods in exception messages in java-like Syntax.
>>  - S8221479: Fix JFR profiling on s390
>>  - S8221483: TestOopCmp.java fails due to "Multiple garbage collectors
>> selected"
>>  - S8221535: add steal tick related information to hs_error file [linux]
>>  - S8221610: Resurrect (legacy) JRE bundle target
>>  - S8221639: [i386] expand_exec_shield_cs_limit workaround is undefined
>> code after JDK-8199717
>>  - S8221833: Readability check in Symbol::is_valid not performed for
>> some addresses
>>  - S8221870: use driver to run CtwRunner in applications/ctw tests
>>  - S8221880: Better customization for Windows RC properties
>> FileDescription and ProductName
>>  - S8221915: cleanup ticks related coding in os_perf_aix.cpp [aix]
>>  - S8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms
>>  - S8221924: get(null) on single-entry unmodifiable Map returns null
>> instead of throwing NPE
>>  - S8222027: java/util/logging/LogManager/TestLoggerNames.java
>> generates intermittent ClassCastException
>>  - S8222032: x86_32 fails with "wrong size of mach node" on AVX-512 machine
>>  - S8222089: [TESTBUG] sun/security/lib/cacerts/VerifyCACerts.java
>> fails due to cert within 90-day expiry window
>>  - S8222133: Add temporary exceptions for root certs that are due to
>> expire soon
>>  - S8222136: Remove two Comodo root CA certificates that are expiring
>>  - S8222137: Remove T-Systems root CA certificate
>>  - S8222397: x86_32 tests with UseSHA1Intrinsics SEGV due to garbled
>> registers
>>  - S8222410:
>> java/nio/file/attribute/BasicFileAttributeView/UnixSocketFile hangs when
>> "nc" does not accept "-U"
>>  - S8222522: Add configure options for Mac Bundle creation
>>  - S8222532: (zipfs) Performance regression when writing ZipFileSystem
>> entries in parallel
>>  - S8222913: Add Jib support for VERSION_EXTRA*
>>  - S8222930: ConcurrentSkipListMap.clone() shares size variable between
>> original and clone
>>  - S8223266: PPC64: Check for branch to illegal address before checking
>> for mem serialization
>>  - S8223395: PPC64: Improve comments in the JVM signal handler to match
>> ISA text
>>  - S8223499: Remove two DocuSign root certificates that are expiring
>>  - S8223555: Cleanups in cacerts tests
>>  - S8223597: jdk/nio/zipfs/ZipFSTester.java RuntimeException:
>> CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)
>>  - S8223665: SA: debugd options should follow jhsdb style
>>  - S8224474: harfbuzz 2.3.1 code fails to compile with gcc 4.4.7
>>  - S8224671: AArch64: mauve System.arraycopy test failure
>>  - S8224727: Problem list test
>> security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java
>>  - S8224828: aarch64: rflags is not correct after safepoint poll
>>  - S8224880: AArch64: java/javac error with AllocatePrefetchDistance
>>  - S8225402: events logging in deoptimization.cpp should go to deopt-log
>>  - S8225716: G1 GC: Undefined behaviour in
>> G1BlockOffsetTablePart::block_at_or_preceding
>>  - S8226876: Assertion in sun/util/locale/provider/CalendarDataUtility
>> on Windows after JDK-8218960
>>  - S8226880: Backport of JDK-8208698 (Improved ECC Implementation)
>> should not bring parts of JDK-8205476 (KeyAgreement#generateSecret is
>> not reset for ECDH based algorithm)
>>
>> -- 
>> 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
>>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From rob.mckenna at oracle.com  Wed Jul 17 12:03:01 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 17 Jul 2019 13:03:01 +0100
Subject: 12.0.2-ga and 13.0.0-ga tags?
In-Reply-To: <CAP7YuAR6nA8Lk3iamCOGWGtc438Dac6+mLG++Dun98ZVSVS=Cg@mail.gmail.com>
References: <CAP7YuARctZMQCrC0E05E=d6aAajVAxMcfZOTV5bygwQyynMYwQ@mail.gmail.com>
 <37ff7003-aaec-ddc0-0053-869dc23057a4@redhat.com>
 <84b23d87-842d-2bba-fb15-3defe0ced93a@redhat.com>
 <CAP7YuAR6nA8Lk3iamCOGWGtc438Dac6+mLG++Dun98ZVSVS=Cg@mail.gmail.com>
Message-ID: <20190717120301.GB5990@vimes>

Hi folks,

My sincerest apologies for the delay. There was a last minute issue with
the repo and I needed a double and triple check before I felt
comfortable pushing.

Coffee consumed, fixes pushed.

    -Rob

On 17/07/19 10:23, Martijn Verburg wrote:
> Thanks, Aleksey - I figured I'd gotten my dates wrong!
> 
> Cheers,
> Martijn
> 
> 
> On Wed, 17 Jul 2019 at 09:15, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> > On 7/17/19 10:04 AM, Aleksey Shipilev wrote:
> > > On 7/17/19 9:56 AM, Martijn Verburg wrote:
> > >> I suspect I'm being really dense but were there 12.0.2-ga and 13.0.0-ga
> > >> tags due to be pushed yesterday or today?
> > >
> > > 13 is due to release in September, you cannot expect GA at this time.
> > >
> > > 12 repo does not even have the security patches pushed in, AFAICS. I
> > believe the tag would follow in
> > > the same push. I'd wait for Rob to push those,
> >
> > ...after Robs wakes up and has his morning coffee. (Sent the note too
> > early. Clearly, I should have
> > had my own coffee first).
> >
> > --
> > Thanks,
> > -Aleksey
> >
> >

From rob.mckenna at oracle.com  Wed Jul 17 12:04:55 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 17 Jul 2019 13:04:55 +0100
Subject: [Updates Communication] jdk12.0.2 security patches pushed
Message-ID: <20190717120455.GC5990@vimes>

Hi folks,

Security fixes for 12.0.2 pushed to:

https://hg.openjdk.java.net/jdk-updates/jdk12u

Thanks,

    -Rob


From doko at ubuntu.com  Wed Jul 17 13:51:39 2019
From: doko at ubuntu.com (Matthias Klose)
Date: Wed, 17 Jul 2019 15:51:39 +0200
Subject: 12.0.2-ga and 13.0.0-ga tags?
In-Reply-To: <20190717120301.GB5990@vimes>
References: <CAP7YuARctZMQCrC0E05E=d6aAajVAxMcfZOTV5bygwQyynMYwQ@mail.gmail.com>
 <37ff7003-aaec-ddc0-0053-869dc23057a4@redhat.com>
 <84b23d87-842d-2bba-fb15-3defe0ced93a@redhat.com>
 <CAP7YuAR6nA8Lk3iamCOGWGtc438Dac6+mLG++Dun98ZVSVS=Cg@mail.gmail.com>
 <20190717120301.GB5990@vimes>
Message-ID: <952229ae-c5f9-196e-52a3-f41cdba3773d@ubuntu.com>

On 17.07.19 14:03, Rob McKenna wrote:
> Hi folks,
> 
> My sincerest apologies for the delay. There was a last minute issue with
> the repo and I needed a double and triple check before I felt
> comfortable pushing.

The jdk-12.0.2-ga and jdk-12.0.2+9 tags now reference different commits.  Is
this expected?

Matthias

From sgehwolf at redhat.com  Wed Jul 17 14:04:56 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 17 Jul 2019 16:04:56 +0200
Subject: 12.0.2-ga and 13.0.0-ga tags?
In-Reply-To: <952229ae-c5f9-196e-52a3-f41cdba3773d@ubuntu.com>
References: <CAP7YuARctZMQCrC0E05E=d6aAajVAxMcfZOTV5bygwQyynMYwQ@mail.gmail.com>
 <37ff7003-aaec-ddc0-0053-869dc23057a4@redhat.com>
 <84b23d87-842d-2bba-fb15-3defe0ced93a@redhat.com>
 <CAP7YuAR6nA8Lk3iamCOGWGtc438Dac6+mLG++Dun98ZVSVS=Cg@mail.gmail.com>
 <20190717120301.GB5990@vimes>
 <952229ae-c5f9-196e-52a3-f41cdba3773d@ubuntu.com>
Message-ID: <7d3a54f486ad2972c95a9bfcccaa783866b48d2f.camel@redhat.com>

On Wed, 2019-07-17 at 15:51 +0200, Matthias Klose wrote:
> On 17.07.19 14:03, Rob McKenna wrote:
> > Hi folks,
> > 
> > My sincerest apologies for the delay. There was a last minute issue with
> > the repo and I needed a double and triple check before I felt
> > comfortable pushing.
> 
> The jdk-12.0.2-ga and jdk-12.0.2+9 tags now reference different commits.  Is
> this expected?

As far as I can see it's jdk-12.0.2-ga -> jdk-12.0.2+9 -> ffb3065f13fe.
So it's essentially the same code. What's the concern exactly?

Thanks,
Severin


From doko at ubuntu.com  Wed Jul 17 14:14:14 2019
From: doko at ubuntu.com (Matthias Klose)
Date: Wed, 17 Jul 2019 16:14:14 +0200
Subject: 12.0.2-ga and 13.0.0-ga tags?
In-Reply-To: <7d3a54f486ad2972c95a9bfcccaa783866b48d2f.camel@redhat.com>
References: <CAP7YuARctZMQCrC0E05E=d6aAajVAxMcfZOTV5bygwQyynMYwQ@mail.gmail.com>
 <37ff7003-aaec-ddc0-0053-869dc23057a4@redhat.com>
 <84b23d87-842d-2bba-fb15-3defe0ced93a@redhat.com>
 <CAP7YuAR6nA8Lk3iamCOGWGtc438Dac6+mLG++Dun98ZVSVS=Cg@mail.gmail.com>
 <20190717120301.GB5990@vimes>
 <952229ae-c5f9-196e-52a3-f41cdba3773d@ubuntu.com>
 <7d3a54f486ad2972c95a9bfcccaa783866b48d2f.camel@redhat.com>
Message-ID: <9b7e2eb8-e4ec-4997-0cc9-732a4033acbf@ubuntu.com>

On 17.07.19 16:04, Severin Gehwolf wrote:
> On Wed, 2019-07-17 at 15:51 +0200, Matthias Klose wrote:
>> On 17.07.19 14:03, Rob McKenna wrote:
>>> Hi folks,
>>>
>>> My sincerest apologies for the delay. There was a last minute issue with
>>> the repo and I needed a double and triple check before I felt
>>> comfortable pushing.
>>
>> The jdk-12.0.2-ga and jdk-12.0.2+9 tags now reference different commits.  Is
>> this expected?
> 
> As far as I can see it's jdk-12.0.2-ga -> jdk-12.0.2+9 -> ffb3065f13fe.
> So it's essentially the same code. What's the concern exactly?

well, there have been some rants about "mystery meat builds" in the past, so I'm
asking here. but from looking at http://hg.openjdk.java.net/jdk-updates/jdk12u/
it's not directly obvious.

But from looking at
http://hg.openjdk.java.net/jdk-updates/jdk12u/graph/e8a37f17cf51 I see see there
is no difference.

Matthias

From sgehwolf at redhat.com  Wed Jul 17 14:16:35 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 17 Jul 2019 16:16:35 +0200
Subject: OpenJDK 11.0.4 Released
In-Reply-To: <6dd29be1-6a6d-1d5b-771e-03cbc439ddde@redhat.com>
References: <6dd29be1-6a6d-1d5b-771e-03cbc439ddde@redhat.com>
Message-ID: <f41f87f63d3187ebec899792ddb76a6102056cd3.camel@redhat.com>

Hi,

The July update of the OpenJDK 11 updates project builds (11.0.4+11) are here:
https://adoptopenjdk.net/upstream.html

Thanks,
Severin


On Wed, 2019-07-17 at 04:44 +0100, Andrew John Hughes wrote:
> We are pleased to announce the release of OpenJDK 11.0.4.
> 
> The source tarball is available from:
> 
> * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.tar.xz
> 
> The tarball is accompanied by a digital signature available at:
> 
> * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.tar.xz.sig
> 
> This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):
> 
> PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
> Fingerprint = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F
> 
> SHA256 checksums:
> 
> d138f10168e4929ed992be99c2059b0ea46c648e1b0080ce1c44a526e498fc05
> openjdk-11.0.4+11.tar.xz
> afdd3f4c7cc9ad8e8e96a6929c51dfff83d41958bb004618e7bea43a1fd7d939
> openjdk-11.0.4+11.tar.xz.sig
> 
> The checksums can be downloaded from:
> 
> * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.4+11.sha256
> 
> What's New?
> ===========
> * Security fixes
>   - S8208698, CVE-2019-2745: Improved ECC Implementation
>   - S8212328, CVE-2019-2762: Exceptional throw cases
>   - S8213431, CVE-2019-2766: Improve file protocol handling
>   - S8213432, CVE-2019-2769: Better copies of CopiesList
>   - S8216381, CVE-2019-2786: More limited privilege usage
>   - S8217563: Improve realm maintenance
>   - S8218863: Better endpoint checks
>   - S8218873: Improve JSSE endpoint checking
>   - S8218876, CVE-2019-7317: Improve PNG support options
>   - S8219775: Certificate validation improvements
>   - S8220517: Enhanced GIF support
>   - S8221345, CVE-2019-2818: Better Poly1305 support
>   - S8221518, CVE-2019-2816: Normalize normalization
>   - S8222678, CVE-2019-2821: Improve TLS negotiation
> * Other fixes
>   - S6913047: Long term memory leak when using PKCS11 and JCE exceeds 32
> bit process address space
>   - S8139178: Wrong fontMetrics when printing in Landscape (OpenJDK)
>   - S8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java
> failed with timed out
>   - S8170494: JNI exception pending in PlainDatagramSocketImpl.c
>   - S8174691: [TESTBUG] A number of native hotspot unit tests fail when
> executed in stand-alone mode
>   - S8179098: Crypto AES/ECB encryption/decryption performance
> regression (introduced in jdk9b73)
>   - S8181143: Introduce diagnostic flag to abort VM on too long VM
> operations
>   - S8188133: C2: Static field accesses in clinit can trigger
> deoptimizations
>   - S8190361: Incorrect version info in jaccessinspector.exe and
> jaccesswalker.exe
>   - S8195793: Remove GTE CyberTrust Global Root
>   - S8200286: (testbug) MOptionTest test fails with
> java.lang.AssertionError: Classfiles too old!
>   - S8200613: SA: jstack throws UnmappedAddressException with a CDS core
> file
>   - S8201317: X25519/X448 code improvements
>   - S8201633: Problems with AES-GCM native acceleration
>   - S8202353: os::readdir should use readdir instead of readdir_r
>   - S8202414: Unsafe write after primitive array creation may result in
> array length change
>   - S8202651: Test ComodoCA.java fails
>   - S8202794: Native Unix code should use readdir rather than readdir_r
>   - S8202884: SA: Attach/detach might fail on Linux if debugee
> application create/destroy threads during attaching
>   - S8203627: Swing applications with JRadioButton and JCheckbox fail to
> render correctly when using GTK3 and the GTK L&F
>   - S8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails
> when running in CDS mode
>   - S8205574: Loop predication "assert(f <= 1 && f >= 0) failed
> Incorrect frequency"
>   - S8205611: Improve the wording of LinkageErrors to include module and
> class loader information
>   - S8206955: MethodHandleProxies.asInterfaceInstance does not support
> default methods
>   - S8207340: (fs) UnixNativeDispatcher close and readdir usages should
> be fixed
>   - S8207748: Fix for 8202794 breaks tier1 builds
>   - S8207760: SAXException: Invalid UTF-16 surrogate detected: d83c ?
>   - S8208634: Add x-IBM-1129 charset
>   - S8208648: ECC Field Arithmetic Enhancements
>   - S8208702:
> javax/swing/reliability/HangDuringStaticInitialization.java may hang on
> macos
>   - S8208996: X11 icon window color handing bug
>   - S8209055: c.s.t.javac.code.DeferredCompletionFailureHandler seems to
> use WeakHashMap incorrectly
>   - S8209414: AArch64: method handle invocation does not respect JVMTI
> interp_only mode
>   - S8209415: Fix JVMTI test failure HS202
>   - S8209573: [TESTBUG] gc/epsilon/TestMemoryMXBeans should retry on failure
>   - S8209914: javadoc search sometimes generates bad URIs
>   - S8209951: Problematic sparc intrinsic:
> com.sun.crypto.provider.CipherBlockChaining
>   - S8210008: custom extension for make/SourceRevision.gmk
>   - S8210197: javac can't tell during speculative attribution if a
> diamond expression is creating an anonymous inner class or not
>   - S8210283: Support git as an SCM alternative in the build
>   - S8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code
>   - S8210457: JVM crash in ResolvedMethodTable::add_method(Handle)
>   - S8210483: AssertionError in DeferredAttr at setOverloadKind caused
> by JDK-8203679
>   - S8210519: build/releaseFile/CheckSource.java failed additional
> sources found
>   - S8210739: Calling JSpinner's setFont with null throws
> NullPointerException
>   - S8210782: Upgrade HarfBuzz to the latest 2.3.1
>   - S8210803: Compilation failure in codeBlob.cpp for Windows 32-bit
>   - S8210837: Add libXrandr-devel to the Linux devkits
>   - S8210863: Remove Xrandr include files from JDK sources
>   - S8210880: Remove HPKeysym.h from JDK sources
>   - S8210886: Remove references in xwindows.md to non-existent files.
>   - S8210899: (zipfs) ZipFileSystem.EntryOutputStreamCRC32 mistakenly
> set the crc32 value into size field
>   - S8211266: [TESTBUG] ZipFSTester.java failed intermittently in
> ZipFSTester.checkRead(): bound must be positive
>   - S8211350: Remove jprt support
>   - S8211393: Memory leak issue on awt_InputMethod.c
>   - S8211435: Exception in thread "AWT-EventQueue-1"
> java.lang.IllegalArgumentException: null source
>   - S8211698: Crash in C2 compiled code during execution of double array
> heavy processing code
>   - S8211810: X11 Time stamp data should be unsigned
>   - S8211826: StringIndexOutOfBoundsException happens via
> GetStringUTFRegion()
>   - S8211841: [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix)
>   - S8211969: test/jdk/lib/security/CheckBlacklistedCerts.java searching
> for wrong paths
>   - S8211971: Move security/cacerts/VerifyCACerts.java and
> security/CheckBlacklistedCerts.java
>   - S8212202: [Windows] Exception if no printers are installed.
>   - S8212205: VM asserts after CDS archive has been unmapped
>   - S8212562: To remove lib/security from test/jdk/TEST.groups
>   - S8212676: AWT SystemColor setting on CDE
>   - S8212677: X11 default visual support for IM status window on VNC
>   - S8212678: Windows IME related patch
>   - S8212794: IBM-964 is required for AIX default charset
>   - S8212828: (process) Provide a way for Runtime.exec to use
> posix_spawn on linux
>   - S8213015: Inconsistent settings between JFR.configure and
> -XX:FlightRecorderOptions
>   - S8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h
>   - S8213232: Unix/X11 setCompositionEnableNative issue
>   - S8213292: Input freezes after MacOS key-selector (press&hold) usage
> on macOS Mojave
>   - S8213294: Upgrade IANA LSR data
>   - S8213515: Improve freetype detection on linux/ppc64/ppc64le/s390x
>   - S8213614: DnD operation change feature does not work with 64bit big
> endian CPU
>   - S8213617: JFR should record the PID of the recorded process
>   - S8213618: IBM970 charset has missing entry and remove unexpected entries
>   - S8213825: assert(false) failed: Non-balanced monitor enter/exit!
> Likely JNI locking
>   - S8213944: Fix AIX build after the removal of Xrandr.h and add a
> configure check for it
>   - S8214002: Cannot use italic font style if the font has embedded bitmap
>   - S8214109: XToolkit is not correctly displayed color on 16-bit high
> color setting
>   - S8214111: There is no icon in all JOptionPane target image
>   - S8214112: The whole text in target JPasswordField image are not selected
>   - S8214252: Expanded & Collapsed nodes of a JTree look the same on GTK3
>   - S8214253: Tooltip is transparent rather than having a black background
>   - S8214468: jQuery UI upgrade from 1.11.4 to 1.12.1
>   - S8214533: IBM-29626C is required for AIX default charset
>   - S8214765: All TrayIcon MessageType icons does not show up with gtk3
> option set
>   - S8214935: Upgrade IANA LSR data
>   - S8215026: Incorrect amount of memory unmapped with
> ImageFileReader::close()
>   - S8215123: Crash in runtime image built with jlink --compress=2
>   - S8215284: Reduce noise induced by periodic task getFileSize()
>   - S8215296: do not disable c99 on Solaris
>   - S8215342: [Zero] Build fails after JDK-8200613
>   - S8215364: JavaFX crashes on Ubuntu 18.04 with Wayland while using
> Swing-FX interop
>   - S8215374: 32-bit build failures after JDK-8181143 (Introduce
> diagnostic flag to abort VM on too long VM operations)
>   - S8215398: -Xlog option usage => Invalid decorator '\temp\app_cds.log'.
>   - S8215443: The use of TransportContext.fatal() leads to bad coding style
>   - S8215472: (zipfs) Cleanups in implementation classes of jdk.zipfs
> and tests
>   - S8215707: [macosx] fix pthread_getschedparam and
> pthread_setschedparam calls
>   - S8215757: C2: PhaseIdealLoop::create_new_if_for_predicate() computes
> wrong IDOM
>   - S8215790: Delegated task created by SSLEngine throws
> java.nio.BufferUnderflowException
>   - S8216045: The size of key_exchange may be wrong on FFDHE
>   - S8216355: missing NULL checks in libnet in interface iteration and
> potential resource leak in getMacAddress
>   - S8216556: Unnecessary liveness computation with JVMTI
>   - S8216577: Add GlobalSign's R6 Root certificate
>   - S8216597: SIGBUS in
> Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047
>   - S8216970: condy causes JVM crash
>   - S8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after
> JDK-8216597 (SIGBUS error in getNativeKeyInfo)
>   - S8217094: HttpClient SSL race if a socket IOException is raised
> before ALPN is available
>   - S8217263: Automate DashOffset test
>   - S8217311: Improve Exception thrown when MulticastSocket.setInterface
> fails on AIX(Unix)
>   - S8217564: idempotent protection missing in crc32c.h
>   - S8217647: JFR: recordings on 32-bit systems unreadable
>   - S8217690: Update public suffix version
>   - S8217707: JNICALL declaration breaks Splash screen functions
>   - S8217765: Internal Error (javaCalls.cpp:61)
> guarantee(thread->can_call_java()) failed
>   - S8217786: Provide virtualization related info in the hs_error file
> on linux s390x
>   - S8217878: ENVELOPING XML signature no longer works in JDK 11
>   - S8217879: hs_err should print more instructions in hex dump
>   - S8217880: AIX build issue after JDK-8214533
>   - S8218020: Fix version number in mesa.md 3rd party legal file
>   - S8218060: JDK-8217786 breaks build due to remaining unused function
>   - S8218063: JDK-8218060 breaks build for S390
>   - S8218152: [javac] fails and exits with no error if a bad annotation
> processor provided
>   - S8218469: JSlider display issue with slider for GTKLookAndFeel
>   - S8218470: JScrollBar display issue with GTKLookAndFeel
>   - S8218472: JProgressBar display issue with GTKLookAndFeel
>   - S8218473: JOptionPane display issue with GTKLookAndFeel
>   - S8218479: JTextPane display issue with GTKLookAndFeel
>   - S8218618: Program fails when using JDK addressed by UNC path and
> using Security Manager
>   - S8218629: XML Digital Signature throws NAMESPACE_ERR exception on
> OpenJDK 11, works 8/9/10
>   - S8218674: HTML Tooltip with "img=src" on component doesn't show
>   - S8218733: SA: CollectedHeap provides broken implementation for
> used() and capacity()
>   - S8218781: Localized names for Japanese era Reiwa in COMPAT provider
>   - S8218811: replace open by os::open in hotspot coding
>   - S8218854: FontMetrics.getMaxAdvance may be less than the maximum
> FontMetrics.charWidth
>   - S8218960: CONFIG level logging statements printed in
> CLDRCalendarDataProviderImpl.java even when default log Level is INFO
>   - S8218991: s390: Add intrinsic for GHASH algorithm
>   - S8219006: AArch64: Register corruption in slow subtype check
>   - S8219011: Implement MacroAssembler::warn method on AArch64
>   - S8219112: name_and_sig_as_C_string usages in frame_s390 miss
> ResourceMark
>   - S8219335: "failed: unexpected type" assert failure in
> ConnectionGraph::split_unique_types() with unsafe accesses
>   - S8219389: Delegated task created by SSLEngine throws
> BufferUnderflowException
>   - S8219414: SA: jhsdb jsnap throws UnmappedAddressException with core
> generated by gcore
>   - S8219448: split-if update_uses accesses stale idom data
>   - S8219460: ppc: adjust NativeGeneralJump::insert_unconditional to
> stack allocated MacroAssembler
>   - S8219566: JFR did not collect call stacks when
> MaxJavaStackTraceDepth is set to zero
>   - S8219574: Minimal VM build failure after JDK-8219414
>   - S8219582: PPC: Crash after C1 checkcast patched and GC
>   - S8219584: Try to dump error file by thread which causes safepoint
> timeout
>   - S8219698: aarch64: SIGILL triggered when specifying unsupported
> hardware features
>   - S8219710: Bump update version for OpenJDK: jdk11.0.4
>   - S8219746: Provide virtualization related info in the hs_error file
> on linux ppc64 / ppc64le
> 
>   - S8219915: [TESTBUG] Fix test
> langtools/tools/javac/processing/model/completionfailure/SymbolsDontCumulate.java
> in Standalone mode
>   - S8219918: ProblemList hotspot tests failing in SAP testing.
>   - S8220165: Encryption using GCM results in RuntimeException- input
> length out of bound
>   - S8220166: Performance regression in deserialization (4-6% in SPECjbb)
>   - S8220198: Lots of com/sun/crypto/provider/Cipher tests fail on
> x86_32 due to missing SHA512 stubs
>   - S8220281: IBM-858 alias name is missing on IBM00858 charset
>   - S8220293: Deadlock in JFR string pool
>   - S8220349: The fix done for JDK-8214253 have caused issues in JTree
> behaviour
>   - S8220353: [TESTBUG] TestRegisterRestoring uses SafepointALot without
> UnlockDiagnosticVMOptions
>   - S8220374: C2: LoopStripMining doesn't strip as expected
>   - S8220441: [PPC64] Clobber memory effect missing for memory barriers
> in atomics
>   - S8220495: Update GIFlib library to the 5.1.8
>   - S8220513: Wrapper Key may get deleted when closing sessions in
> SunPKCS11 crypto provider
>   - S8220625: tools/javac/classreader/8171132/BadConstantValue.java
> failed with "did not see expected error"
>   - S8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java
> fails with jtreg -vmoption:-Xmx < 8g
>   - S8220714: C2 Compilation failure when accessing off-heap memory
> using Unsafe
>   - S8220718: Missing ResourceMark in nmethod::metadata_do
>   - S8220781: linux-s390 : os::get_summary_cpu_info gives bad output
>   - S8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal
> address
>   - S8221083: [ppc64] Wrong oop compare in C1-generated code
>   - S8221175: Fix bad function case for controlled JVM crash on PPC64
> big-endian
>   - S8221244: Unexpected behavior of PropertyDescription.getReadMethod
> for boolean properties
>   - S8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use
>   - S8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java
>   - S8221400: java/lang/String/StringRepeat.java test requests too much heap
>   - S8221401: java/math/BigInteger/LargeValueExceptions.java test should
> be disabled on 32-bit platforms
>   - S8221412: lookupPrintServices() does not always update the list of
> Windows remote printers
>   - S8221437:
> assert(java_lang_invoke_ResolvedMethodName::vmtarget(resolved_method())
> == m()) failed: Should not change after link resolution
>   - S8221470: Print methods in exception messages in java-like Syntax.
>   - S8221479: Fix JFR profiling on s390
>   - S8221483: TestOopCmp.java fails due to "Multiple garbage collectors
> selected"
>   - S8221535: add steal tick related information to hs_error file [linux]
>   - S8221610: Resurrect (legacy) JRE bundle target
>   - S8221639: [i386] expand_exec_shield_cs_limit workaround is undefined
> code after JDK-8199717
>   - S8221833: Readability check in Symbol::is_valid not performed for
> some addresses
>   - S8221870: use driver to run CtwRunner in applications/ctw tests
>   - S8221880: Better customization for Windows RC properties
> FileDescription and ProductName
>   - S8221915: cleanup ticks related coding in os_perf_aix.cpp [aix]
>   - S8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms
>   - S8221924: get(null) on single-entry unmodifiable Map returns null
> instead of throwing NPE
>   - S8222027: java/util/logging/LogManager/TestLoggerNames.java
> generates intermittent ClassCastException
>   - S8222032: x86_32 fails with "wrong size of mach node" on AVX-512 machine
>   - S8222089: [TESTBUG] sun/security/lib/cacerts/VerifyCACerts.java
> fails due to cert within 90-day expiry window
>   - S8222133: Add temporary exceptions for root certs that are due to
> expire soon
>   - S8222136: Remove two Comodo root CA certificates that are expiring
>   - S8222137: Remove T-Systems root CA certificate
>   - S8222397: x86_32 tests with UseSHA1Intrinsics SEGV due to garbled
> registers
>   - S8222410:
> java/nio/file/attribute/BasicFileAttributeView/UnixSocketFile hangs when
> "nc" does not accept "-U"
>   - S8222522: Add configure options for Mac Bundle creation
>   - S8222532: (zipfs) Performance regression when writing ZipFileSystem
> entries in parallel
>   - S8222913: Add Jib support for VERSION_EXTRA*
>   - S8222930: ConcurrentSkipListMap.clone() shares size variable between
> original and clone
>   - S8223266: PPC64: Check for branch to illegal address before checking
> for mem serialization
>   - S8223395: PPC64: Improve comments in the JVM signal handler to match
> ISA text
>   - S8223499: Remove two DocuSign root certificates that are expiring
>   - S8223555: Cleanups in cacerts tests
>   - S8223597: jdk/nio/zipfs/ZipFSTester.java RuntimeException:
> CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)
>   - S8223665: SA: debugd options should follow jhsdb style
>   - S8224474: harfbuzz 2.3.1 code fails to compile with gcc 4.4.7
>   - S8224671: AArch64: mauve System.arraycopy test failure
>   - S8224727: Problem list test
> security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java
>   - S8224828: aarch64: rflags is not correct after safepoint poll
>   - S8224880: AArch64: java/javac error with AllocatePrefetchDistance
>   - S8225402: events logging in deoptimization.cpp should go to deopt-log
>   - S8225716: G1 GC: Undefined behaviour in
> G1BlockOffsetTablePart::block_at_or_preceding
>   - S8226876: Assertion in sun/util/locale/provider/CalendarDataUtility
> on Windows after JDK-8218960
>   - S8226880: Backport of JDK-8208698 (Improved ECC Implementation)
> should not bring parts of JDK-8205476 (KeyAgreement#generateSecret is
> not reset for ECDH based algorithm)
> 


From sgehwolf at redhat.com  Wed Jul 17 14:29:12 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 17 Jul 2019 16:29:12 +0200
Subject: 12.0.2-ga and 13.0.0-ga tags?
In-Reply-To: <9b7e2eb8-e4ec-4997-0cc9-732a4033acbf@ubuntu.com>
References: <CAP7YuARctZMQCrC0E05E=d6aAajVAxMcfZOTV5bygwQyynMYwQ@mail.gmail.com>
 <37ff7003-aaec-ddc0-0053-869dc23057a4@redhat.com>
 <84b23d87-842d-2bba-fb15-3defe0ced93a@redhat.com>
 <CAP7YuAR6nA8Lk3iamCOGWGtc438Dac6+mLG++Dun98ZVSVS=Cg@mail.gmail.com>
 <20190717120301.GB5990@vimes>
 <952229ae-c5f9-196e-52a3-f41cdba3773d@ubuntu.com>
 <7d3a54f486ad2972c95a9bfcccaa783866b48d2f.camel@redhat.com>
 <9b7e2eb8-e4ec-4997-0cc9-732a4033acbf@ubuntu.com>
Message-ID: <6b70611c4490fbb8905c44947e115e5f41501f59.camel@redhat.com>

On Wed, 2019-07-17 at 16:14 +0200, Matthias Klose wrote:
> On 17.07.19 16:04, Severin Gehwolf wrote:
> > On Wed, 2019-07-17 at 15:51 +0200, Matthias Klose wrote:
> > > On 17.07.19 14:03, Rob McKenna wrote:
> > > > Hi folks,
> > > > 
> > > > My sincerest apologies for the delay. There was a last minute issue with
> > > > the repo and I needed a double and triple check before I felt
> > > > comfortable pushing.
> > > 
> > > The jdk-12.0.2-ga and jdk-12.0.2+9 tags now reference different commits.  Is
> > > this expected?
> > 
> > As far as I can see it's jdk-12.0.2-ga -> jdk-12.0.2+9 -> ffb3065f13fe.
> > So it's essentially the same code. What's the concern exactly?
> 
> well, there have been some rants about "mystery meat builds" in the past, so I'm
> asking here. but from looking at http://hg.openjdk.java.net/jdk-updates/jdk12u/
> it's not directly obvious.
> 
> But from looking at
> http://hg.openjdk.java.net/jdk-updates/jdk12u/graph/e8a37f17cf51 I see see there
> is no difference.

Thanks for double-checking!

Cheers,
Severin


From rob.mckenna at oracle.com  Wed Jul 17 15:01:34 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 17 Jul 2019 16:01:34 +0100
Subject: 12.0.2-ga and 13.0.0-ga tags?
In-Reply-To: <6b70611c4490fbb8905c44947e115e5f41501f59.camel@redhat.com>
References: <CAP7YuARctZMQCrC0E05E=d6aAajVAxMcfZOTV5bygwQyynMYwQ@mail.gmail.com>
 <37ff7003-aaec-ddc0-0053-869dc23057a4@redhat.com>
 <84b23d87-842d-2bba-fb15-3defe0ced93a@redhat.com>
 <CAP7YuAR6nA8Lk3iamCOGWGtc438Dac6+mLG++Dun98ZVSVS=Cg@mail.gmail.com>
 <20190717120301.GB5990@vimes>
 <952229ae-c5f9-196e-52a3-f41cdba3773d@ubuntu.com>
 <7d3a54f486ad2972c95a9bfcccaa783866b48d2f.camel@redhat.com>
 <9b7e2eb8-e4ec-4997-0cc9-732a4033acbf@ubuntu.com>
 <6b70611c4490fbb8905c44947e115e5f41501f59.camel@redhat.com>
Message-ID: <20190717150134.GG5990@vimes>

This was an artefact of an issue we ran into with the repo. To
complicate matters I had not pushed the +10 tag to this repo. (note: the
+10 tag also points to the +9 tag) I've just corrected that.

Apologies for the oversight.

    -Rob

On 17/07/19 16:29, Severin Gehwolf wrote:
> On Wed, 2019-07-17 at 16:14 +0200, Matthias Klose wrote:
> > On 17.07.19 16:04, Severin Gehwolf wrote:
> > > On Wed, 2019-07-17 at 15:51 +0200, Matthias Klose wrote:
> > > > On 17.07.19 14:03, Rob McKenna wrote:
> > > > > Hi folks,
> > > > > 
> > > > > My sincerest apologies for the delay. There was a last minute issue with
> > > > > the repo and I needed a double and triple check before I felt
> > > > > comfortable pushing.
> > > > 
> > > > The jdk-12.0.2-ga and jdk-12.0.2+9 tags now reference different commits.  Is
> > > > this expected?
> > > 
> > > As far as I can see it's jdk-12.0.2-ga -> jdk-12.0.2+9 -> ffb3065f13fe.
> > > So it's essentially the same code. What's the concern exactly?
> > 
> > well, there have been some rants about "mystery meat builds" in the past, so I'm
> > asking here. but from looking at http://hg.openjdk.java.net/jdk-updates/jdk12u/
> > it's not directly obvious.
> > 
> > But from looking at
> > http://hg.openjdk.java.net/jdk-updates/jdk12u/graph/e8a37f17cf51 I see see there
> > is no difference.
> 
> Thanks for double-checking!
> 
> Cheers,
> Severin
> 

From stuart.marks at oracle.com  Wed Jul 17 22:48:37 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 17 Jul 2019 15:48:37 -0700
Subject: [11u]: RFR JDK-8227368: EnumSet.class serialization broken in JDK
 9+
In-Reply-To: <a763a2f6-d3c2-5170-a806-a1b3359048fc@gmail.com>
References: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com>
 <0bb07139-762d-1f4a-690d-2ce25a20148e@oracle.com>
 <a763a2f6-d3c2-5170-a806-a1b3359048fc@gmail.com>
Message-ID: <740f6756-178d-bae8-d100-c82b0ed216a0@oracle.com>



On 7/17/19 2:23 AM, Peter Levart wrote:
> It would be interesting to know what the api/serializabletypes JCK 11 test does. 
> Why does it fail when svuid field is introduced?

I'm not sure. The error is that it detects the added field with the value we 
provided. Clearly the class had to have been loaded and initialized for that to 
have occurred, so I suspect it uses reflection.

> Otherwise, your "sleazy hacks" to fabricate the correct (as of JDK 8) computed 
> svuid seem OK. The only gripe is that should any further changes to EnumSet be 
> necessary in JDK 11 u, they would have to be carefully constructed to not break 
> the serialization again. At least there is a test for that now :-)

Given that the changes in JDK 9 and 10 were mostly incidental, it seems unlikely 
that another change will be necessary in JDK 11u. But as you note there is a 
test now, so any changes will be caught quickly.

**

Process notes.

To move this along, I've followed the procedure at [1] (and also related pages 
beneath [2]) to request backport approval. This involved updating the main bug 
JDK-8227368 to add the jdk11u-fix-request and jdk12u-fix-request labels, and to 
add text justifying the backport, the reason for differences from the JDK 13 
fix, and linking to this review thread.

(I kind of doubt this will get put into JDK 12u, but the best way to find out is 
to ask, I think.)

Note that most process activity occurs around the main bug. (This isn't very 
well articulated in the process docs.) To this end, I've updated subject line of 
this message to use main bug, and in my patch I also use the main bug id.

(As an aside, it's usually not necessary to create a backport issue manually. 
When the fix is pushed, one will be created automatically, and the fix-version 
filled in. I've set the fix-version of the backport record JDK-8227650 to 11.0.5 
since I think that's the likely the right release value; but if an extra 
backport record gets created, no big, we can just close out the unused one. I'm 
not sure if this is actually explained anywhere. I did read several pages in the 
updates area of the wiki [2] and they don't say to create a backport issue, but 
they don't say not to either.)

Finally, as expected, the JDK 13 fix has been pulled forward into the jdk/jdk 
mainline.

s'marks

[1] http://openjdk.java.net/projects/jdk-updates/approval.html

[2] https://wiki.openjdk.java.net/display/JDKUpdates

From stuart.marks at oracle.com  Wed Jul 17 23:11:26 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 17 Jul 2019 16:11:26 -0700
Subject: [11u]: RFR JDK-8227368: EnumSet.class serialization broken in JDK
 9+
In-Reply-To: <740f6756-178d-bae8-d100-c82b0ed216a0@oracle.com>
References: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com>
 <0bb07139-762d-1f4a-690d-2ce25a20148e@oracle.com>
 <a763a2f6-d3c2-5170-a806-a1b3359048fc@gmail.com>
 <740f6756-178d-bae8-d100-c82b0ed216a0@oracle.com>
Message-ID: <9be5eebe-f8b4-90a7-3299-ff69958b20e6@oracle.com>



On 7/17/19 3:48 PM, Stuart Marks wrote:
> I've set the fix-version of the backport record JDK-8227650 to 11.0.5 ...

I changed this to 11-pool on advice from Joe Darcy, as this will make it more 
likely that that the automatic hg-updater will pick up this backport issue when 
the fix gets pushed to some 11-update release.

s'marks

From christoph.langer at sap.com  Thu Jul 18 08:06:21 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 18 Jul 2019 08:06:21 +0000
Subject: [12u] AIX build is broken after integration of 12.0.2 due to
 JDK-8210782
Message-ID: <AM6PR02MB51927044427D78CD7FED27178AC80@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Rob, all,

when trying to build OpenJDK 12.0.2 on AIX, we discovered that it is broken due to the change of JDK-8210782 "Upgrade HarfBuzz to the latest 2.3.1". We discovered the AIX issue already during backport of that item to jdk11u. But as Oracle did do the HarfBuzz upgrade for 12.0.2 in their closed repo, the problem was only discovered there when 12.0.2-ga was made public.

For all people out there that need to build AIX 12.0.2, here is the required patch (just verified it):

# HG changeset patch
# Parent  c45c2cbfb841932934185a92ad115f6dd43d4b8a
Fix Harfbuzz 2.3.1 build for AIX XlC 12.1

diff -r c45c2cbfb841 -r c61eeea82197 src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh
--- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh             Wed Jul 17 14:58:26 2019 +0000
+++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh         Thu Jul 18 07:40:29 2019 +0100
@@ -83,7 +83,9 @@
 template <typename T, typename V, typename B>
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 <typename T, typename V>
struct _hb_assign<T, V, _hb_bool_type<(bool) (1 + (unsigned int) T::min_size)> >
{ static inline void value (T &o, const V v) { o.set (v); } };

Rob, shall/can I push this to jdk12u (knowing that this repo is de-facto done as probably nobody will pick up OpenJDK 12 updates)? But I think there'd be some benefit when the repo head would be buildable everywhere... Maybe we should also have another post-ga tag there... don't know.

In any case, I think the process for JDK12 updates or future update releases lead by Oracle is not very optimal for OpenJDK community update releases. This is because you do quite a few pre-GA integrations in your closed repo for changes that could be public. These get only published on the release day. I understand that this can't be done for security updates. However, we should think of process improvements allowing you to merge your build tags on a weekly basis back to the public jdk<nn>u repository to allow testing for downstream vendors. Maybe that's something that can be discussed in the upcoming OpenJDK committers workshop.

Thanks and best regards
Christoph




From mbalao at redhat.com  Thu Jul 18 19:38:46 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 18 Jul 2019 16:38:46 -0300
Subject: [11u] RFR: 8223482: Unsupported ciphersuites may be offered by a TLS
 client
Message-ID: <778861d5-cc04-ee7a-4bb8-eaba161adda0@redhat.com>

Hi,

I'd like to request a review for the jdk11u backport of 8223482 [1]:

http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.jdk11u.webrev.00/

There are 2 changes compared to the JDK version [2]:

 * SSLCipher.java
  * "Cipher.getInstance" replaced with "JsseJce.getCipher" in
SSLCipher::isTransformationAvailable
   * JDK-11 has SunJSSE experimental FIPS support (which was removed in
JDK), so we are able to check if the transformation is supported by
SunJSSE's crypto provider. We don't need to check if it's supported by
any provider because SunJSSE's crypto provider is the one that will be
used for the TLS connection.

 * TestTLS12.java (FipsModeTLS12.java in JDK):
  * The change in TestTLS12::initialize does not apply to JDK-11
   * In JDK-11, we don't remove security providers because we are able
to set the one that has to be used in SunJSSE (due to SunJSSE
experimental FIPS support).

Testing:

 * No regressions found in:
  * jdk/sun/security/pkcs11
  * jdk/javax/net/ssl
  * jdk/com/sun/crypto/provider/TLS

 * TestTLS12 updated to cover this patch

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8223482
[2] - http://hg.openjdk.java.net/jdk/jdk/rev/d0f73fccf5f3

From goetz.lindenmaier at sap.com  Fri Jul 19 09:41:32 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 19 Jul 2019 09:41:32 +0000
Subject: Downport of 8214542: Fix Request comment missing
Message-ID: <AM6PR02MB53477F777B572C7BF9F16D86ECCB0@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi Marcus, 

If I read the history of this bug correctly, you added tag
Jdk11u-fix-request.
https://bugs.openjdk.java.net/browse/JDK-8214542?filter=36358

Could you please also add the mandatory 'Fix Request' comment?
See also 
https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
step 6.

Thanks and best regards,
  Goetz.


From rob.mckenna at oracle.com  Fri Jul 19 13:23:37 2019
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Fri, 19 Jul 2019 14:23:37 +0100
Subject: [12u] AIX build is broken after integration of 12.0.2 due to
 JDK-8210782
In-Reply-To: <AM6PR02MB51927044427D78CD7FED27178AC80@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB51927044427D78CD7FED27178AC80@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <20190719132337.GA6353@vimes>

Hi Christoph,

This change should have been pushed via the open repos. Thats a message
we've been attempting to spread, but unfortunately this change predates that
effort.

For now, please file a push approval request and I'll approve it.

    -Rob

On 18/07/19 08:06, Langer, Christoph wrote:
> Hi Rob, all,
> 
> when trying to build OpenJDK 12.0.2 on AIX, we discovered that it is broken due to the change of JDK-8210782 "Upgrade HarfBuzz to the latest 2.3.1". We discovered the AIX issue already during backport of that item to jdk11u. But as Oracle did do the HarfBuzz upgrade for 12.0.2 in their closed repo, the problem was only discovered there when 12.0.2-ga was made public.
> 
> For all people out there that need to build AIX 12.0.2, here is the required patch (just verified it):
> 
> # HG changeset patch
> # Parent  c45c2cbfb841932934185a92ad115f6dd43d4b8a
> Fix Harfbuzz 2.3.1 build for AIX XlC 12.1
> 
> diff -r c45c2cbfb841 -r c61eeea82197 src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh
> --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh             Wed Jul 17 14:58:26 2019 +0000
> +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh         Thu Jul 18 07:40:29 2019 +0100
> @@ -83,7 +83,9 @@
>  template <typename T, typename V, typename B>
> 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 <typename T, typename V>
> struct _hb_assign<T, V, _hb_bool_type<(bool) (1 + (unsigned int) T::min_size)> >
> { static inline void value (T &o, const V v) { o.set (v); } };
> 
> Rob, shall/can I push this to jdk12u (knowing that this repo is de-facto done as probably nobody will pick up OpenJDK 12 updates)? But I think there'd be some benefit when the repo head would be buildable everywhere... Maybe we should also have another post-ga tag there... don't know.
> 
> In any case, I think the process for JDK12 updates or future update releases lead by Oracle is not very optimal for OpenJDK community update releases. This is because you do quite a few pre-GA integrations in your closed repo for changes that could be public. These get only published on the release day. I understand that this can't be done for security updates. However, we should think of process improvements allowing you to merge your build tags on a weekly basis back to the public jdk<nn>u repository to allow testing for downstream vendors. Maybe that's something that can be discussed in the upcoming OpenJDK committers workshop.
> 
> Thanks and best regards
> Christoph
> 
> 
> 

From martijnverburg at gmail.com  Fri Jul 19 19:28:29 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 19 Jul 2019 20:28:29 +0100
Subject: What is 11-pool Fix Version sued for?
Message-ID: <CAP7YuATa_o-NBu9t-j3Rv2F1cidqGH8GrJ5AguAYtDMb8S4mgA@mail.gmail.com>

Hi all,

Would I be correct in thinking that `11-pool` contains a host of suitable
issues that are available to be picked up by anyone to submit a patch for?

JBS search for a reference:

https://bugs.openjdk.java.net/browse/JDK-8227650?jql=project%20%3D%20JDK%20AND%20fixVersion%20%3D%2011-pool

Cheers,
Martijn

From christoph.langer at sap.com  Sat Jul 20 06:49:02 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sat, 20 Jul 2019 06:49:02 +0000
Subject: What is 11-pool Fix Version sued for?
In-Reply-To: <CAP7YuATa_o-NBu9t-j3Rv2F1cidqGH8GrJ5AguAYtDMb8S4mgA@mail.gmail.com>
References: <CAP7YuATa_o-NBu9t-j3Rv2F1cidqGH8GrJ5AguAYtDMb8S4mgA@mail.gmail.com>
Message-ID: <AM6PR02MB5192AE7042DA23C1F71981688ACA0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Martijn,

11-pool more or less shows, that a fix or backport of some issue to 11 is planned. When the actual fix is pushed, 11-pool will be replaced with the target release version (e.g. 11.0.5 or such). It if for instance needed, if a backport involves a CSR - so one can attach the CSR to the 11-pool issue before actually committing a fix.

HTH
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Martijn Verburg
> Sent: Freitag, 19. Juli 2019 21:28
> To: jdk-updates-dev at openjdk.java.net
> Subject: What is 11-pool Fix Version sued for?
>
> Hi all,
>
> Would I be correct in thinking that `11-pool` contains a host of suitable
> issues that are available to be picked up by anyone to submit a patch for?
>
> JBS search for a reference:
>
> https://bugs.openjdk.java.net/browse/JDK-
> 8227650?jql=project%20%3D%20JDK%20AND%20fixVersion%20%3D%2011-
> pool
>
> Cheers,
> Martijn

From martijnverburg at gmail.com  Sat Jul 20 10:03:42 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 20 Jul 2019 11:03:42 +0100
Subject: What is 11-pool Fix Version sued for?
In-Reply-To: <AM6PR02MB5192AE7042DA23C1F71981688ACA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <CAP7YuATa_o-NBu9t-j3Rv2F1cidqGH8GrJ5AguAYtDMb8S4mgA@mail.gmail.com>
 <AM6PR02MB5192AE7042DA23C1F71981688ACA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <CAP7YuARV40rXaG-8HsZGm2ADtNFboV5xNT2QGm4C691_SuBLag@mail.gmail.com>

Thanks, Christoph,

When you say planned does that mean an engineer from . an org has already
grabbed it to backport or should I/we just look at the assigned field and
assuming it's empty, post here if we want to try and tackle it?

Cheers,
Martijn


On Sat, 20 Jul 2019 at 07:49, Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Martijn,
>
> 11-pool more or less shows, that a fix or backport of some issue to 11 is
> planned. When the actual fix is pushed, 11-pool will be replaced with the
> target release version (e.g. 11.0.5 or such). It if for instance needed, if
> a backport involves a CSR - so one can attach the CSR to the 11-pool issue
> before actually committing a fix.
>
> HTH
> Christoph
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Martijn Verburg
> > Sent: Freitag, 19. Juli 2019 21:28
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: What is 11-pool Fix Version sued for?
> >
> > Hi all,
> >
> > Would I be correct in thinking that `11-pool` contains a host of suitable
> > issues that are available to be picked up by anyone to submit a patch
> for?
> >
> > JBS search for a reference:
> >
> > https://bugs.openjdk.java.net/browse/JDK-
> > 8227650?jql=project%20%3D%20JDK%20AND%20fixVersion%20%3D%2011-
> > pool
> >
> > Cheers,
> > Martijn
>

From rob.mckenna at oracle.com  Sun Jul 21 23:17:22 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 22 Jul 2019 00:17:22 +0100
Subject: What is 11-pool Fix Version sued for?
In-Reply-To: <CAP7YuARV40rXaG-8HsZGm2ADtNFboV5xNT2QGm4C691_SuBLag@mail.gmail.com>
References: <CAP7YuATa_o-NBu9t-j3Rv2F1cidqGH8GrJ5AguAYtDMb8S4mgA@mail.gmail.com>
 <AM6PR02MB5192AE7042DA23C1F71981688ACA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <CAP7YuARV40rXaG-8HsZGm2ADtNFboV5xNT2QGm4C691_SuBLag@mail.gmail.com>
Message-ID: <20190721231722.GA4270@vimes>

Hi folks,

By coincidence a couple of us were discussing this issue last week.

We use it for tracking purposes a lot of the time. (I can check my -pool
records to find outstanding issues)

We're actually thinking of moving over to an NN-pool-<orgname> type
arrangement to avoid stepping on OpenJDK's toes. That is to say, we'll
use NN-pool-oracle on bugs we'd like to track for -oracle releases.

This would mean that if you see a -pool record, you know someone intends
to fix it in an OpenJDK release. (e.g. 11.0.6 as opposed to
11.0.6-oracle)

One slight issue with that is that Oracle engineers may end up using the
-pool-oracle fixVersion out of habit, even where they intend to push to an
OpenJDK release. (e.g. 13.0.2)

Feedback appreciated!

    -Rob

On 20/07/19 11:03, Martijn Verburg wrote:
> Thanks, Christoph,
> 
> When you say planned does that mean an engineer from . an org has already
> grabbed it to backport or should I/we just look at the assigned field and
> assuming it's empty, post here if we want to try and tackle it?
> 
> Cheers,
> Martijn
> 
> 
> On Sat, 20 Jul 2019 at 07:49, Langer, Christoph <christoph.langer at sap.com>
> wrote:
> 
> > Hi Martijn,
> >
> > 11-pool more or less shows, that a fix or backport of some issue to 11 is
> > planned. When the actual fix is pushed, 11-pool will be replaced with the
> > target release version (e.g. 11.0.5 or such). It if for instance needed, if
> > a backport involves a CSR - so one can attach the CSR to the 11-pool issue
> > before actually committing a fix.
> >
> > HTH
> > Christoph
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > > Behalf Of Martijn Verburg
> > > Sent: Freitag, 19. Juli 2019 21:28
> > > To: jdk-updates-dev at openjdk.java.net
> > > Subject: What is 11-pool Fix Version sued for?
> > >
> > > Hi all,
> > >
> > > Would I be correct in thinking that `11-pool` contains a host of suitable
> > > issues that are available to be picked up by anyone to submit a patch
> > for?
> > >
> > > JBS search for a reference:
> > >
> > > https://bugs.openjdk.java.net/browse/JDK-
> > > 8227650?jql=project%20%3D%20JDK%20AND%20fixVersion%20%3D%2011-
> > > pool
> > >
> > > Cheers,
> > > Martijn
> >

From christoph.langer at sap.com  Mon Jul 22 06:28:57 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 22 Jul 2019 06:28:57 +0000
Subject: [12u] RFR (S): 8228466: Fix build on AIX and with Solaris Studio 12u4
 in 12u after HarfBuzz 2.3.1 upgrade
Message-ID: <AM6PR02MB519212B02535DD166006E8DA8AC40@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

please review and approve this patch for fixing the AIX and the Solaris/SS12u4 build of JDK12u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8228466
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8228466.0/

The build issues were only discovered after the final OpenJDK 12.0.2 source was published. Initially I only reported AIX but we also see the build broken on Solaris with the older Sun Studio level 12u4. As per [0], Oracle builds 12u with SS12u6 but we at SAP still used 12u4 and found it working until then. The fix for Solaris seems to be small and harmless, so I request to integrate it as well. The changes prove to work in JDK 11.0.4 [1].

As per prior discussion [2], I request review and approval for pushing this to 12u.

Thanks
Christoph

[0] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
[1] http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a267d045754a
[2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001441.html


From christoph.langer at sap.com  Mon Jul 22 06:34:10 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 22 Jul 2019 06:34:10 +0000
Subject: What is 11-pool Fix Version sued for?
In-Reply-To: <CAP7YuARV40rXaG-8HsZGm2ADtNFboV5xNT2QGm4C691_SuBLag@mail.gmail.com>
References: <CAP7YuATa_o-NBu9t-j3Rv2F1cidqGH8GrJ5AguAYtDMb8S4mgA@mail.gmail.com>
 <AM6PR02MB5192AE7042DA23C1F71981688ACA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <CAP7YuARV40rXaG-8HsZGm2ADtNFboV5xNT2QGm4C691_SuBLag@mail.gmail.com>
Message-ID: <AM6PR02MB5192685F658291D53E8EE0128AC40@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Martijn,

I would check whether there?s an assignee and if there?s one contact him/her or, if unassigned, start work on the issue and post to the appropriate lists. Sometimes (probably mostly) the 11-pool requests are actively worked on but sometimes they also tend to get forgotten.

/Christoph


From: Martijn Verburg <martijnverburg at gmail.com>
Sent: Samstag, 20. Juli 2019 12:04
To: Langer, Christoph <christoph.langer at sap.com>
Cc: jdk-updates-dev at openjdk.java.net
Subject: Re: What is 11-pool Fix Version sued for?

Thanks, Christoph,

When you say planned does that mean an engineer from . an org has already grabbed it to backport or should I/we just look at the assigned field and assuming it's empty, post here if we want to try and tackle it?

Cheers,
Martijn


On Sat, 20 Jul 2019 at 07:49, Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Martijn,

11-pool more or less shows, that a fix or backport of some issue to 11 is planned. When the actual fix is pushed, 11-pool will be replaced with the target release version (e.g. 11.0.5 or such). It if for instance needed, if a backport involves a CSR - so one can attach the CSR to the 11-pool issue before actually committing a fix.

HTH
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net<mailto:jdk-updates-dev-bounces at openjdk.java.net>> On
> Behalf Of Martijn Verburg
> Sent: Freitag, 19. Juli 2019 21:28
> To: jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>
> Subject: What is 11-pool Fix Version sued for?
>
> Hi all,
>
> Would I be correct in thinking that `11-pool` contains a host of suitable
> issues that are available to be picked up by anyone to submit a patch for?
>
> JBS search for a reference:
>
> https://bugs.openjdk.java.net/browse/JDK-
> 8227650?jql=project%20%3D%20JDK%20AND%20fixVersion%20%3D%2011-
> pool
>
> Cheers,
> Martijn

From christoph.langer at sap.com  Mon Jul 22 06:37:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 22 Jul 2019 06:37:39 +0000
Subject: What is 11-pool Fix Version sued for?
In-Reply-To: <20190721231722.GA4270@vimes>
References: <CAP7YuATa_o-NBu9t-j3Rv2F1cidqGH8GrJ5AguAYtDMb8S4mgA@mail.gmail.com>
 <AM6PR02MB5192AE7042DA23C1F71981688ACA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <CAP7YuARV40rXaG-8HsZGm2ADtNFboV5xNT2QGm4C691_SuBLag@mail.gmail.com>
 <20190721231722.GA4270@vimes>
Message-ID: <AM6PR02MB5192871FFC9B845BDFFF150E8AC40@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Rob,

that sounds like a good suggestion. Obviously people, especially those that are not familiar with all the update project processes, will sometimes get something wrong. But that can always be corrected. ??

Can you, at the same time, please fix the 8-pool issues? In 8u the 8-pool version will only be picked up for Oracle releases currently. Openjdk8u pushes for 8-pool items are completely ignored by hgupdater.

Cheers
Christoph

> -----Original Message-----
> From: Rob McKenna <rob.mckenna at oracle.com>
> Sent: Montag, 22. Juli 2019 01:17
> To: Martijn Verburg <martijnverburg at gmail.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: What is 11-pool Fix Version sued for?
> 
> Hi folks,
> 
> By coincidence a couple of us were discussing this issue last week.
> 
> We use it for tracking purposes a lot of the time. (I can check my -pool
> records to find outstanding issues)
> 
> We're actually thinking of moving over to an NN-pool-<orgname> type
> arrangement to avoid stepping on OpenJDK's toes. That is to say, we'll
> use NN-pool-oracle on bugs we'd like to track for -oracle releases.
> 
> This would mean that if you see a -pool record, you know someone intends
> to fix it in an OpenJDK release. (e.g. 11.0.6 as opposed to
> 11.0.6-oracle)
> 
> One slight issue with that is that Oracle engineers may end up using the
> -pool-oracle fixVersion out of habit, even where they intend to push to an
> OpenJDK release. (e.g. 13.0.2)
> 
> Feedback appreciated!
> 
>     -Rob
> 
> On 20/07/19 11:03, Martijn Verburg wrote:
> > Thanks, Christoph,
> >
> > When you say planned does that mean an engineer from . an org has
> already
> > grabbed it to backport or should I/we just look at the assigned field and
> > assuming it's empty, post here if we want to try and tackle it?
> >
> > Cheers,
> > Martijn
> >
> >
> > On Sat, 20 Jul 2019 at 07:49, Langer, Christoph <christoph.langer at sap.com>
> > wrote:
> >
> > > Hi Martijn,
> > >
> > > 11-pool more or less shows, that a fix or backport of some issue to 11 is
> > > planned. When the actual fix is pushed, 11-pool will be replaced with the
> > > target release version (e.g. 11.0.5 or such). It if for instance needed, if
> > > a backport involves a CSR - so one can attach the CSR to the 11-pool issue
> > > before actually committing a fix.
> > >
> > > HTH
> > > Christoph
> > >
> > > > -----Original Message-----
> > > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> On
> > > > Behalf Of Martijn Verburg
> > > > Sent: Freitag, 19. Juli 2019 21:28
> > > > To: jdk-updates-dev at openjdk.java.net
> > > > Subject: What is 11-pool Fix Version sued for?
> > > >
> > > > Hi all,
> > > >
> > > > Would I be correct in thinking that `11-pool` contains a host of suitable
> > > > issues that are available to be picked up by anyone to submit a patch
> > > for?
> > > >
> > > > JBS search for a reference:
> > > >
> > > > https://bugs.openjdk.java.net/browse/JDK-
> > > >
> 8227650?jql=project%20%3D%20JDK%20AND%20fixVersion%20%3D%2011-
> > > > pool
> > > >
> > > > Cheers,
> > > > Martijn
> > >

From goetz.lindenmaier at sap.com  Mon Jul 22 09:02:18 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 22 Jul 2019 09:02:18 +0000
Subject: Downport of 8214542: Fix Request comment missing
In-Reply-To: <CAOpWGx2KHLp8SVviND5bLS88URevZDC1HTvq1m2HF7AtAZTMZQ@mail.gmail.com>
References: <AM6PR02MB53477F777B572C7BF9F16D86ECCB0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <CAOpWGx2KHLp8SVviND5bLS88URevZDC1HTvq1m2HF7AtAZTMZQ@mail.gmail.com>
Message-ID: <AM6PR02MB5347C0E5E3B75D391664F771ECC40@AM6PR02MB5347.eurprd02.prod.outlook.com>

Thanks :)

> -----Original Message-----
> From: Marcus Hirt <marcus.hirt at datadoghq.com>
> Sent: Montag, 22. Juli 2019 10:44
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: Re: Downport of 8214542: Fix Request comment missing
> 
> Sure thing. Added some additional context.
> 
> Kind regards,
> Marcus
> 
> On Fri, Jul 19, 2019 at 11:42 AM Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi Marcus,
> >
> > If I read the history of this bug correctly, you added tag
> > Jdk11u-fix-request.
> > https://bugs.openjdk.java.net/browse/JDK-8214542?filter=36358
> >
> > Could you please also add the mandatory 'Fix Request' comment?
> > See also
> > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
> > step 6.
> >
> > Thanks and best regards,
> >   Goetz.
> >

From christoph.langer at sap.com  Mon Jul 22 09:48:37 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 22 Jul 2019 09:48:37 +0000
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
 ECDHServerKeyExchange
In-Reply-To: <50cd9f32-e8fc-07af-57f9-c09d16a39c0c@oracle.com>
References: <AM6PR02MB5192197FCDF6C7991D135E838AFA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB51922F6378CAFFF50EF2C4568AF30@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <94780af5-378f-bb1d-9d46-a56dcd9f9722@oracle.com>
 <50cd9f32-e8fc-07af-57f9-c09d16a39c0c@oracle.com>
Message-ID: <AM6PR02MB51922A16C8CEF1B098A56CAC8AC40@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Valerie,

thanks again for looking at my backport changelist for 8216039 in 11.0.5.

As for JDK-8225745: We shall probably backport this to OpenJDK 11u, when Oracle also brings this to their JDK 11 updates. I'll monitor it ??

Best regards
Christoph



> -----Original Message-----
> From: Valerie Peng <valerie.peng at oracle.com>
> Sent: Freitag, 12. Juli 2019 01:38
> To: jdk-updates-dev at openjdk.java.net; Langer, Christoph
> <christoph.langer at sap.com>
> Subject: Re: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
> ECDHServerKeyExchange
> 
> BTW, I have just integrated a relevant fix
> (https://bugs.openjdk.java.net/browse/JDK-8225745) which should probably
> be backported as well...
> 
> Thanks,
> Valerie

From sgehwolf at redhat.com  Mon Jul 22 10:57:30 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 22 Jul 2019 12:57:30 +0200
Subject: [11u] RFR: 8220672: [TESTBUG] TestCPUSets should check that cpuset
 does not exceed available cores
Message-ID: <8a45565ffd1089bb7425817a1117b75f9e4d164f.camel@redhat.com>

Hi,

I'm working on getting better container testing experience in JDK 11u.
One of the issues I'd like to backport is this one. Also, it's one of
those cases which got backported in 11.0.5-oracle.

The jdk/jdk changeset didn't apply cleanly since a)
jtreg.SkippedException is being thrown in jdk/jdk, not available in JDK
11u b) TestCPUSets.java wasn't problem-listed in JDK 11u. Otherwise the
patch is the same.

I've not included the change for b) and opted for System.out.println()
and return as a substitute for a).

Bug: https://bugs.openjdk.java.net/browse/JDK-8220672
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8220672/jdk11/01/webrev/
original-changeset: http://hg.openjdk.java.net/jdk/jdk/rev/a73fe240da4a

Testing: Ran docker tests on Linux x86_64.

Thoughts?

Thanks,
Severin


From marcus.hirt at datadoghq.com  Mon Jul 22 08:43:50 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 22 Jul 2019 10:43:50 +0200
Subject: Downport of 8214542: Fix Request comment missing
In-Reply-To: <AM6PR02MB53477F777B572C7BF9F16D86ECCB0@AM6PR02MB5347.eurprd02.prod.outlook.com>
References: <AM6PR02MB53477F777B572C7BF9F16D86ECCB0@AM6PR02MB5347.eurprd02.prod.outlook.com>
Message-ID: <CAOpWGx2KHLp8SVviND5bLS88URevZDC1HTvq1m2HF7AtAZTMZQ@mail.gmail.com>

Sure thing. Added some additional context.

Kind regards,
Marcus

On Fri, Jul 19, 2019 at 11:42 AM Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
>
> Hi Marcus,
>
> If I read the history of this bug correctly, you added tag
> Jdk11u-fix-request.
> https://bugs.openjdk.java.net/browse/JDK-8214542?filter=36358
>
> Could you please also add the mandatory 'Fix Request' comment?
> See also
> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
> step 6.
>
> Thanks and best regards,
>   Goetz.
>

From sgehwolf at redhat.com  Mon Jul 22 15:09:36 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 22 Jul 2019 17:09:36 +0200
Subject: [11u] RFR: 8221710: [TESTBUG] more configurable parameters for
 docker testing
Message-ID: <735d2d022611a36899262ed77a608438a0765b3a.camel@redhat.com>

Hi,

Please review one additional docker tests backport. A pre-requisite for
JDK-8224165 to bring down which helps verifying JDK-8220672. The JDK 13
patch applies cleanly, but doesn't work without modifications pointed
out below as JDK 11 doesn't have SkippedException (which is a rather
large changeset to bring down)

Bug: https://bugs.openjdk.java.net/browse/JDK-8221710
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221710/jdk11/01/webrev/
original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/b354ffb03ae4

Testing: Ran docker tests on Linux x86_64

Thoughts?

Thanks,
Severin

diff --git a/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java b/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java
--- a/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java
+++ b/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java
@@ -38,7 +38,6 @@
 import jdk.test.lib.Utils;
 import jdk.test.lib.process.OutputAnalyzer;
 import jdk.test.lib.process.ProcessTools;
-import jtreg.SkippedException;
 
 
 public class DockerTestUtils {
@@ -92,7 +91,9 @@
         if (isDockerEngineAvailable()) {
             return true;
         } else {
-            throw new SkippedException("Docker engine is not available on this system");
+            System.out.println("Docker engine is not available on this system");
+            System.out.println("This test is SKIPPED");
+            return false;
         }
     }
 



From GROEGES at uk.ibm.com  Tue Jul 23 08:52:07 2019
From: GROEGES at uk.ibm.com (Steve Groeger)
Date: Tue, 23 Jul 2019 09:52:07 +0100
Subject: RFR: 8226468: loadquery failed error message displayed
Message-ID: <OF0CE01E4A.48619CCD-ON80258440.003092C9-80258440.0030B62C@notes.na.collabserv.com>

Hi Thomas, 

Thanks for handling this change for me. 
I have requested for the change to be back-ported to jdk11, jdk12 and 
jdk13. 
I am still awaiting the agreement to have it back-ported to jdk11, but it 
has been approved to be back-ported to jdk12 and jdk13. 
I would be grateful if you could make the changes to these jdk versions. 
Any issues 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 


"Thomas St?fe" <thomas.stuefe at gmail.com> wrote on 25/06/2019 14:17:19:

> From: "Thomas St?fe" <thomas.stuefe at gmail.com> 
> To: Steve Groeger <GROEGES at uk.ibm.com> 
> Cc: "Baesken, Matthias" <matthias.baesken at sap.com>, ppc-aix-port-dev
> <ppc-aix-port-dev at openjdk.java.net> 
> Date: 25/06/2019 14:17 
> Subject: Re: RFR: 8226468: loadquery failed error message displayed 
> 
> Hi Steve, 
> 
> looks good. Its fine, we do not need a realloc loop. Keep it simple 
stupid :) 
> 
> I can sponsor this for you. 
> 
> ..Thomas 
> 
> On Tue, Jun 25, 2019 at 2:57 PM Steve Groeger <GROEGES at uk.ibm.com> 
wrote: 
> Matthias / Thomas, 
> 
> Thanks for all your comments. I have created an issue [1] and also a
> webrev [2] to resolve this issue. 
> 
> I have just doubled the size of the buffer (to 0x8000) in both 
> places you mentioned. 
> If we want to use the same method as used in loadlib_aix.cpp then I 
> can look at doing that. 
> 
> If I can get someone to sponsor this change and to also review the 
> webrev I would be very grateful. 
> 
> Once this has been approved and committed then I would probabamly 
> look at getting this back-ported to jdk13 and jdk11. 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8226468 
> [2] http://cr.openjdk.java.net/~sgroeger/8226468-1/webrev.00/ 
> 
> 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 
> 
> "Baesken, Matthias" <matthias.baesken at sap.com> wrote on 25/06/2019 
11:19:26:
> 
> > From: "Baesken, Matthias" <matthias.baesken at sap.com> 
> > To: "Thomas St?fe" <thomas.stuefe at gmail.com>, Steve Groeger 
> > <GROEGES at uk.ibm.com> 
> > Cc: ppc-aix-port-dev <ppc-aix-port-dev at openjdk.java.net> 
> > Date: 25/06/2019 11:19 
> > Subject: RE: loadquery failed error message displayed 
> > 
> > Hi Steve, please create an issue + patch . 
> > 
> > Btw.  I wonder also about   the other  loadquery  usages : 
> > 
> > 
> > java_md_aix.c 
> > 
> > static unsigned char dladdr_buffer[0x4000]; 
> > 
> > 33 return loadquery(L_GETINFO, dladdr_buffer, sizeof(dladdr_buffer)); 
> > 
> > 
> > loadlib_aix.cpp 
> > 
> > 192 // Call loadquery(L_GETINFO..) to get a list of all loaded Dlls 
> > from AIX. loadquery 
> > 198 if (loadquery(L_GETINFO, buffer, buflen) == -1) { 
> > 
> > 
> > 
> > Maybe you  could also adjust the  buffer size in  java_md_aix.c  as 
well  ?
> > (  The usage  in  loadlib_aix.cpp  uses a buffer reallocation  until
> > the size is large enough.  ) 
> > 
> > Increasing by factor of 2  is fine with me .  But maybe some people 
> > prefer what we do in  loadlib_aix.cpp (reallocation at runtime ). 
> > 
> > 
> > 
> > 
> > Best regards, Matthias 
> > 
> > 
> > From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net> 
> > On Behalf Of Thomas St?fe
> > Sent: Mittwoch, 19. Juni 2019 19:21
> > To: Steve Groeger <GROEGES at uk.ibm.com>
> > Cc: ppc-aix-port-dev <ppc-aix-port-dev at openjdk.java.net>
> > Subject: Re: loadquery failed error message displayed 
> > 
> > Hi Steve, 
> > 
> > I wrote this a very long time ago and we never ran into this 
> > problem, curious that it took so long... but of course, please 
> > create an issue and do a patch, thanks! 
> > 
> > I would probably just increase the buffer by factor 2 or 4. 
> > 
> > Cheers, Thomas 
> > 
> > On Wed, Jun 19, 2019, 14:19 Steve Groeger <GROEGES at uk.ibm.com> wrote: 
> > Hi all, 
> > 
> > We have a scenario where in a Java program after loading some shared
> > libraries (using System.loadLibrary) and then calling 
> > javax.imageio.ImageIO.read(new File(..)) the java program displays 
> > the following error message: 
> > 
> > loadquery failed (12 Not enough space) 
> > 
> > This happens when running on AIX with Java 11 using this sample code: 
> > 
> > import java.io.File;
> > import java.util.Map;
> > import javax.imageio.ImageIO;
> > public class Reproduce {
> >    public static void main(String[] args) {
> >        try {
> >            System.loadLibrary("mylib");
> > 
> >            String filePath = "...";
> >            BufferedImage img = ImageIO.read(new File(filePath));
> > 
> >        }
> >        catch (Throwable e) {
> >            System.out.println("Exception : " + e);
> >            e.printStackTrace();
> >        }
> >    }
> > } 
> > 
> > It seems that this is displayed from src/java.desktop/aix/native/
> > libawt/porting_aix.c 
> > 
> > static unsigned char dladdr_buffer[0x4000];
> > 
> > static void fill_dll_info(void) {
> >  int rc = loadquery(L_GETINFO,dladdr_buffer, sizeof(dladdr_buffer));
> >  if (rc == -1) {
> >    fprintf(stderr, "loadquery failed (%d %s)", errno, 
strerror(errno));
> >    fflush(stderr);
> >  }
> > }
> > 
> > and is due to the dladdr_info buffer being too small to contain all 
> > the data returned from the loadquery function. 
> > 
> > The same buffer size is also used in src/java.base/aix/native/
> > libjli/java_md_aix.c 
> > 
> > Could / Should the size of these buffers be increased to handle the 
> > large data and prevent the error message from being displayed. 
> > If so, I am happy to raise an issue and to generate a webrev for this. 

> > What would people suggest as a suitable size for the buffer, ie 
> > double the size (x8000) or something else? 
> > 
> > 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
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From matthias.baesken at sap.com  Tue Jul 23 11:36:19 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 23 Jul 2019 11:36:19 +0000
Subject: [12u] RFR (S): 8228466: Fix build on AIX and with Solaris Studio
 12u4 in 12u after HarfBuzz 2.3.1 upgrade
In-Reply-To: <AM6PR02MB5192933B0BC5F6BA8E7B19C98AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192933B0BC5F6BA8E7B19C98AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB50786E755E7FC1477A4E2CBE93C70@AM6PR02MB5078.eurprd02.prod.outlook.com>

Looks good to me !

Best regards, Matthias



From: Langer, Christoph
Sent: Montag, 22. Juli 2019 08:29
To: jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>; 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>; 'rob.mckenna at oracle.com' <rob.mckenna at oracle.com<mailto:rob.mckenna at oracle.com>>
Subject: [12u] RFR (S): 8228466: Fix build on AIX and with Solaris Studio 12u4 in 12u after HarfBuzz 2.3.1 upgrade

Hi,

please review and approve this patch for fixing the AIX and the Solaris/SS12u4 build of JDK12u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8228466
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8228466.0/

The build issues were only discovered after the final OpenJDK 12.0.2 source was published. Initially I only reported AIX but we also see the build broken on Solaris with the older Sun Studio level 12u4. As per [0], Oracle builds 12u with SS12u6 but we at SAP still used 12u4 and found it working until then. The fix for Solaris seems to be small and harmless, so I request to integrate it as well. The changes prove to work in JDK 11.0.4 [1].

As per prior discussion [2], I request review and approval for pushing this to 12u.

Thanks
Christoph

[0] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
[1] http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a267d045754a
[2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001441.html


From christoph.langer at sap.com  Tue Jul 23 14:58:15 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 23 Jul 2019 14:58:15 +0000
Subject: [11u] 8205654: serviceability/dcmd/framework/HelpTest.java timed out
Message-ID: <AM6PR02MB51921687C268BAE4C923E39F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

please review the backport of "8205654: serviceability/dcmd/framework/HelpTest.java timed out" to OpenJDK 11u. We're seeing the mentioned test issue intermittently in our nightlies.

Bug: https://bugs.openjdk.java.net/browse/JDK-8205654
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8205654.11u-dev.0/
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/67537bbafd7f
Original review discussion: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/026883.html

The change improves the way how jcmd explores running Java processes on Linux. It'll then try to use the proc file system first to get the necessary information before trying to attach via the attach framework.

The original patch needs 2 modifications:
1. In src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java I had to add the fix of JDK-8218705. The bug is not visible unfortunately but it seems something was forgot in the original commit. The change for JDK-8218705 is: http://hg.openjdk.java.net/jdk/jdk/rev/50c1b0a0f1e8
2. In test/lib/jdk/test/lib/util/JarUtils.java I had to take over some upstream coding from jdk/jdk to provide the JarUtils support that is needed by the new testcase "TestProcessHelper".

Thanks
Christoph


From christoph.langer at sap.com  Tue Jul 23 15:20:49 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 23 Jul 2019 15:20:49 +0000
Subject: [11u] 8219513:
 compiler/codegen/aes/TestCipherBlockChainingEncrypt.java timeout on
 Solaris-sparc
Message-ID: <AM6PR02MB5192C79A7A643EC2935926F28AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

test cleanup time... please review another testfix backport.

Bug: https://bugs.openjdk.java.net/browse/JDK-8219513
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219513.11u-dev.0/
Original change: http://hg.openjdk.java.net/jdk/jdk/rev/8c82412da698

The patch did not apply cleanly, unfortunately, because jtreg.SkippedException is not yet available in 11u. But other than that it applies and seems to quiesce the test.

Thanks
Christoph


From christoph.langer at sap.com  Tue Jul 23 15:29:54 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 23 Jul 2019 15:29:54 +0000
Subject: [11u] RFR: 8227041: runtime/memory/RunUnitTestsConcurrently.java has
 a memory leak
Message-ID: <AM6PR02MB51926C7EE75A84679B00902F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

please review backport of this test fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8227041
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8227041.11u-dev.0/

The test is a real resource drain and causes OOMs - while not really testing something useful. It was already removed in jdk/jdk - so requesting to remove it from JDK11u as well (to fix sporadic test failures).

In jdk11 the relevant source files look a bit different, so I had to modify the original changeset a bit.

Thanks
Christoph


From sgehwolf at redhat.com  Tue Jul 23 15:35:32 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 23 Jul 2019 17:35:32 +0200
Subject: [11u] 8219513:
 compiler/codegen/aes/TestCipherBlockChainingEncrypt.java timeout on
 Solaris-sparc
In-Reply-To: <AM6PR02MB5192C79A7A643EC2935926F28AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192C79A7A643EC2935926F28AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <103de0f469ca8ffe07988d887b6e3563f22e3d8a.camel@redhat.com>

Hi,

On Tue, 2019-07-23 at 15:20 +0000, Langer, Christoph wrote:
> Hi,
> 
> test cleanup time... please review another testfix backport.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8219513
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219513.11u-dev.0/
> Original change: http://hg.openjdk.java.net/jdk/jdk/rev/8c82412da698
> 
> The patch did not apply cleanly, unfortunately, because jtreg.SkippedException is not yet available in 11u. But other than that it applies and seems to quiesce the test.

This looks reasonable.

Those jtreg.SkippedException changes pop up a lot when backporting test
fixes/improvements which make me wonder whether we should add a
jtreg.SkippedException in the JDK 11u test tree for one backport and
then have subsequent backports apply as-is. That requires a minimum
version of jtreg, though.

Thoughts?

Thanks,
Severin


From vladimir.kozlov at oracle.com  Tue Jul 23 16:01:15 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Jul 2019 09:01:15 -0700
Subject: [11u] 8219513:
 compiler/codegen/aes/TestCipherBlockChainingEncrypt.java timeout on
 Solaris-sparc
In-Reply-To: <AM6PR02MB5192C79A7A643EC2935926F28AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192C79A7A643EC2935926F28AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <2b3372ec-543a-59c5-4b67-d10c6a06821b@oracle.com>

Good.

Thanks,
Vladimir

On 7/23/19 8:20 AM, Langer, Christoph wrote:
> Hi,
> 
> test cleanup time... please review another testfix backport.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8219513
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219513.11u-dev.0/
> Original change: http://hg.openjdk.java.net/jdk/jdk/rev/8c82412da698
> 
> The patch did not apply cleanly, unfortunately, because jtreg.SkippedException is not yet available in 11u. But other than that it applies and seems to quiesce the test.
> 
> Thanks
> Christoph
> 

From mbalao at redhat.com  Tue Jul 23 17:01:22 2019
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 23 Jul 2019 14:01:22 -0300
Subject: [11u] RFR: 8223482: Unsupported ciphersuites may be offered by a
 TLS client
In-Reply-To: <778861d5-cc04-ee7a-4bb8-eaba161adda0@redhat.com>
References: <778861d5-cc04-ee7a-4bb8-eaba161adda0@redhat.com>
Message-ID: <b1be78b4-00bb-dee9-aaa6-b907c941aba4@redhat.com>

CC'ing security-dev.

Thanks,
Martin.-


On 7/18/19 4:38 PM, Martin Balao wrote:
> Hi,
> 
> I'd like to request a review for the jdk11u backport of 8223482 [1]:
> 
> http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.jdk11u.webrev.00/
> 
> There are 2 changes compared to the JDK version [2]:
> 
>  * SSLCipher.java
>   * "Cipher.getInstance" replaced with "JsseJce.getCipher" in
> SSLCipher::isTransformationAvailable
>    * JDK-11 has SunJSSE experimental FIPS support (which was removed in
> JDK), so we are able to check if the transformation is supported by
> SunJSSE's crypto provider. We don't need to check if it's supported by
> any provider because SunJSSE's crypto provider is the one that will be
> used for the TLS connection.
> 
>  * TestTLS12.java (FipsModeTLS12.java in JDK):
>   * The change in TestTLS12::initialize does not apply to JDK-11
>    * In JDK-11, we don't remove security providers because we are able
> to set the one that has to be used in SunJSSE (due to SunJSSE
> experimental FIPS support).
> 
> Testing:
> 
>  * No regressions found in:
>   * jdk/sun/security/pkcs11
>   * jdk/javax/net/ssl
>   * jdk/com/sun/crypto/provider/TLS
> 
>  * TestTLS12 updated to cover this patch
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8223482
> [2] - http://hg.openjdk.java.net/jdk/jdk/rev/d0f73fccf5f3
> 


From gnu.andrew at redhat.com  Tue Jul 23 19:35:25 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 23 Jul 2019 20:35:25 +0100
Subject: [11u] RFR: 8223482: Unsupported ciphersuites may be offered by a
 TLS client
In-Reply-To: <778861d5-cc04-ee7a-4bb8-eaba161adda0@redhat.com>
References: <778861d5-cc04-ee7a-4bb8-eaba161adda0@redhat.com>
Message-ID: <eeb124a4-f983-64bb-29eb-863b6b153beb@redhat.com>



On 18/07/2019 20:38, Martin Balao wrote:
> Hi,
> 
> I'd like to request a review for the jdk11u backport of 8223482 [1]:
> 
> http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.jdk11u.webrev.00/
> 
> There are 2 changes compared to the JDK version [2]:
> 
>  * SSLCipher.java
>   * "Cipher.getInstance" replaced with "JsseJce.getCipher" in
> SSLCipher::isTransformationAvailable
>    * JDK-11 has SunJSSE experimental FIPS support (which was removed in
> JDK), so we are able to check if the transformation is supported by
> SunJSSE's crypto provider. We don't need to check if it's supported by
> any provider because SunJSSE's crypto provider is the one that will be
> used for the TLS connection.
> 
>  * TestTLS12.java (FipsModeTLS12.java in JDK):
>   * The change in TestTLS12::initialize does not apply to JDK-11
>    * In JDK-11, we don't remove security providers because we are able
> to set the one that has to be used in SunJSSE (due to SunJSSE
> experimental FIPS support).
> 
> Testing:
> 
>  * No regressions found in:
>   * jdk/sun/security/pkcs11
>   * jdk/javax/net/ssl
>   * jdk/com/sun/crypto/provider/TLS
> 
>  * TestTLS12 updated to cover this patch
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8223482
> [2] - http://hg.openjdk.java.net/jdk/jdk/rev/d0f73fccf5f3
> 

The changes mentioned look ok to me.

I am curious as to why the copyright headers are being altered,
especially for
src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java which
is otherwise identical to the JDK version.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From gnu.andrew at redhat.com  Tue Jul 23 19:51:51 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 23 Jul 2019 20:51:51 +0100
Subject: CFV: New OpenJDK Updates Committer: Martin Balao
Message-ID: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>

I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
Updates Committer.

Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it
makes little sense for him not to be a committer for the updates
project. He has already had a number of changes pushed to the 11u
repositories by others. [0]

Votes are due by 20h00 UTC on the 6th of August, 2019.

Only current OpenJDK Updates Committers [1] are eligible to vote on
this nomination.

Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2].

[0]
https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
[1] https://openjdk.java.net/census#jdk-updates
[2] http://openjdk.java.net/projects/#committer-vote
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From gnu.andrew at redhat.com  Tue Jul 23 19:52:47 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 23 Jul 2019 20:52:47 +0100
Subject: CFV: New OpenJDK Updates Committer: Martin Balao
In-Reply-To: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
References: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
Message-ID: <ef92b34c-8313-2ce3-b36e-8210bdb2a93e@redhat.com>



On 23/07/2019 20:51, Andrew John Hughes wrote:
> I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
> Updates Committer.
> 
> Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it
> makes little sense for him not to be a committer for the updates
> project. He has already had a number of changes pushed to the 11u
> repositories by others. [0]
> 
> Votes are due by 20h00 UTC on the 6th of August, 2019.
> 
> Only current OpenJDK Updates Committers [1] are eligible to vote on
> this nomination.
> 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> [0]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] https://openjdk.java.net/census#jdk-updates
> [2] http://openjdk.java.net/projects/#committer-vote
> 

Vote: Yes
-- 
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 bourges.laurent at gmail.com  Tue Jul 23 19:58:08 2019
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 23 Jul 2019 21:58:08 +0200
Subject: CFV: New OpenJDK Updates Committer: Martin Balao
In-Reply-To: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
References: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
Message-ID: <CAKjRUT7oRr6nXq7WY8+qNGQ5B898HPP1rEgsZZX0dsaU5VsUZQ@mail.gmail.com>

Vote: Yes

Le mar. 23 juil. 2019 ? 21:52, Andrew John Hughes <gnu.andrew at redhat.com> a
?crit :

> I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
> Updates Committer.
>
> Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it
> makes little sense for him not to be a committer for the updates
> project. He has already had a number of changes pushed to the 11u
> repositories by others. [0]
>
> Votes are due by 20h00 UTC on the 6th of August, 2019.
>
> Only current OpenJDK Updates Committers [1] are eligible to vote on
> this nomination.
>
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> [0]
>
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] https://openjdk.java.net/census#jdk-updates
> [2] http://openjdk.java.net/projects/#committer-vote
> --
> 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
>
>

-- 
-- 
Laurent Bourg?s

From zgu at redhat.com  Tue Jul 23 19:59:18 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 23 Jul 2019 15:59:18 -0400
Subject: CFV: New OpenJDK Updates Committer: Martin Balao
In-Reply-To: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
References: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
Message-ID: <58c3d46c-3cb1-360b-ed19-1dce7789d717@redhat.com>

Vote: yes

-Zhengyu

On 7/23/19 3:51 PM, Andrew John Hughes wrote:
> I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
> Updates Committer.
> 
> Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it
> makes little sense for him not to be a committer for the updates
> project. He has already had a number of changes pushed to the 11u
> repositories by others. [0]
> 
> Votes are due by 20h00 UTC on the 6th of August, 2019.
> 
> Only current OpenJDK Updates Committers [1] are eligible to vote on
> this nomination.
> 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> [0]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] https://openjdk.java.net/census#jdk-updates
> [2] http://openjdk.java.net/projects/#committer-vote
> 

From gnu.andrew at redhat.com  Tue Jul 23 20:00:42 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 23 Jul 2019 21:00:42 +0100
Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
Message-ID: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>

I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.

Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not
to have him doing similar work for 11u. He does also have a sizeable
number of OpenJDK commits, particularly in the AWT and graphics area [1].

Votes are due by 20h00 UTC on the 6th of August, 2019.

Only current OpenJDK Updates Reviewers [2] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.

For Three-Vote Consensus voting instructions, see [3].

[0] https://openjdk.java.net/census#neugens
[1]
https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
[2] https://openjdk.java.net/census#jdk-updates
[3] https://openjdk.java.net/bylaws#three-vote-consensus
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From gnu.andrew at redhat.com  Tue Jul 23 20:01:02 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 23 Jul 2019 21:01:02 +0100
Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
In-Reply-To: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
Message-ID: <2cd88c33-45f9-afca-6cdc-082bfd2d5b0f@redhat.com>



On 23/07/2019 21:00, Andrew John Hughes wrote:
> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.
> 
> Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not
> to have him doing similar work for 11u. He does also have a sizeable
> number of OpenJDK commits, particularly in the AWT and graphics area [1].
> 
> Votes are due by 20h00 UTC on the 6th of August, 2019.
> 
> Only current OpenJDK Updates Reviewers [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
> 
> For Three-Vote Consensus voting instructions, see [3].
> 
> [0] https://openjdk.java.net/census#neugens
> [1]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
> [2] https://openjdk.java.net/census#jdk-updates
> [3] https://openjdk.java.net/bylaws#three-vote-consensus
> 

Vote: Yes
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From hohensee at amazon.com  Tue Jul 23 20:20:22 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 23 Jul 2019 20:20:22 +0000
Subject: New OpenJDK Updates Committer: Martin Balao
In-Reply-To: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
References: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
Message-ID: <ACF5A36C-64D5-46FF-BE19-AE0C174DF15A@amazon.com>

Vote: yes

?On 7/23/19, 12:52 PM, "jdk-updates-dev on behalf of Andrew John Hughes" <jdk-updates-dev-bounces at openjdk.java.net on behalf of gnu.andrew at redhat.com> wrote:

    I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
    Updates Committer.
    
    Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it
    makes little sense for him not to be a committer for the updates
    project. He has already had a number of changes pushed to the 11u
    repositories by others. [0]
    
    Votes are due by 20h00 UTC on the 6th of August, 2019.
    
    Only current OpenJDK Updates Committers [1] are eligible to vote on
    this nomination.
    
    Votes must be cast in the open by replying to this mailing list.
    
    For Lazy Consensus voting instructions, see [2].
    
    [0]
    https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
    [1] https://openjdk.java.net/census#jdk-updates
    [2] http://openjdk.java.net/projects/#committer-vote
    -- 
    Andrew :)
    
    Senior Free Java Software Engineer
    Red Hat, Inc. (http://www.redhat.com)
    
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
    https://keybase.io/gnu_andrew
    
    


From hohensee at amazon.com  Tue Jul 23 20:20:42 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 23 Jul 2019 20:20:42 +0000
Subject: New OpenJDK Updates Reviewer: Mario Torre
In-Reply-To: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
Message-ID: <2762991E-DCD5-47E6-AD71-51A74D65E0E3@amazon.com>

Vote: yes

?On 7/23/19, 1:02 PM, "jdk-updates-dev on behalf of Andrew John Hughes" <jdk-updates-dev-bounces at openjdk.java.net on behalf of gnu.andrew at redhat.com> wrote:

    I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.
    
    Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not
    to have him doing similar work for 11u. He does also have a sizeable
    number of OpenJDK commits, particularly in the AWT and graphics area [1].
    
    Votes are due by 20h00 UTC on the 6th of August, 2019.
    
    Only current OpenJDK Updates Reviewers [2] are eligible to vote on this
    nomination. Votes must be cast in the open by replying to this mailing
    list.
    
    For Three-Vote Consensus voting instructions, see [3].
    
    [0] https://openjdk.java.net/census#neugens
    [1]
    https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
    [2] https://openjdk.java.net/census#jdk-updates
    [3] https://openjdk.java.net/bylaws#three-vote-consensus
    -- 
    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 zgu at redhat.com  Tue Jul 23 20:25:53 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 23 Jul 2019 16:25:53 -0400
Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
In-Reply-To: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
Message-ID: <66a8c5f1-7539-1109-eb20-cab15df1d243@redhat.com>

Hi Andrew,

On 7/23/19 4:00 PM, Andrew John Hughes wrote:
> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.

You meant jdk-updates reviewer, right? Cause Mario is already a 8u reviewer.

...
jdk7u	JDK 7 Updates Project ? Reviewer
jdk8	JDK 8 Project ? Committer
jdk8u	JDK 8 Updates Project ? Reviewer
...

-Zhengyu

> 
> Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not
> to have him doing similar work for 11u. He does also have a sizeable
> number of OpenJDK commits, particularly in the AWT and graphics area [1].
> 
> Votes are due by 20h00 UTC on the 6th of August, 2019.
> 
> Only current OpenJDK Updates Reviewers [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
> 
> For Three-Vote Consensus voting instructions, see [3].
> 
> [0] https://openjdk.java.net/census#neugens
> [1]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
> [2] https://openjdk.java.net/census#jdk-updates
> [3] https://openjdk.java.net/bylaws#three-vote-consensus
> 

From christoph.langer at sap.com  Tue Jul 23 20:55:03 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 23 Jul 2019 20:55:03 +0000
Subject: [11u] 8219513:
 compiler/codegen/aes/TestCipherBlockChainingEncrypt.java timeout on
 Solaris-sparc
In-Reply-To: <2b3372ec-543a-59c5-4b67-d10c6a06821b@oracle.com>
References: <AM6PR02MB5192C79A7A643EC2935926F28AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <2b3372ec-543a-59c5-4b67-d10c6a06821b@oracle.com>
Message-ID: <AM6PR02MB519208D16C3D9A95B2B908878AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>

Thank you, Vladimir.

> -----Original Message-----
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Sent: Dienstag, 23. Juli 2019 18:01
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: [11u] 8219513:
> compiler/codegen/aes/TestCipherBlockChainingEncrypt.java timeout on
> Solaris-sparc
>
> Good.
>
> Thanks,
> Vladimir
>
> On 7/23/19 8:20 AM, Langer, Christoph wrote:
> > Hi,
> >
> > test cleanup time... please review another testfix backport.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8219513
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219513.11u-
> dev.0/
> > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/8c82412da698
> >
> > The patch did not apply cleanly, unfortunately, because
> jtreg.SkippedException is not yet available in 11u. But other than that it
> applies and seems to quiesce the test.
> >
> > Thanks
> > Christoph
> >

From christoph.langer at sap.com  Tue Jul 23 20:56:02 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 23 Jul 2019 20:56:02 +0000
Subject: [11u] 8219513:
 compiler/codegen/aes/TestCipherBlockChainingEncrypt.java timeout on
 Solaris-sparc
In-Reply-To: <103de0f469ca8ffe07988d887b6e3563f22e3d8a.camel@redhat.com>
References: <AM6PR02MB5192C79A7A643EC2935926F28AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <103de0f469ca8ffe07988d887b6e3563f22e3d8a.camel@redhat.com>
Message-ID: <AM6PR02MB5192A3FC7795703663D84E208AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Severin,

> On Tue, 2019-07-23 at 15:20 +0000, Langer, Christoph wrote:
> > Hi,
> >
> > test cleanup time... please review another testfix backport.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8219513
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219513.11u-
> dev.0/
> > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/8c82412da698
> >
> > The patch did not apply cleanly, unfortunately, because
> jtreg.SkippedException is not yet available in 11u. But other than that it
> applies and seems to quiesce the test.
>
> This looks reasonable.

Thanks for the review.

> Those jtreg.SkippedException changes pop up a lot when backporting test
> fixes/improvements which make me wonder whether we should add a
> jtreg.SkippedException in the JDK 11u test tree for one backport and
> then have subsequent backports apply as-is. That requires a minimum
> version of jtreg, though.
>
> Thoughts?

Yeah, sounds like a good idea. For my part, we always try to use the latest jtreg version - so it should be fine.

Best regards
Christoph


From christoph.langer at sap.com  Tue Jul 23 20:58:02 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 23 Jul 2019 20:58:02 +0000
Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
In-Reply-To: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
Message-ID: <AM6PR02MB51921A65AD2441B0EA3CF1DA8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>

Vote: yes

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew John Hughes
> Sent: Dienstag, 23. Juli 2019 22:01
> To: 'jdk-updates-dev at openjdk.java.net' <jdk-updates-
> dev at openjdk.java.net>
> Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
>
> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.
>
> Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not
> to have him doing similar work for 11u. He does also have a sizeable
> number of OpenJDK commits, particularly in the AWT and graphics area [1].
>
> Votes are due by 20h00 UTC on the 6th of August, 2019.
>
> Only current OpenJDK Updates Reviewers [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> [0] https://openjdk.java.net/census#neugens
> [1]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-
> dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40re
> dhat.com%22))+and+not+merge()
> [2] https://openjdk.java.net/census#jdk-updates
> [3] https://openjdk.java.net/bylaws#three-vote-consensus
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew


From christoph.langer at sap.com  Tue Jul 23 20:58:02 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 23 Jul 2019 20:58:02 +0000
Subject: CFV: New OpenJDK Updates Committer: Martin Balao
In-Reply-To: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
References: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
Message-ID: <AM6PR02MB5192730D5C2851F1E62093DA8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>

Vote: yes

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew John Hughes
> Sent: Dienstag, 23. Juli 2019 21:52
> To: 'jdk-updates-dev at openjdk.java.net' <jdk-updates-
> dev at openjdk.java.net>
> Subject: CFV: New OpenJDK Updates Committer: Martin Balao
>
> I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
> Updates Committer.
>
> Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it
> makes little sense for him not to be a committer for the updates
> project. He has already had a number of changes pushed to the 11u
> repositories by others. [0]
>
> Votes are due by 20h00 UTC on the 6th of August, 2019.
>
> Only current OpenJDK Updates Committers [1] are eligible to vote on
> this nomination.
>
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> [0]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-
> dev/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redha
> t.com%22))+and+not+merge()
> [1] https://openjdk.java.net/census#jdk-updates
> [2] http://openjdk.java.net/projects/#committer-vote
> --
> 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 Sergey.Bylokhov at oracle.com  Tue Jul 23 21:10:45 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 23 Jul 2019 14:10:45 -0700
Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
In-Reply-To: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
Message-ID: <43ec5748-219c-358a-57b9-83bda4230fff@oracle.com>

Vote: yes

On 23.07.2019 13:00, Andrew John Hughes wrote:
> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.
> 
> Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not
> to have him doing similar work for 11u. He does also have a sizeable
> number of OpenJDK commits, particularly in the AWT and graphics area [1].
> 
> Votes are due by 20h00 UTC on the 6th of August, 2019.
> 
> Only current OpenJDK Updates Reviewers [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
> 
> For Three-Vote Consensus voting instructions, see [3].
> 
> [0] https://openjdk.java.net/census#neugens
> [1]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
> [2] https://openjdk.java.net/census#jdk-updates
> [3] https://openjdk.java.net/bylaws#three-vote-consensus
> 


-- 
Best regards, Sergey.

From shade at redhat.com  Wed Jul 24 08:30:30 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 24 Jul 2019 10:30:30 +0200
Subject: CFV: New OpenJDK Updates Committer: Martin Balao
In-Reply-To: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
References: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
Message-ID: <82d82ef0-1ad7-619f-302a-e67456a51711@redhat.com>

Vote: yes

On 7/23/19 9:51 PM, Andrew John Hughes wrote:
> I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
> Updates Committer.
-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jul 24 08:30:53 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 24 Jul 2019 10:30:53 +0200
Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
In-Reply-To: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
Message-ID: <4c6a4670-238f-0b9a-e709-14f79cf4b873@redhat.com>

Vote: yes

On 7/23/19 10:00 PM, Andrew John Hughes wrote:
> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.

-- 
Thanks,
-Aleksey


From sgehwolf at redhat.com  Wed Jul 24 08:33:40 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 24 Jul 2019 10:33:40 +0200
Subject: CFV: New OpenJDK Updates Committer: Martin Balao
In-Reply-To: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
References: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
Message-ID: <eab009cd95973e5baef1914468c639b473deca32.camel@redhat.com>

Vote: yes

On Tue, 2019-07-23 at 20:51 +0100, Andrew John Hughes wrote:
> I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
> Updates Committer.
> 
> Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it
> makes little sense for him not to be a committer for the updates
> project. He has already had a number of changes pushed to the 11u
> repositories by others. [0]
> 
> Votes are due by 20h00 UTC on the 6th of August, 2019.
> 
> Only current OpenJDK Updates Committers [1] are eligible to vote on
> this nomination.
> 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> [0]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] https://openjdk.java.net/census#jdk-updates
> [2] http://openjdk.java.net/projects/#committer-vote


From goetz.lindenmaier at sap.com  Wed Jul 24 08:55:59 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 24 Jul 2019 08:55:59 +0000
Subject: CFV: New OpenJDK Updates Committer: Martin Balao
In-Reply-To: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
References: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
Message-ID: <AM6PR02MB5347665077D0DF9038CA0E71ECC60@AM6PR02MB5347.eurprd02.prod.outlook.com>

vote: yes

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew John Hughes
> Sent: Dienstag, 23. Juli 2019 21:52
> To: 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net>
> Subject: CFV: New OpenJDK Updates Committer: Martin Balao
> 
> I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
> Updates Committer.
> 
> Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it
> makes little sense for him not to be a committer for the updates
> project. He has already had a number of changes pushed to the 11u
> repositories by others. [0]
> 
> Votes are due by 20h00 UTC on the 6th of August, 2019.
> 
> Only current OpenJDK Updates Committers [1] are eligible to vote on
> this nomination.
> 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> [0]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-
> dev/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.c
> om%22))+and+not+merge()
> [1] https://openjdk.java.net/census#jdk-updates
> [2] http://openjdk.java.net/projects/#committer-vote
> --
> 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 volker.simonis at gmail.com  Wed Jul 24 09:19:19 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 24 Jul 2019 11:19:19 +0200
Subject: CFV: New OpenJDK Updates Committer: Martin Balao
In-Reply-To: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
References: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
Message-ID: <CA+3eh12yTBWqYh0ddHxoh8ZRJVA3KdftbwuPS1y_HMpfwSgM0A@mail.gmail.com>

Vote: yes

Andrew John Hughes <gnu.andrew at redhat.com> schrieb am Di., 23. Juli 2019,
21:52:

> I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
> Updates Committer.
>
> Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it
> makes little sense for him not to be a committer for the updates
> project. He has already had a number of changes pushed to the 11u
> repositories by others. [0]
>
> Votes are due by 20h00 UTC on the 6th of August, 2019.
>
> Only current OpenJDK Updates Committers [1] are eligible to vote on
> this nomination.
>
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> [0]
>
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] https://openjdk.java.net/census#jdk-updates
> [2] http://openjdk.java.net/projects/#committer-vote
> --
> 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 volker.simonis at gmail.com  Wed Jul 24 09:20:17 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 24 Jul 2019 11:20:17 +0200
Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
In-Reply-To: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
Message-ID: <CA+3eh10ad0isDAvYNHpqBy0QTffo3usQ06MgaoHJzh1iRvT3tw@mail.gmail.com>

Vote: yes

Andrew John Hughes <gnu.andrew at redhat.com> schrieb am Di., 23. Juli 2019,
22:01:

> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.
>
> Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not
> to have him doing similar work for 11u. He does also have a sizeable
> number of OpenJDK commits, particularly in the AWT and graphics area [1].
>
> Votes are due by 20h00 UTC on the 6th of August, 2019.
>
> Only current OpenJDK Updates Reviewers [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> [0] https://openjdk.java.net/census#neugens
> [1]
>
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
> [2] https://openjdk.java.net/census#jdk-updates
> [3] https://openjdk.java.net/bylaws#three-vote-consensus
> --
> 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 zgu at redhat.com  Wed Jul 24 11:15:53 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 24 Jul 2019 07:15:53 -0400
Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
In-Reply-To: <CA+3eh10ad0isDAvYNHpqBy0QTffo3usQ06MgaoHJzh1iRvT3tw@mail.gmail.com>
References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
 <CA+3eh10ad0isDAvYNHpqBy0QTffo3usQ06MgaoHJzh1iRvT3tw@mail.gmail.com>
Message-ID: <cb30eca3-8002-0152-b5cc-ddfeca4a5060@redhat.com>

Vote: yes

-Zhengyu

On 7/24/19 5:20 AM, Volker Simonis wrote:
> Vote: yes
> 
> Andrew John Hughes <gnu.andrew at redhat.com> schrieb am Di., 23. Juli 2019,
> 22:01:
> 
>> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.
>>
>> Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not
>> to have him doing similar work for 11u. He does also have a sizeable
>> number of OpenJDK commits, particularly in the AWT and graphics area [1].
>>
>> Votes are due by 20h00 UTC on the 6th of August, 2019.
>>
>> Only current OpenJDK Updates Reviewers [2] are eligible to vote on this
>> nomination. Votes must be cast in the open by replying to this mailing
>> list.
>>
>> For Three-Vote Consensus voting instructions, see [3].
>>
>> [0] https://openjdk.java.net/census#neugens
>> [1]
>>
>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
>> [2] https://openjdk.java.net/census#jdk-updates
>> [3] https://openjdk.java.net/bylaws#three-vote-consensus
>> --
>> 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  Wed Jul 24 12:52:48 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 24 Jul 2019 12:52:48 +0000
Subject: [11u]: 8221408: Windows 32bit build build errors/warnings in hotspot
Message-ID: <AM6PR02MB53478E862AAEC8FA21ACB716ECC60@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi

I would like to downport this change as it fixes warnings
of the windows 32 bit build with VS 2017.
I had to change the syntax of the pragma disabling
the warning in os_windows_x86.cpp, because the macros
used in jdk13 are not available in jdk11. Thus I need a review.
The rest applied cleanly.

http://cr.openjdk.java.net/~goetz/wr19/8221408-ntintel_warnings-jdk11/01/

1.       I assume I need to downport
2.       https://bugs.openjdk.java.net/browse/JDK-8221725<https://bugs.openjdk.java.net/browse/JDK-8221725>: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot), too.
3.       It's a simple cast and applies cleanly.

Best regards,
  Goetz.

From bourges.laurent at gmail.com  Wed Jul 24 13:06:47 2019
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 24 Jul 2019 15:06:47 +0200
Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
In-Reply-To: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
Message-ID: <CAKjRUT4g0xNu1jih5kApFeAa58MO=_tYUtDCG5BD0WTTiWHWhg@mail.gmail.com>

Vote: yes

Le mar. 23 juil. 2019 ? 22:01, Andrew John Hughes <gnu.andrew at redhat.com> a
?crit :

> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.
>
> Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not
> to have him doing similar work for 11u. He does also have a sizeable
> number of OpenJDK commits, particularly in the AWT and graphics area [1].
>
> Votes are due by 20h00 UTC on the 6th of August, 2019.
>
> Only current OpenJDK Updates Reviewers [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> [0] https://openjdk.java.net/census#neugens
> [1]
>
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
> [2] https://openjdk.java.net/census#jdk-updates
> [3] https://openjdk.java.net/bylaws#three-vote-consensus
> --
> 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
>
>

-- 
-- 
Laurent Bourg?s

From martin.doerr at sap.com  Wed Jul 24 14:33:43 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 24 Jul 2019 14:33:43 +0000
Subject: [11u]: 8221408: Windows 32bit build build errors/warnings in
 hotspot
In-Reply-To: <AM6PR02MB53478E862AAEC8FA21ACB716ECC60@AM6PR02MB5347.eurprd02.prod.outlook.com>
References: <AM6PR02MB53478E862AAEC8FA21ACB716ECC60@AM6PR02MB5347.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4788C1E0B09316D66C5019B69AC60@AM6PR02MB4788.eurprd02.prod.outlook.com>

Hi G?tz,

this looks good.

Thanks,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Mittwoch, 24. Juli 2019 14:53
> To: 'jdk-updates-dev at openjdk.java.net' <jdk-updates-
> dev at openjdk.java.net>
> Subject: [11u]: 8221408: Windows 32bit build build
> errors/warnings in hotspot
> 
> Hi
> 
> I would like to downport this change as it fixes warnings
> of the windows 32 bit build with VS 2017.
> I had to change the syntax of the pragma disabling
> the warning in os_windows_x86.cpp, because the macros
> used in jdk13 are not available in jdk11. Thus I need a review.
> The rest applied cleanly.
> 
> http://cr.openjdk.java.net/~goetz/wr19/8221408-ntintel_warnings-
> jdk11/01/
> 
> 1.       I assume I need to downport
> 2.       https://bugs.openjdk.java.net/browse/JDK-
> 8221725<https://bugs.openjdk.java.net/browse/JDK-8221725>: AArch64
> build failures after JDK-8221408 (Windows 32bit build build errors/warnings in
> hotspot), too.
> 3.       It's a simple cast and applies cleanly.
> 
> Best regards,
>   Goetz.

From mbalao at redhat.com  Wed Jul 24 18:25:25 2019
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 24 Jul 2019 15:25:25 -0300
Subject: [11u] RFR: 8223482: Unsupported ciphersuites may be offered by a
 TLS client
In-Reply-To: <eeb124a4-f983-64bb-29eb-863b6b153beb@redhat.com>
References: <778861d5-cc04-ee7a-4bb8-eaba161adda0@redhat.com>
 <eeb124a4-f983-64bb-29eb-863b6b153beb@redhat.com>
Message-ID: <ef418aa2-cc2c-8a70-f561-e6240d4e25a3@redhat.com>

Hi Andrew,

On 7/23/19 4:35 PM, Andrew John Hughes wrote:
> 
> The changes mentioned look ok to me.
> 
> I am curious as to why the copyright headers are being altered,
> especially for
> src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java which
> is otherwise identical to the JDK version.
> 

Thanks for your review.

I've decided to bump copyright dates because of the changes introduced,
but reverted them (and added you as a reviewer) in
http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.jdk11u.webrev.01/

Can someone push on my behalf?

Thanks,
Martin.-

From shade at redhat.com  Wed Jul 24 19:26:24 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 24 Jul 2019 21:26:24 +0200
Subject: [11u] RFR: 8223482: Unsupported ciphersuites may be offered by a
 TLS client
In-Reply-To: <ef418aa2-cc2c-8a70-f561-e6240d4e25a3@redhat.com>
References: <778861d5-cc04-ee7a-4bb8-eaba161adda0@redhat.com>
 <eeb124a4-f983-64bb-29eb-863b6b153beb@redhat.com>
 <ef418aa2-cc2c-8a70-f561-e6240d4e25a3@redhat.com>
Message-ID: <ce75715e-7085-ab40-1c95-ff5a7d0b4357@redhat.com>

On 7/24/19 8:25 PM, Martin Balao wrote:
> I've decided to bump copyright dates because of the changes introduced,
> but reverted them (and added you as a reviewer) in
> http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.jdk11u.webrev.01/
> 
> Can someone push on my behalf?

I am going to do it.

-Aleksey


From shade at redhat.com  Wed Jul 24 19:53:13 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 24 Jul 2019 21:53:13 +0200
Subject: [11u] RFR: 8223482: Unsupported ciphersuites may be offered by a
 TLS client
In-Reply-To: <ce75715e-7085-ab40-1c95-ff5a7d0b4357@redhat.com>
References: <778861d5-cc04-ee7a-4bb8-eaba161adda0@redhat.com>
 <eeb124a4-f983-64bb-29eb-863b6b153beb@redhat.com>
 <ef418aa2-cc2c-8a70-f561-e6240d4e25a3@redhat.com>
 <ce75715e-7085-ab40-1c95-ff5a7d0b4357@redhat.com>
Message-ID: <4ae90810-d278-3187-67ad-f93432691770@redhat.com>

On 7/24/19 9:26 PM, Aleksey Shipilev wrote:
> On 7/24/19 8:25 PM, Martin Balao wrote:
>> I've decided to bump copyright dates because of the changes introduced,
>> but reverted them (and added you as a reviewer) in
>> http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.jdk11u.webrev.01/
>>
>> Can someone push on my behalf?
> 
> I am going to do it.

There:
  https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/3ba9c532128b

-- 
Thanks,
-Aleksey


From adinn at redhat.com  Thu Jul 25 15:11:18 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 25 Jul 2019 16:11:18 +0100
Subject: CFV: New OpenJDK Updates Committer: Martin Balao
In-Reply-To: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
References: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
Message-ID: <c6f7f384-b0f7-93ab-b4e1-83bf20ba916b@redhat.com>

Vote: yes

On 23/07/2019 20:51, Andrew John Hughes wrote:
> I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
> Updates Committer.
> 
> Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it
> makes little sense for him not to be a committer for the updates
> project. He has already had a number of changes pushed to the 11u
> repositories by others. [0]
> 
> Votes are due by 20h00 UTC on the 6th of August, 2019.
> 
> Only current OpenJDK Updates Committers [1] are eligible to vote on
> this nomination.
> 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> [0]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] https://openjdk.java.net/census#jdk-updates
> [2] http://openjdk.java.net/projects/#committer-vote
> 

-- 
regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From vicente.romero at oracle.com  Thu Jul 25 16:16:03 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 25 Jul 2019 12:16:03 -0400
Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
In-Reply-To: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
Message-ID: <b6a03c88-0b62-9506-9b86-0ea83a1e31d0@oracle.com>

vote: yes

Vicente

On 7/23/19 4:00 PM, Andrew John Hughes wrote:
> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.
>
> Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not
> to have him doing similar work for 11u. He does also have a sizeable
> number of OpenJDK commits, particularly in the AWT and graphics area [1].
>
> Votes are due by 20h00 UTC on the 6th of August, 2019.
>
> Only current OpenJDK Updates Reviewers [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> [0] https://openjdk.java.net/census#neugens
> [1]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
> [2] https://openjdk.java.net/census#jdk-updates
> [3] https://openjdk.java.net/bylaws#three-vote-consensus


From jianglizhou at google.com  Thu Jul 25 19:01:13 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 25 Jul 2019 12:01:13 -0700
Subject: CFV: New OpenJDK Updates Committer: Martin Balao
In-Reply-To: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
References: <cfbcbe07-4622-0833-bb6a-21bcbcfb4c7a@redhat.com>
Message-ID: <CALrW1jzgV=B7GdkWru8kX5aczaWkRH7eX6YpCcHjF4K_VvNXsw@mail.gmail.com>

Vote: yes

Best Regards,
Jiangli

On Tue, Jul 23, 2019 at 12:52 PM Andrew John Hughes
<gnu.andrew at redhat.com> wrote:
>
> I hereby nominate Martin Balao (mbalao) for the role of OpenJDK
> Updates Committer.
>
> Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it
> makes little sense for him not to be a committer for the updates
> project. He has already had a number of changes pushed to the 11u
> repositories by others. [0]
>
> Votes are due by 20h00 UTC on the 6th of August, 2019.
>
> Only current OpenJDK Updates Committers [1] are eligible to vote on
> this nomination.
>
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> [0]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] https://openjdk.java.net/census#jdk-updates
> [2] http://openjdk.java.net/projects/#committer-vote
> --
> 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 jianglizhou at google.com  Thu Jul 25 19:03:04 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 25 Jul 2019 12:03:04 -0700
Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre
In-Reply-To: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com>
Message-ID: <CALrW1jwUeN1+JczfcEXqA6NqLLMBRMeZUF2pcbkBxCDevzFJ=g@mail.gmail.com>

Vote: yes

Best Regards,
Jiangli

On Tue, Jul 23, 2019 at 1:01 PM Andrew John Hughes
<gnu.andrew at redhat.com> wrote:
>
> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.
>
> Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not
> to have him doing similar work for 11u. He does also have a sizeable
> number of OpenJDK commits, particularly in the AWT and graphics area [1].
>
> Votes are due by 20h00 UTC on the 6th of August, 2019.
>
> Only current OpenJDK Updates Reviewers [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> [0] https://openjdk.java.net/census#neugens
> [1]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
> [2] https://openjdk.java.net/census#jdk-updates
> [3] https://openjdk.java.net/bylaws#three-vote-consensus
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
>

From shade at redhat.com  Tue Jul 30 10:04:47 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 30 Jul 2019 12:04:47 +0200
Subject: jdk/jdk13 vs jdk-updates/jdk13u
Message-ID: <743062ac-4ef6-002e-f66a-0f854837f70d@redhat.com>

Hi,

I am looking at building the bleeding edge jdk13, and have a process question. My goal is to build
and test the bleeding edge jdk13 for me and users in my vicinity to test.

Right now, we have two repositories: jdk/jdk13 for stabilizing 13-ga, and jdk-updates/jdk13u
apparently for 13.0.2 (not 13.0.1!). You would think that jdk-updates/jdk13u contains all the latest
changes for 13, but it is not: it is latest tag is jdk-13+26, while jdk/jdk13 is already at jdk-13+31.

Is there a plan to have jdk/jdk13 -> jdk-updates/jdk13u merges regularly? That would make
jdk-updates/jdk13u the most bleeding edge.

Or do we have to wait for JDK 13 released and jdk/jdk13 cease to exist? That would force me to have
two different jdk13 binaries until that happens, which would be inconvenient.

-- 
Thanks,
-Aleksey


From stooke at redhat.com  Tue Jul 30 16:22:04 2019
From: stooke at redhat.com (Simon Tooke)
Date: Tue, 30 Jul 2019 12:22:04 -0400
Subject: RFC [11u]: backport of JDK-8215756: Memory leaks in the AWT on macOS
Message-ID: <dc75c7ea-5584-62e2-4722-f09a4b50b352@redhat.com>

Hello all,

I would like to backport the following bug into jdk11u-dev:

The patch is trivial, and applies as-is.  I have supplied a patch, but the original patch works as-is.

bug: https://bugs.openjdk.java.net/browse/JDK-8215756

jdk11u patch:? http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk11
<http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk8u/>

Original patch: http://hg.openjdk.java.net/jdk/client/rev/64e7a73195c1

Thanks for your time,

-Simon

---
Simon Tooke
Principle Software Engineer,
Red Hat Canada?? <https://www.redhat.com>

From shade at redhat.com  Tue Jul 30 16:25:14 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 30 Jul 2019 18:25:14 +0200
Subject: RFC [11u]: backport of JDK-8215756: Memory leaks in the AWT on
 macOS
In-Reply-To: <dc75c7ea-5584-62e2-4722-f09a4b50b352@redhat.com>
References: <dc75c7ea-5584-62e2-4722-f09a4b50b352@redhat.com>
Message-ID: <0a107607-8306-70af-624c-29e06a330e77@redhat.com>

On 7/30/19 6:22 PM, Simon Tooke wrote:
> jdk11u patch:? http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk11
> <http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk8u/>
> 
> Original patch: http://hg.openjdk.java.net/jdk/client/rev/64e7a73195c1

If the patch applies cleanly, you don't need RFC/RFR. See here, "5. If the original patch was
modified, get the change reviewed":
https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix. Just add the
jdk11u-fix-request + "Fix Request" comment, and let 11u maintainer decide from there.

-- 
Thanks,
-Aleksey


From sean.coffey at oracle.com  Tue Jul 30 16:37:37 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 30 Jul 2019 17:37:37 +0100
Subject: jdk/jdk13 vs jdk-updates/jdk13u
In-Reply-To: <743062ac-4ef6-002e-f66a-0f854837f70d@redhat.com>
References: <743062ac-4ef6-002e-f66a-0f854837f70d@redhat.com>
Message-ID: <225de205-2872-5ce4-3822-dba475a8359a@oracle.com>

Seems like a sync that should be more regular.

I'll sync up jdk13 to jdk13u now. Will push changes once build & testing 
is green.
Rob can discuss code sync frequency topic when he's back in the office.

regards,
Sean.

On 30/07/2019 11:04, Aleksey Shipilev wrote:
> Hi,
>
> I am looking at building the bleeding edge jdk13, and have a process question. My goal is to build
> and test the bleeding edge jdk13 for me and users in my vicinity to test.
>
> Right now, we have two repositories: jdk/jdk13 for stabilizing 13-ga, and jdk-updates/jdk13u
> apparently for 13.0.2 (not 13.0.1!). You would think that jdk-updates/jdk13u contains all the latest
> changes for 13, but it is not: it is latest tag is jdk-13+26, while jdk/jdk13 is already at jdk-13+31.
>
> Is there a plan to have jdk/jdk13 -> jdk-updates/jdk13u merges regularly? That would make
> jdk-updates/jdk13u the most bleeding edge.
>
> Or do we have to wait for JDK 13 released and jdk/jdk13 cease to exist? That would force me to have
> two different jdk13 binaries until that happens, which would be inconvenient.
>

From shade at redhat.com  Tue Jul 30 16:51:36 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 30 Jul 2019 18:51:36 +0200
Subject: jdk/jdk13 vs jdk-updates/jdk13u
In-Reply-To: <225de205-2872-5ce4-3822-dba475a8359a@oracle.com>
References: <743062ac-4ef6-002e-f66a-0f854837f70d@redhat.com>
 <225de205-2872-5ce4-3822-dba475a8359a@oracle.com>
Message-ID: <749e495d-55f7-b363-466d-6473ff512f4a@redhat.com>

On 7/30/19 6:37 PM, Se?n Coffey wrote:
> Seems like a sync that should be more regular.

Yup, syncing jdk/jdk13 -> jdk-updates/jdk13u when the regular jdk/jdk13 -> jdk/jdk sync happens
would be nice.

> I'll sync up jdk13 to jdk13u now. Will push changes once build & testing is green.
> Rob can discuss code sync frequency topic when he's back in the office.

Thank you.

-- 
-Aleksey


From martijnverburg at gmail.com  Tue Jul 30 17:12:19 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 30 Jul 2019 18:12:19 +0100
Subject: What is 11-pool Fix Version sued for?
In-Reply-To: <AM6PR02MB5192685F658291D53E8EE0128AC40@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <CAP7YuATa_o-NBu9t-j3Rv2F1cidqGH8GrJ5AguAYtDMb8S4mgA@mail.gmail.com>
 <AM6PR02MB5192AE7042DA23C1F71981688ACA0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <CAP7YuARV40rXaG-8HsZGm2ADtNFboV5xNT2QGm4C691_SuBLag@mail.gmail.com>
 <AM6PR02MB5192685F658291D53E8EE0128AC40@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <CAP7YuAQyVUNhkYPwAwJbu6tpzq6s-QHScCk4Jm0nci5nAc48MQ@mail.gmail.com>

Thanks duly noted.

Cheers,
Martijn


On Mon, 22 Jul 2019 at 07:34, Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Martijn,
>
>
>
> I would check whether there?s an assignee and if there?s one contact
> him/her or, if unassigned, start work on the issue and post to the
> appropriate lists. Sometimes (probably mostly) the 11-pool requests are
> actively worked on but sometimes they also tend to get forgotten.
>
>
>
> /Christoph
>
>
>
>
>
> *From:* Martijn Verburg <martijnverburg at gmail.com>
> *Sent:* Samstag, 20. Juli 2019 12:04
> *To:* Langer, Christoph <christoph.langer at sap.com>
> *Cc:* jdk-updates-dev at openjdk.java.net
> *Subject:* Re: What is 11-pool Fix Version sued for?
>
>
>
> Thanks, Christoph,
>
>
>
> When you say planned does that mean an engineer from . an org has already
> grabbed it to backport or should I/we just look at the assigned field and
> assuming it's empty, post here if we want to try and tackle it?
>
>
> Cheers,
> Martijn
>
>
>
>
>
> On Sat, 20 Jul 2019 at 07:49, Langer, Christoph <christoph.langer at sap.com>
> wrote:
>
> Hi Martijn,
>
> 11-pool more or less shows, that a fix or backport of some issue to 11 is
> planned. When the actual fix is pushed, 11-pool will be replaced with the
> target release version (e.g. 11.0.5 or such). It if for instance needed, if
> a backport involves a CSR - so one can attach the CSR to the 11-pool issue
> before actually committing a fix.
>
> HTH
> Christoph
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Martijn Verburg
> > Sent: Freitag, 19. Juli 2019 21:28
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: What is 11-pool Fix Version sued for?
> >
> > Hi all,
> >
> > Would I be correct in thinking that `11-pool` contains a host of suitable
> > issues that are available to be picked up by anyone to submit a patch
> for?
> >
> > JBS search for a reference:
> >
> > https://bugs.openjdk.java.net/browse/JDK-
> > 8227650?jql=project%20%3D%20JDK%20AND%20fixVersion%20%3D%2011-
> > pool
> >
> > Cheers,
> > Martijn
>
>

From christoph.langer at sap.com  Tue Jul 30 19:18:44 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 30 Jul 2019 19:18:44 +0000
Subject: jdk/jdk13 vs jdk-updates/jdk13u
In-Reply-To: <749e495d-55f7-b363-466d-6473ff512f4a@redhat.com>
References: <743062ac-4ef6-002e-f66a-0f854837f70d@redhat.com>
 <225de205-2872-5ce4-3822-dba475a8359a@oracle.com>
 <749e495d-55f7-b363-466d-6473ff512f4a@redhat.com>
Message-ID: <AM6PR02MB51928F11368259B48A386E588ADC0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

thanks Se?n for doing the sync. I was also wondering why jdk13u was so much behind.

What I'm still wondering now is why jdk13u is already targeting 13.0.2? I mean, it's still quite some time to go for the October update and I thought it could still be targeting 13.0.1. At least I was under the impression that for the last update, 12.0.2, the jdk12u branch was open for pushes to 12.0.2 for a longer time. Maybe that's something Rob can answer as well when he's back.

Thanks
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Dienstag, 30. Juli 2019 09:52
> To: Se?n Coffey <sean.coffey at oracle.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: jdk/jdk13 vs jdk-updates/jdk13u
>
> On 7/30/19 6:37 PM, Se?n Coffey wrote:
> > Seems like a sync that should be more regular.
>
> Yup, syncing jdk/jdk13 -> jdk-updates/jdk13u when the regular jdk/jdk13 ->
> jdk/jdk sync happens
> would be nice.
>
> > I'll sync up jdk13 to jdk13u now. Will push changes once build & testing is
> green.
> > Rob can discuss code sync frequency topic when he's back in the office.
>
> Thank you.
>
> --
> -Aleksey


From stooke at redhat.com  Tue Jul 30 19:32:04 2019
From: stooke at redhat.com (Simon Tooke)
Date: Tue, 30 Jul 2019 15:32:04 -0400
Subject: RFC [11u]: backport of JDK-8215756: Memory leaks in the AWT on
 macOS
In-Reply-To: <0a107607-8306-70af-624c-29e06a330e77@redhat.com>
References: <dc75c7ea-5584-62e2-4722-f09a4b50b352@redhat.com>
 <0a107607-8306-70af-624c-29e06a330e77@redhat.com>
Message-ID: <aa6b4dd7-5f8f-fe9f-ff60-dd6c095a4a34@redhat.com>


On 7/30/2019 12:25 PM, Aleksey Shipilev wrote:
> On 7/30/19 6:22 PM, Simon Tooke wrote:
>> jdk11u patch:? http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk11
>> <http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk8u/>
>>
>> Original patch: http://hg.openjdk.java.net/jdk/client/rev/64e7a73195c1
> If the patch applies cleanly, you don't need RFC/RFR. See here, "5. If the original patch was
> modified, get the change reviewed":
> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix. Just add the
> jdk11u-fix-request + "Fix Request" comment, and let 11u maintainer decide from there.

I have done this (tag + comment) now, thanks for the reminder.

-simon




From christoph.langer at sap.com  Wed Jul 31 12:41:37 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 31 Jul 2019 12:41:37 +0000
Subject: [11u] 8205654: serviceability/dcmd/framework/HelpTest.java timed
 out
Message-ID: <AM6PR02MB5192D2286307FC9752DE98778ADF0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Ping...



From: Langer, Christoph
Sent: Dienstag, 23. Juli 2019 07:58
To: jdk-updates-dev at openjdk.java.net
Cc: OpenJDK Serviceability <serviceability-dev at openjdk.java.net>
Subject: [11u] 8205654: serviceability/dcmd/framework/HelpTest.java timed out



Hi,



please review the backport of "8205654: serviceability/dcmd/framework/HelpTest.java timed out" to OpenJDK 11u. We're seeing the mentioned test issue intermittently in our nightlies.



Bug: https://bugs.openjdk.java.net/browse/JDK-8205654

Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8205654.11u-dev.0/

Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/67537bbafd7f

Original review discussion: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/026883.html



The change improves the way how jcmd explores running Java processes on Linux. It'll then try to use the proc file system first to get the necessary information before trying to attach via the attach framework.



The original patch needs 2 modifications:

1. In src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java I had to add the fix of JDK-8218705. The bug is not visible unfortunately but it seems something was forgot in the original commit. The change for JDK-8218705 is: http://hg.openjdk.java.net/jdk/jdk/rev/50c1b0a0f1e8

2. In test/lib/jdk/test/lib/util/JarUtils.java I had to take over some upstream coding from jdk/jdk to provide the JarUtils support that is needed by the new testcase "TestProcessHelper".



Thanks

Christoph




From christoph.langer at sap.com  Wed Jul 31 13:20:16 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 31 Jul 2019 13:20:16 +0000
Subject: [11u] RFR: 8221710: [TESTBUG] more configurable parameters for
 docker testing
In-Reply-To: <735d2d022611a36899262ed77a608438a0765b3a.camel@redhat.com>
References: <735d2d022611a36899262ed77a608438a0765b3a.camel@redhat.com>
Message-ID: <AM6PR02MB51920D8A556820FF2E0E238A8ADF0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Looks good.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Severin Gehwolf
> Sent: Montag, 22. Juli 2019 08:10
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR: 8221710: [TESTBUG] more configurable parameters for
> docker testing
>
> Hi,
>
> Please review one additional docker tests backport. A pre-requisite for
> JDK-8224165 to bring down which helps verifying JDK-8220672. The JDK 13
> patch applies cleanly, but doesn't work without modifications pointed
> out below as JDK 11 doesn't have SkippedException (which is a rather
> large changeset to bring down)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8221710
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8221710/jdk11/01/webrev/
> original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/b354ffb03ae4
>
> Testing: Ran docker tests on Linux x86_64
>
> Thoughts?
>
> Thanks,
> Severin
>
> diff --git a/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java
> b/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java
> --- a/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java
> +++ b/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java
> @@ -38,7 +38,6 @@
>  import jdk.test.lib.Utils;
>  import jdk.test.lib.process.OutputAnalyzer;
>  import jdk.test.lib.process.ProcessTools;
> -import jtreg.SkippedException;
>
>
>  public class DockerTestUtils {
> @@ -92,7 +91,9 @@
>          if (isDockerEngineAvailable()) {
>              return true;
>          } else {
> -            throw new SkippedException("Docker engine is not available on this
> system");
> +            System.out.println("Docker engine is not available on this system");
> +            System.out.println("This test is SKIPPED");
> +            return false;
>          }
>      }
>
>


From christoph.langer at sap.com  Wed Jul 31 13:18:15 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 31 Jul 2019 13:18:15 +0000
Subject: [11u] RFR: 8220672: [TESTBUG] TestCPUSets should check that
 cpuset does not exceed available cores
In-Reply-To: <8a45565ffd1089bb7425817a1117b75f9e4d164f.camel@redhat.com>
References: <8a45565ffd1089bb7425817a1117b75f9e4d164f.camel@redhat.com>
Message-ID: <AM6PR02MB519292E8D6DDA54A970AABA18ADF0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Severin,

this looks good.

I think we really want to have the SkippedException in 11u ??

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Severin Gehwolf
> Sent: Montag, 22. Juli 2019 03:58
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR: 8220672: [TESTBUG] TestCPUSets should check that
> cpuset does not exceed available cores
>
> Hi,
>
> I'm working on getting better container testing experience in JDK 11u.
> One of the issues I'd like to backport is this one. Also, it's one of
> those cases which got backported in 11.0.5-oracle.
>
> The jdk/jdk changeset didn't apply cleanly since a)
> jtreg.SkippedException is being thrown in jdk/jdk, not available in JDK
> 11u b) TestCPUSets.java wasn't problem-listed in JDK 11u. Otherwise the
> patch is the same.
>
> I've not included the change for b) and opted for System.out.println()
> and return as a substitute for a).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220672
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8220672/jdk11/01/webrev/
> original-changeset: http://hg.openjdk.java.net/jdk/jdk/rev/a73fe240da4a
>
> Testing: Ran docker tests on Linux x86_64.
>
> Thoughts?
>
> Thanks,
> Severin


From christoph.langer at sap.com  Wed Jul 31 13:44:53 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 31 Jul 2019 13:44:53 +0000
Subject: RFR: 8226468: loadquery failed error message displayed
In-Reply-To: <OF0CE01E4A.48619CCD-ON80258440.003092C9-80258440.0030B62C@notes.na.collabserv.com>
References: <OF0CE01E4A.48619CCD-ON80258440.003092C9-80258440.0030B62C@notes.na.collabserv.com>
Message-ID: <AM6PR02MB51929DB14E40F2FFA131B3DD8ADF0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Steve,

I've pushed this clean backport to jdk11u and jdk13u. As JDK12 updates is obsolete, I'd rather not push it there anymore. What do you think?

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Steve Groeger
> Sent: Dienstag, 23. Juli 2019 01:52
> To: jdk-updates-dev at openjdk.java.net
> Subject: RFR: 8226468: loadquery failed error message displayed
>
> Hi Thomas,
>
> Thanks for handling this change for me.
> I have requested for the change to be back-ported to jdk11, jdk12 and
> jdk13.
> I am still awaiting the agreement to have it back-ported to jdk11, but it
> has been approved to be back-ported to jdk12 and jdk13.
> I would be grateful if you could make the changes to these jdk versions.
> Any issues 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
>
>
> "Thomas St?fe" <thomas.stuefe at gmail.com> wrote on 25/06/2019 14:17:19:
>
> > From: "Thomas St?fe" <thomas.stuefe at gmail.com>
> > To: Steve Groeger <GROEGES at uk.ibm.com>
> > Cc: "Baesken, Matthias" <matthias.baesken at sap.com>, ppc-aix-port-dev
> > <ppc-aix-port-dev at openjdk.java.net>
> > Date: 25/06/2019 14:17
> > Subject: Re: RFR: 8226468: loadquery failed error message displayed
> >
> > Hi Steve,
> >
> > looks good. Its fine, we do not need a realloc loop. Keep it simple
> stupid :)
> >
> > I can sponsor this for you.
> >
> > ..Thomas
> >
> > On Tue, Jun 25, 2019 at 2:57 PM Steve Groeger <GROEGES at uk.ibm.com>
> wrote:
> > Matthias / Thomas,
> >
> > Thanks for all your comments. I have created an issue [1] and also a
> > webrev [2] to resolve this issue.
> >
> > I have just doubled the size of the buffer (to 0x8000) in both
> > places you mentioned.
> > If we want to use the same method as used in loadlib_aix.cpp then I
> > can look at doing that.
> >
> > If I can get someone to sponsor this change and to also review the
> > webrev I would be very grateful.
> >
> > Once this has been approved and committed then I would probabamly
> > look at getting this back-ported to jdk13 and jdk11.
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8226468
> > [2] http://cr.openjdk.java.net/~sgroeger/8226468-1/webrev.00/
> >
> > 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
> >
> > "Baesken, Matthias" <matthias.baesken at sap.com> wrote on 25/06/2019
> 11:19:26:
> >
> > > From: "Baesken, Matthias" <matthias.baesken at sap.com>
> > > To: "Thomas St?fe" <thomas.stuefe at gmail.com>, Steve Groeger
> > > <GROEGES at uk.ibm.com>
> > > Cc: ppc-aix-port-dev <ppc-aix-port-dev at openjdk.java.net>
> > > Date: 25/06/2019 11:19
> > > Subject: RE: loadquery failed error message displayed
> > >
> > > Hi Steve, please create an issue + patch .
> > >
> > > Btw.  I wonder also about   the other  loadquery  usages :
> > >
> > >
> > > java_md_aix.c
> > >
> > > static unsigned char dladdr_buffer[0x4000];
> > >
> > > 33 return loadquery(L_GETINFO, dladdr_buffer, sizeof(dladdr_buffer));
> > >
> > >
> > > loadlib_aix.cpp
> > >
> > > 192 // Call loadquery(L_GETINFO..) to get a list of all loaded Dlls
> > > from AIX. loadquery
> > > 198 if (loadquery(L_GETINFO, buffer, buflen) == -1) {
> > >
> > >
> > >
> > > Maybe you  could also adjust the  buffer size in  java_md_aix.c  as
> well  ?
> > > (  The usage  in  loadlib_aix.cpp  uses a buffer reallocation  until
> > > the size is large enough.  )
> > >
> > > Increasing by factor of 2  is fine with me .  But maybe some people
> > > prefer what we do in  loadlib_aix.cpp (reallocation at runtime ).
> > >
> > >
> > >
> > >
> > > Best regards, Matthias
> > >
> > >
> > > From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net>
> > > On Behalf Of Thomas St?fe
> > > Sent: Mittwoch, 19. Juni 2019 19:21
> > > To: Steve Groeger <GROEGES at uk.ibm.com>
> > > Cc: ppc-aix-port-dev <ppc-aix-port-dev at openjdk.java.net>
> > > Subject: Re: loadquery failed error message displayed
> > >
> > > Hi Steve,
> > >
> > > I wrote this a very long time ago and we never ran into this
> > > problem, curious that it took so long... but of course, please
> > > create an issue and do a patch, thanks!
> > >
> > > I would probably just increase the buffer by factor 2 or 4.
> > >
> > > Cheers, Thomas
> > >
> > > On Wed, Jun 19, 2019, 14:19 Steve Groeger <GROEGES at uk.ibm.com>
> wrote:
> > > Hi all,
> > >
> > > We have a scenario where in a Java program after loading some shared
> > > libraries (using System.loadLibrary) and then calling
> > > javax.imageio.ImageIO.read(new File(..)) the java program displays
> > > the following error message:
> > >
> > > loadquery failed (12 Not enough space)
> > >
> > > This happens when running on AIX with Java 11 using this sample code:
> > >
> > > import java.io.File;
> > > import java.util.Map;
> > > import javax.imageio.ImageIO;
> > > public class Reproduce {
> > >    public static void main(String[] args) {
> > >        try {
> > >            System.loadLibrary("mylib");
> > >
> > >            String filePath = "...";
> > >            BufferedImage img = ImageIO.read(new File(filePath));
> > >
> > >        }
> > >        catch (Throwable e) {
> > >            System.out.println("Exception : " + e);
> > >            e.printStackTrace();
> > >        }
> > >    }
> > > }
> > >
> > > It seems that this is displayed from src/java.desktop/aix/native/
> > > libawt/porting_aix.c
> > >
> > > static unsigned char dladdr_buffer[0x4000];
> > >
> > > static void fill_dll_info(void) {
> > >  int rc = loadquery(L_GETINFO,dladdr_buffer, sizeof(dladdr_buffer));
> > >  if (rc == -1) {
> > >    fprintf(stderr, "loadquery failed (%d %s)", errno,
> strerror(errno));
> > >    fflush(stderr);
> > >  }
> > > }
> > >
> > > and is due to the dladdr_info buffer being too small to contain all
> > > the data returned from the loadquery function.
> > >
> > > The same buffer size is also used in src/java.base/aix/native/
> > > libjli/java_md_aix.c
> > >
> > > Could / Should the size of these buffers be increased to handle the
> > > large data and prevent the error message from being displayed.
> > > If so, I am happy to raise an issue and to generate a webrev for this.
>
> > > What would people suggest as a suitable size for the buffer, ie
> > > double the size (x8000) or something else?
> > >
> > > 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
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with
> > number 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU


From thomas.stuefe at gmail.com  Wed Jul 31 15:56:28 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 31 Jul 2019 17:56:28 +0200
Subject: [11u] RFR: 8227041: runtime/memory/RunUnitTestsConcurrently.java
 has a memory leak
In-Reply-To: <AM6PR02MB51926C7EE75A84679B00902F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB51926C7EE75A84679B00902F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUwN3AnMCKqAuz6RrDxtPjiVHZ9oTuHit6J2qE=VBhwfRA@mail.gmail.com>

Hi Christoph,

Assuming it builds and the tests run through, I am fine with this change.

Cheers, Thomas

On Tue, Jul 23, 2019 at 5:30 PM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi,
>
> please review backport of this test fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227041
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8227041.11u-dev.0/
>
> The test is a real resource drain and causes OOMs - while not really
> testing something useful. It was already removed in jdk/jdk - so requesting
> to remove it from JDK11u as well (to fix sporadic test failures).
>
> In jdk11 the relevant source files look a bit different, so I had to
> modify the original changeset a bit.
>
> Thanks
> Christoph
>
>

From shade at redhat.com  Wed Jul 31 16:16:39 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 31 Jul 2019 18:16:39 +0200
Subject: [11u] RFR: 8227041: runtime/memory/RunUnitTestsConcurrently.java
 has a memory leak
In-Reply-To: <AM6PR02MB51926C7EE75A84679B00902F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB51926C7EE75A84679B00902F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <30b6f4f4-1241-ef77-68a1-f4f5ec842179@redhat.com>

On 7/23/19 5:29 PM, Langer, Christoph wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227041
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8227041.11u-dev.0/

That looks good.

-- 
Thanks,
-Aleksey


From sgehwolf at redhat.com  Wed Jul 31 16:28:25 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 31 Jul 2019 18:28:25 +0200
Subject: [11u] jtreg.SkippedException?
Message-ID: <c664bdd52a31ae1ba4a041d2418b2f2f3189cd3c.camel@redhat.com>

Hi,

During a couple of test related backports to OpenJDK 11u a recurring
issue seems to be a need to change a jdk/jdk patch due to
jtreg.SkippedException not being present in jdk-updates/jdk11u{,-dev}.

I'd propose to get it added to the JDK 11u test trees so as to make
test backports easier going forward. While this might add a patch which
is JDK 11u only, it removes the need for reviews for more test
backports going forward.

Note that JDK-8208655 introduced jtreg.SkippedException for JDK 12,
which seems too big of a patch for a full backport. I could include
SkippedException in one of my pending JDK 11u backports[1][2] or get it
added separately. I'm leaning towards a separate JDK 11u-only patch.

Thoughts?

Thanks,
Severin

[1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001456.html
[2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001454.html


From serguei.spitsyn at oracle.com  Wed Jul 31 16:41:14 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 31 Jul 2019 09:41:14 -0700
Subject: [11u] 8205654: serviceability/dcmd/framework/HelpTest.java timed
 out
In-Reply-To: <AM6PR02MB51921687C268BAE4C923E39F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB51921687C268BAE4C923E39F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <d298adec-8e51-bede-5125-8004e36d9aca@oracle.com>

Hi Christoph,

It looks good to me.

It'd be nice if Daniil has time to look at it.

Thanks,
Serguei


On 7/23/19 07:58, Langer, Christoph wrote:
> Hi,
>
> please review the backport of "8205654: serviceability/dcmd/framework/HelpTest.java timed out" to OpenJDK 11u. We're seeing the mentioned test issue intermittently in our nightlies.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205654
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8205654.11u-dev.0/
> Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/67537bbafd7f
> Original review discussion: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/026883.html
>
> The change improves the way how jcmd explores running Java processes on Linux. It'll then try to use the proc file system first to get the necessary information before trying to attach via the attach framework.
>
> The original patch needs 2 modifications:
> 1. In src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java I had to add the fix of JDK-8218705. The bug is not visible unfortunately but it seems something was forgot in the original commit. The change for JDK-8218705 is: http://hg.openjdk.java.net/jdk/jdk/rev/50c1b0a0f1e8
> 2. In test/lib/jdk/test/lib/util/JarUtils.java I had to take over some upstream coding from jdk/jdk to provide the JarUtils support that is needed by the new testcase "TestProcessHelper".
>
> Thanks
> Christoph
>


From mikhailo.seledtsov at oracle.com  Wed Jul 31 16:43:32 2019
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Wed, 31 Jul 2019 09:43:32 -0700
Subject: [11u] jtreg.SkippedException?
In-Reply-To: <c664bdd52a31ae1ba4a041d2418b2f2f3189cd3c.camel@redhat.com>
References: <c664bdd52a31ae1ba4a041d2418b2f2f3189cd3c.camel@redhat.com>
Message-ID: <dbbd4062-846b-f00c-704c-291ca0c5e7f6@oracle.com>

Hi Severin,

 ? There might be a dependency on a specific version of Jtreg to support 
the jtreg.SkippedException.

Looping in Igor and Jon.


Thanks,

Misha

On 7/31/19 9:28 AM, Severin Gehwolf wrote:
> Hi,
>
> During a couple of test related backports to OpenJDK 11u a recurring
> issue seems to be a need to change a jdk/jdk patch due to
> jtreg.SkippedException not being present in jdk-updates/jdk11u{,-dev}.
>
> I'd propose to get it added to the JDK 11u test trees so as to make
> test backports easier going forward. While this might add a patch which
> is JDK 11u only, it removes the need for reviews for more test
> backports going forward.
>
> Note that JDK-8208655 introduced jtreg.SkippedException for JDK 12,
> which seems too big of a patch for a full backport. I could include
> SkippedException in one of my pending JDK 11u backports[1][2] or get it
> added separately. I'm leaning towards a separate JDK 11u-only patch.
>
> Thoughts?
>
> Thanks,
> Severin
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001456.html
> [2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001454.html
>

From jonathan.gibbons at oracle.com  Wed Jul 31 17:22:08 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 31 Jul 2019 10:22:08 -0700
Subject: [11u] jtreg.SkippedException?
In-Reply-To: <dbbd4062-846b-f00c-704c-291ca0c5e7f6@oracle.com>
References: <c664bdd52a31ae1ba4a041d2418b2f2f3189cd3c.camel@redhat.com>
 <dbbd4062-846b-f00c-704c-291ca0c5e7f6@oracle.com>
Message-ID: <b030856f-ed0c-6f3b-afe3-4559f6f02cd0@oracle.com>

Hi Misha, Severin, all,

When we added SkippedException we specifically designed it to avoid any 
dependencies on jtreg.

As far as jtreg is concerned, any class named "jtreg.SkippedException" 
will do. There is not even a requirement
that all tests should use the same definition of jtreg.SkippedException.

It should be sufficient to do the following:

1. Add a definition of jtreg.SkippedException in some test library, and 
use it in tests.
2. Update the requiredVersion for jtreg in TEST.ROOT to be a version 
that handles SkippedException.

Even 2 is somewhat optional, but if you don't do it, the test will just 
fail because of the SkippedException.

-- Jon


On 07/31/2019 09:43 AM, mikhailo.seledtsov at oracle.com wrote:
> Hi Severin,
>
> ? There might be a dependency on a specific version of Jtreg to 
> support the jtreg.SkippedException.
>
> Looping in Igor and Jon.
>
>
> Thanks,
>
> Misha
>
> On 7/31/19 9:28 AM, Severin Gehwolf wrote:
>> Hi,
>>
>> During a couple of test related backports to OpenJDK 11u a recurring
>> issue seems to be a need to change a jdk/jdk patch due to
>> jtreg.SkippedException not being present in jdk-updates/jdk11u{,-dev}.
>>
>> I'd propose to get it added to the JDK 11u test trees so as to make
>> test backports easier going forward. While this might add a patch which
>> is JDK 11u only, it removes the need for reviews for more test
>> backports going forward.
>>
>> Note that JDK-8208655 introduced jtreg.SkippedException for JDK 12,
>> which seems too big of a patch for a full backport. I could include
>> SkippedException in one of my pending JDK 11u backports[1][2] or get it
>> added separately. I'm leaning towards a separate JDK 11u-only patch.
>>
>> Thoughts?
>>
>> Thanks,
>> Severin
>>
>> [1] 
>> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001456.html
>> [2] 
>> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001454.html
>>


From jonathan.gibbons at oracle.com  Wed Jul 31 17:23:54 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 31 Jul 2019 10:23:54 -0700
Subject: [11u] jtreg.SkippedException?
In-Reply-To: <b030856f-ed0c-6f3b-afe3-4559f6f02cd0@oracle.com>
References: <c664bdd52a31ae1ba4a041d2418b2f2f3189cd3c.camel@redhat.com>
 <dbbd4062-846b-f00c-704c-291ca0c5e7f6@oracle.com>
 <b030856f-ed0c-6f3b-afe3-4559f6f02cd0@oracle.com>
Message-ID: <501b2c1e-8fe3-fe69-99dc-6cac96d5e7ac@oracle.com>

Also,

Note to self: I should make sure this is covered in the jtreg documentation.

-- Jon


On 07/31/2019 10:22 AM, Jonathan Gibbons wrote:
> Hi Misha, Severin, all,
>
> When we added SkippedException we specifically designed it to avoid 
> any dependencies on jtreg.
>
> As far as jtreg is concerned, any class named "jtreg.SkippedException" 
> will do. There is not even a requirement
> that all tests should use the same definition of jtreg.SkippedException.
>
> It should be sufficient to do the following:
>
> 1. Add a definition of jtreg.SkippedException in some test library, 
> and use it in tests.
> 2. Update the requiredVersion for jtreg in TEST.ROOT to be a version 
> that handles SkippedException.
>
> Even 2 is somewhat optional, but if you don't do it, the test will 
> just fail because of the SkippedException.
>
> -- Jon
>
>
> On 07/31/2019 09:43 AM, mikhailo.seledtsov at oracle.com wrote:
>> Hi Severin,
>>
>> ? There might be a dependency on a specific version of Jtreg to 
>> support the jtreg.SkippedException.
>>
>> Looping in Igor and Jon.
>>
>>
>> Thanks,
>>
>> Misha
>>
>> On 7/31/19 9:28 AM, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> During a couple of test related backports to OpenJDK 11u a recurring
>>> issue seems to be a need to change a jdk/jdk patch due to
>>> jtreg.SkippedException not being present in jdk-updates/jdk11u{,-dev}.
>>>
>>> I'd propose to get it added to the JDK 11u test trees so as to make
>>> test backports easier going forward. While this might add a patch which
>>> is JDK 11u only, it removes the need for reviews for more test
>>> backports going forward.
>>>
>>> Note that JDK-8208655 introduced jtreg.SkippedException for JDK 12,
>>> which seems too big of a patch for a full backport. I could include
>>> SkippedException in one of my pending JDK 11u backports[1][2] or get it
>>> added separately. I'm leaning towards a separate JDK 11u-only patch.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Severin
>>>
>>> [1] 
>>> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001456.html
>>> [2] 
>>> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001454.html
>>>
>


From mikhailo.seledtsov at oracle.com  Wed Jul 31 17:36:22 2019
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Wed, 31 Jul 2019 10:36:22 -0700
Subject: [11u] jtreg.SkippedException?
In-Reply-To: <b030856f-ed0c-6f3b-afe3-4559f6f02cd0@oracle.com>
References: <c664bdd52a31ae1ba4a041d2418b2f2f3189cd3c.camel@redhat.com>
 <dbbd4062-846b-f00c-704c-291ca0c5e7f6@oracle.com>
 <b030856f-ed0c-6f3b-afe3-4559f6f02cd0@oracle.com>
Message-ID: <f5cf3966-8f42-cb36-85a1-dacaaa724b96@oracle.com>

Jon,

Thank you for clarification,

Misha

On 7/31/19 10:22 AM, Jonathan Gibbons wrote:
> Hi Misha, Severin, all,
>
> When we added SkippedException we specifically designed it to avoid 
> any dependencies on jtreg.
>
> As far as jtreg is concerned, any class named "jtreg.SkippedException" 
> will do. There is not even a requirement
> that all tests should use the same definition of jtreg.SkippedException.
>
> It should be sufficient to do the following:
>
> 1. Add a definition of jtreg.SkippedException in some test library, 
> and use it in tests.
> 2. Update the requiredVersion for jtreg in TEST.ROOT to be a version 
> that handles SkippedException.
>
> Even 2 is somewhat optional, but if you don't do it, the test will 
> just fail because of the SkippedException.
>
> -- Jon
>
>
> On 07/31/2019 09:43 AM, mikhailo.seledtsov at oracle.com wrote:
>> Hi Severin,
>>
>> ? There might be a dependency on a specific version of Jtreg to 
>> support the jtreg.SkippedException.
>>
>> Looping in Igor and Jon.
>>
>>
>> Thanks,
>>
>> Misha
>>
>> On 7/31/19 9:28 AM, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> During a couple of test related backports to OpenJDK 11u a recurring
>>> issue seems to be a need to change a jdk/jdk patch due to
>>> jtreg.SkippedException not being present in jdk-updates/jdk11u{,-dev}.
>>>
>>> I'd propose to get it added to the JDK 11u test trees so as to make
>>> test backports easier going forward. While this might add a patch which
>>> is JDK 11u only, it removes the need for reviews for more test
>>> backports going forward.
>>>
>>> Note that JDK-8208655 introduced jtreg.SkippedException for JDK 12,
>>> which seems too big of a patch for a full backport. I could include
>>> SkippedException in one of my pending JDK 11u backports[1][2] or get it
>>> added separately. I'm leaning towards a separate JDK 11u-only patch.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Severin
>>>
>>> [1] 
>>> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001456.html
>>> [2] 
>>> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001454.html
>>>
>

From serguei.spitsyn at oracle.com  Wed Jul 31 17:42:49 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 31 Jul 2019 10:42:49 -0700
Subject: [11u] 8205654: serviceability/dcmd/framework/HelpTest.java timed
 out
In-Reply-To: <534514DB-A591-4DC9-AE45-2C8F2BE10186@oracle.com>
References: <AM6PR02MB51921687C268BAE4C923E39F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d298adec-8e51-bede-5125-8004e36d9aca@oracle.com>
 <534514DB-A591-4DC9-AE45-2C8F2BE10186@oracle.com>
Message-ID: <cb95788d-c438-3615-3091-6c53162b351b@oracle.com>



On 7/31/19 10:32 AM, Daniil Titov wrote:
> Hi Christoph,
>
> There were several issues that the original change introduced.  These issues were
>   solved in [1] and [2]  and they need to be included in the backport.

You probably wanted to say, the 8225543 and 8221730 have to be 
backported as well,
but not in the same backport.

Thanks,
Serguei

> [1]:  JDK-8225543 - https://bugs.openjdk.java.net/browse/JDK-8225543
> [2]:  JDK-8221730 - https://bugs.openjdk.java.net/browse/JDK-8221730
>
> Thanks,
> Daniil
>
> ?On 7/31/19, 9:41 AM, "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com> wrote:
>
>      
>      On 7/23/19 07:58, Langer, Christoph wrote:
>      > Hi,
>      >
>      > please review the backport of "8205654: serviceability/dcmd/framework/HelpTest.java timed out" to OpenJDK 11u. We're seeing the mentioned test issue intermittently in our nightlies.
>      >
>      > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654
>      > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8205654.11u-dev.0/
>      > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/67537bbafd7f
>      > Original review discussion: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/026883.html
>      >
>      > The change improves the way how jcmd explores running Java processes on Linux. It'll then try to use the proc file system first to get the necessary information before trying to attach via the attach framework.
>      >
>      > The original patch needs 2 modifications:
>      > 1. In src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java I had to add the fix of JDK-8218705. The bug is not visible unfortunately but it seems something was forgot in the original commit. The change for JDK-8218705 is: http://hg.openjdk.java.net/jdk/jdk/rev/50c1b0a0f1e8
>      > 2. In test/lib/jdk/test/lib/util/JarUtils.java I had to take over some upstream coding from jdk/jdk to provide the JarUtils support that is needed by the new testcase "TestProcessHelper".
>      >
>      > Thanks
>      > Christoph
>      >
>      
>      
>
>


From shade at redhat.com  Wed Jul 31 17:51:10 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 31 Jul 2019 19:51:10 +0200
Subject: [11u] RFR 8228400: Remove built-in AArch64 simulator
Message-ID: <5e246f51-4cb9-03a2-d4f2-bf0f7bf440f6@redhat.com>

Original change:
  https://bugs.openjdk.java.net/browse/JDK-8228400
  https://hg.openjdk.java.net/jdk/jdk/rev/01bca26734bb

This train goes all the way down to 8u-aarch64, this change is for 11u. This considerably shrinks
the aarch64 code, making it more maintainable. I'll let the original change stew in jdk/jdk a little
bit more, but we can start reviewing backports meanwhile. If there are follow-up issues from that
removal, we would address them as separate backports (as usual).

11u webrev:
  https://cr.openjdk.java.net/~shade/8228400/webrev.11u.01/

There are several differences:
  - no shenandoahBarrierSetAssembler.hpp; we would discover the blrt removal during downstream
Shenandoah merges (and build failures);
  - os_linux_aarch64.cpp is a bit different: has SPELL_REG_{SP,FP} and thus conflicts;
  - a few BUILTIN_SIM blocks removals were rejected due to context changes;

Testing: aarch64 tier1, tier2; eyeballing differences against jdk/jdk changeset

-- 
Thanks,
-Aleksey


From aph at redhat.com  Wed Jul 31 18:21:54 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 31 Jul 2019 11:21:54 -0700
Subject: [aarch64-port-dev ] [11u] RFR 8228400: Remove built-in AArch64
 simulator
In-Reply-To: <5e246f51-4cb9-03a2-d4f2-bf0f7bf440f6@redhat.com>
References: <5e246f51-4cb9-03a2-d4f2-bf0f7bf440f6@redhat.com>
Message-ID: <390b1088-6194-bcd8-a1c5-d8cf07a65fd8@redhat.com>

On 7/31/19 6:51 PM, Aleksey Shipilev wrote:
> Testing: aarch64 tier1, tier2; eyeballing differences against jdk/jdk changeset

No. I don't think that the removal of the built-in simulator should be
backported.  It doesn't win anything significant and it carries a
nonzero risk.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From shade at redhat.com  Wed Jul 31 18:32:38 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 31 Jul 2019 20:32:38 +0200
Subject: [aarch64-port-dev ] [11u] RFR 8228400: Remove built-in AArch64
 simulator
In-Reply-To: <390b1088-6194-bcd8-a1c5-d8cf07a65fd8@redhat.com>
References: <5e246f51-4cb9-03a2-d4f2-bf0f7bf440f6@redhat.com>
 <390b1088-6194-bcd8-a1c5-d8cf07a65fd8@redhat.com>
Message-ID: <741a213c-2745-d242-d2bb-367d28f04cd3@redhat.com>

On 7/31/19 8:21 PM, Andrew Haley wrote:
> On 7/31/19 6:51 PM, Aleksey Shipilev wrote:
>> Testing: aarch64 tier1, tier2; eyeballing differences against jdk/jdk changeset
> 
> No. I don't think that the removal of the built-in simulator should be
> backported.  

I thought we would remove it in 8u-aarch64, in preparation for eventual upstreaming. It that case,
it makes sense to have all releases share the same code shape to simplify future backporting.
Simulator is already removed in 14, and assuming we are doing it in 8u-aarch64, 11u would be the
only release left with the built-in simulator.

Removals in 11u and 8u-aarch64 were the plan all along:

"If not, should we remove it to reduce the codebase? It is present in all JDK releases, including 11
and 13. We could start there, and backport all the way down to 8u."
  https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-July/007688.html

"I am planning to backport it to 11u and 8u-aarch64 too."
  https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-July/007703.html

> It doesn't win anything significant and it carries a nonzero risk.

I would call removing this much effectively dead code rather significant win for maintainability:
  2350 lines changed: 45 ins; 2269 del; 36 mod; 50803 unchg

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Wed Jul 31 18:58:01 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 31 Jul 2019 14:58:01 -0400
Subject: [11u] RFR 8219370: NMT: Move synchronization primitives from
 mtInternal to mtSynchronizer
Message-ID: <7497e75f-1a16-6a0e-e756-5e9dab6f5acd@redhat.com>

Hi,

I would like to backport this patch to 11u.

This patch aggregated synchronization primitives under a new memory 
category, which improves NMT usability.

The patch does not apply cleanly, due to:
1) PlatformMonitors are no longer in 11u code base
2) JDK-8210246 changed how new memory category is defined, and it does 
not look like in 11u backport list.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8219370
Original webrev: http://cr.openjdk.java.net/~zgu/JDK-8219370/webrev.00/


11u Webrev: 
http://cr.openjdk.java.net/~zgu/JDK-8219370-11u/webrev.00/index.html

Test:
   hotspot_nmt (fastdebug and release) on Linux 86_64.

Thanks,

-Zhengyu

From serguei.spitsyn at oracle.com  Wed Jul 31 19:02:30 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 31 Jul 2019 12:02:30 -0700
Subject: [11u] 8205654: serviceability/dcmd/framework/HelpTest.java timed
 out
In-Reply-To: <8B42E32B-52A4-4391-A13C-8D20BCEC3295@oracle.com>
References: <AM6PR02MB51921687C268BAE4C923E39F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d298adec-8e51-bede-5125-8004e36d9aca@oracle.com>
 <534514DB-A591-4DC9-AE45-2C8F2BE10186@oracle.com>
 <cb95788d-c438-3615-3091-6c53162b351b@oracle.com>
 <8B42E32B-52A4-4391-A13C-8D20BCEC3295@oracle.com>
Message-ID: <9a9062b3-4db8-6310-a8df-5741a9536bfc@oracle.com>



On 7/31/19 11:55 AM, Daniil Titov wrote:
> I think either way is fine, but if backporting [1] and [2] separately, we need to ensure,
> that they will be also approved  for 11u. Currently neither [1] nor [2]
> have jdk11u-fix-request and jdk11u-fix-yes labels.

Agreed.

Thanks,
Serguei

> [1]:  JDK-8225543 - https://bugs.openjdk.java.net/browse/JDK-8225543
> [2]:  JDK-8221730 - https://bugs.openjdk.java.net/browse/JDK-8221730
>
> Best regards,
> Daniil
>
> ?On 7/31/19, 10:42 AM, "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com> wrote:
>
>      
>      
>      On 7/31/19 10:32 AM, Daniil Titov wrote:
>      > Hi Christoph,
>      >
>      > There were several issues that the original change introduced.  These issues were
>      >   solved in [1] and [2]  and they need to be included in the backport.
>      
>      You probably wanted to say, the 8225543 and 8221730 have to be
>      backported as well,
>      but not in the same backport.
>      
>      Thanks,
>      Serguei
>      
>      > [1]:  JDK-8225543 - https://bugs.openjdk.java.net/browse/JDK-8225543
>      > [2]:  JDK-8221730 - https://bugs.openjdk.java.net/browse/JDK-8221730
>      >
>      > Thanks,
>      > Daniil
>      >
>      > ?On 7/31/19, 9:41 AM, "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com> wrote:
>      >
>      >
>      >      On 7/23/19 07:58, Langer, Christoph wrote:
>      >      > Hi,
>      >      >
>      >      > please review the backport of "8205654: serviceability/dcmd/framework/HelpTest.java timed out" to OpenJDK 11u. We're seeing the mentioned test issue intermittently in our nightlies.
>      >      >
>      >      > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654
>      >      > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8205654.11u-dev.0/
>      >      > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/67537bbafd7f
>      >      > Original review discussion: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/026883.html
>      >      >
>      >      > The change improves the way how jcmd explores running Java processes on Linux. It'll then try to use the proc file system first to get the necessary information before trying to attach via the attach framework.
>      >      >
>      >      > The original patch needs 2 modifications:
>      >      > 1. In src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java I had to add the fix of JDK-8218705. The bug is not visible unfortunately but it seems something was forgot in the original commit. The change for JDK-8218705 is: http://hg.openjdk.java.net/jdk/jdk/rev/50c1b0a0f1e8
>      >      > 2. In test/lib/jdk/test/lib/util/JarUtils.java I had to take over some upstream coding from jdk/jdk to provide the JarUtils support that is needed by the new testcase "TestProcessHelper".
>      >      >
>      >      > Thanks
>      >      > Christoph
>      >      >
>      >
>      >
>      >
>      >
>      
>      
>
>


From jkang at redhat.com  Wed Jul 31 19:38:49 2019
From: jkang at redhat.com (Jie Kang)
Date: Wed, 31 Jul 2019 15:38:49 -0400
Subject: [11u] CSR question re. backport ofJDK-8228669: JFR tool
Message-ID: <CAEBeOcqewFbppY7bC6Oe4V-wDmmXqP_yyqJ28GwwPT7-xXj5pg@mail.gmail.com>

Hi all,

I would like to backport JDK-8205516: JFR tool [0] to OpenJDK 11. My
understanding from the CSR FAQ [1] is that since the initial patch
required a CSR, the backport [2] also requires a CSR. As such, I have
opened a CSR [3] with the same content as the original. However, this
thread [4] suggests that the process regarding backports and CSR's has
not been finalised yet. Also, the initial bug has already been
backported into 11.0.6-oracle [5].

I would greatly appreciate any guidance on the process moving forward.
Can I continue without the CSR?


Regards,

[0]
https://bugs.openjdk.java.net/browse/JDK-8205516

[1]
https://wiki.openjdk.java.net/display/csr/CSR+FAQs

[2]
https://bugs.openjdk.java.net/browse/JDK-8228669

[3]
https://bugs.openjdk.java.net/browse/JDK-8228670

[4]
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009646.html

[5]
https://bugs.openjdk.java.net/browse/JDK-8222896

From zgu at redhat.com  Wed Jul 31 20:32:26 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 31 Jul 2019 16:32:26 -0400
Subject: [11u] RFR 8216401: Allow "file:" URLs in Class-Path of local JARs
Message-ID: <3c11157e-c29e-793a-304a-e44428fb40e0@redhat.com>

I would like to backport this patch to 11u, as it appears to be on 
Oracle's backport list.

The patch does not apply cleanly. The fix itself applies cleanly, but 
included test does not, apparently due to test infrastructure changes.


Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216401
Original Webrev: 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html
Original review thread: 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html


11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8216401-11u/webrev.00/

Test:
   Passed included test.

Diff:
diff -r 8967c5ef0b65 
test/jdk/jdk/internal/loader/URLClassPath/JarClassPathFileEntry.java
--- 
a/test/jdk/jdk/internal/loader/URLClassPath/JarClassPathFileEntry.java 
Mon Jan 14 11:22:32 2019 -0800
+++ 
b/test/jdk/jdk/internal/loader/URLClassPath/JarClassPathFileEntry.java 
Wed Jul 31 16:15:11 2019 -0400
@@ -28,14 +28,14 @@
  import java.nio.file.Paths;
  import java.util.jar.Attributes;
  import java.util.jar.Manifest;
-import jdk.test.lib.util.JarUtils;
  import jdk.test.lib.compiler.InMemoryJavaCompiler;

  /*
   * @test
   * @bug 8216401
   * @summary Test loading of JAR Class-Path entry with file: scheme
- * @library /test/lib
+ * @library /lib/testlibrary /test/lib
+ * @build JarClassPathFileEntry JarUtils jdk.testlibrary.*
   *
   * @run main/othervm JarClassPathFileEntry
   * @run main/othervm 
-Djdk.net.URLClassPath.disableClassPathURLCheck=true JarClassPathFileEntry

Thanks,

-Zhengyu

From rob.mckenna at oracle.com  Wed Jul 31 22:04:00 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 31 Jul 2019 23:04:00 +0100
Subject: jdk/jdk13 vs jdk-updates/jdk13u
In-Reply-To: <AM6PR02MB51928F11368259B48A386E588ADC0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <743062ac-4ef6-002e-f66a-0f854837f70d@redhat.com>
 <225de205-2872-5ce4-3822-dba475a8359a@oracle.com>
 <749e495d-55f7-b363-466d-6473ff512f4a@redhat.com>
 <AM6PR02MB51928F11368259B48A386E588ADC0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <20190731220400.GC4267@tecra>

Hi folks,

I'll stew on this a little more when I get back but the best I can
commit to is a weekly sync (though I may need to reserve the right to miss
a week here and there) from jdk13 -> jdk13u.

A resource crunch is the primary cause of the early switch to 13.0.2,
but OpenJDK contributions will be pulled into the 13.0.1 stabilization repo
as critical approvals automatically for now. (I appreciate that this is
somewhat confusing, I'll tackle that next time around)

    -Rob

On 30/07/19 19:18, Langer, Christoph wrote:
> Hi,
> 
> thanks Se?n for doing the sync. I was also wondering why jdk13u was so much behind.
> 
> What I'm still wondering now is why jdk13u is already targeting 13.0.2? I mean, it's still quite some time to go for the October update and I thought it could still be targeting 13.0.1. At least I was under the impression that for the last update, 12.0.2, the jdk12u branch was open for pushes to 12.0.2 for a longer time. Maybe that's something Rob can answer as well when he's back.
> 
> Thanks
> Christoph
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Aleksey Shipilev
> > Sent: Dienstag, 30. Juli 2019 09:52
> > To: Se?n Coffey <sean.coffey at oracle.com>; jdk-updates-
> > dev at openjdk.java.net
> > Subject: Re: jdk/jdk13 vs jdk-updates/jdk13u
> >
> > On 7/30/19 6:37 PM, Se?n Coffey wrote:
> > > Seems like a sync that should be more regular.
> >
> > Yup, syncing jdk/jdk13 -> jdk-updates/jdk13u when the regular jdk/jdk13 ->
> > jdk/jdk sync happens
> > would be nice.
> >
> > > I'll sync up jdk13 to jdk13u now. Will push changes once build & testing is
> > green.
> > > Rob can discuss code sync frequency topic when he's back in the office.
> >
> > Thank you.
> >
> > --
> > -Aleksey
> 

From daniil.x.titov at oracle.com  Wed Jul 31 17:33:07 2019
From: daniil.x.titov at oracle.com (Daniil Titov)
Date: Wed, 31 Jul 2019 17:33:07 -0000
Subject: [11u] 8205654: serviceability/dcmd/framework/HelpTest.java timed
 out
In-Reply-To: <d298adec-8e51-bede-5125-8004e36d9aca@oracle.com>
References: <AM6PR02MB51921687C268BAE4C923E39F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d298adec-8e51-bede-5125-8004e36d9aca@oracle.com>
Message-ID: <534514DB-A591-4DC9-AE45-2C8F2BE10186@oracle.com>

Hi Christoph,

There were several issues that the original change introduced.  These issues were
 solved in [1] and [2]  and they need to be included in the backport.

[1]:  JDK-8225543 - https://bugs.openjdk.java.net/browse/JDK-8225543 
[2]:  JDK-8221730 - https://bugs.openjdk.java.net/browse/JDK-8221730 

Thanks,
Daniil

?On 7/31/19, 9:41 AM, "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com> wrote:

    
    On 7/23/19 07:58, Langer, Christoph wrote:
    > Hi,
    >
    > please review the backport of "8205654: serviceability/dcmd/framework/HelpTest.java timed out" to OpenJDK 11u. We're seeing the mentioned test issue intermittently in our nightlies.
    >
    > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654
    > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8205654.11u-dev.0/
    > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/67537bbafd7f
    > Original review discussion: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/026883.html
    >
    > The change improves the way how jcmd explores running Java processes on Linux. It'll then try to use the proc file system first to get the necessary information before trying to attach via the attach framework.
    >
    > The original patch needs 2 modifications:
    > 1. In src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java I had to add the fix of JDK-8218705. The bug is not visible unfortunately but it seems something was forgot in the original commit. The change for JDK-8218705 is: http://hg.openjdk.java.net/jdk/jdk/rev/50c1b0a0f1e8
    > 2. In test/lib/jdk/test/lib/util/JarUtils.java I had to take over some upstream coding from jdk/jdk to provide the JarUtils support that is needed by the new testcase "TestProcessHelper".
    >
    > Thanks
    > Christoph
    >
    
    



From daniil.x.titov at oracle.com  Wed Jul 31 18:55:41 2019
From: daniil.x.titov at oracle.com (Daniil Titov)
Date: Wed, 31 Jul 2019 18:55:41 -0000
Subject: [11u] 8205654: serviceability/dcmd/framework/HelpTest.java timed
 out
In-Reply-To: <cb95788d-c438-3615-3091-6c53162b351b@oracle.com>
References: <AM6PR02MB51921687C268BAE4C923E39F8AC70@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d298adec-8e51-bede-5125-8004e36d9aca@oracle.com>
 <534514DB-A591-4DC9-AE45-2C8F2BE10186@oracle.com>
 <cb95788d-c438-3615-3091-6c53162b351b@oracle.com>
Message-ID: <8B42E32B-52A4-4391-A13C-8D20BCEC3295@oracle.com>

I think either way is fine, but if backporting [1] and [2] separately, we need to ensure, 
that they will be also approved  for 11u. Currently neither [1] nor [2]
have jdk11u-fix-request and jdk11u-fix-yes labels.

[1]:  JDK-8225543 - https://bugs.openjdk.java.net/browse/JDK-8225543 
[2]:  JDK-8221730 - https://bugs.openjdk.java.net/browse/JDK-8221730 

Best regards,
Daniil

?On 7/31/19, 10:42 AM, "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com> wrote:

    
    
    On 7/31/19 10:32 AM, Daniil Titov wrote:
    > Hi Christoph,
    >
    > There were several issues that the original change introduced.  These issues were
    >   solved in [1] and [2]  and they need to be included in the backport.
    
    You probably wanted to say, the 8225543 and 8221730 have to be 
    backported as well,
    but not in the same backport.
    
    Thanks,
    Serguei
    
    > [1]:  JDK-8225543 - https://bugs.openjdk.java.net/browse/JDK-8225543
    > [2]:  JDK-8221730 - https://bugs.openjdk.java.net/browse/JDK-8221730
    >
    > Thanks,
    > Daniil
    >
    > ?On 7/31/19, 9:41 AM, "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com> wrote:
    >
    >      
    >      On 7/23/19 07:58, Langer, Christoph wrote:
    >      > Hi,
    >      >
    >      > please review the backport of "8205654: serviceability/dcmd/framework/HelpTest.java timed out" to OpenJDK 11u. We're seeing the mentioned test issue intermittently in our nightlies.
    >      >
    >      > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654
    >      > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8205654.11u-dev.0/
    >      > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/67537bbafd7f
    >      > Original review discussion: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/026883.html
    >      >
    >      > The change improves the way how jcmd explores running Java processes on Linux. It'll then try to use the proc file system first to get the necessary information before trying to attach via the attach framework.
    >      >
    >      > The original patch needs 2 modifications:
    >      > 1. In src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java I had to add the fix of JDK-8218705. The bug is not visible unfortunately but it seems something was forgot in the original commit. The change for JDK-8218705 is: http://hg.openjdk.java.net/jdk/jdk/rev/50c1b0a0f1e8
    >      > 2. In test/lib/jdk/test/lib/util/JarUtils.java I had to take over some upstream coding from jdk/jdk to provide the JarUtils support that is needed by the new testcase "TestProcessHelper".
    >      >
    >      > Thanks
    >      > Christoph
    >      >
    >      
    >      
    >
    >