From christoph.langer at sap.com  Mon Dec  2 08:55:28 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 2 Dec 2019 08:55:28 +0000
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <DB8PR02MB55478FC3D57902448731CCF88A430@DB8PR02MB5547.eurprd02.prod.outlook.com>

Vote:yes

Cheers
Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Daniel
> Fuchs
> Sent: Freitag, 29. November 2019 20:13
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: CFV: New JDK Committer: Julia Boes
> 
> Hi,
> 
> I hereby nominate Julia Boes (jboes) to JDK Committer.
> 
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
> 
> Votes are due by 12:00 UTC December 14th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> 
> -- daniel
> 
> [1]
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keywor
> d(julia.boes)+or+keyword(jboes)&revcount=20
> 
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus

From Alan.Bateman at oracle.com  Mon Dec  2 09:23:51 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 2 Dec 2019 09:23:51 +0000
Subject: TimeZone Updater Tool/Project, where would we put it?
In-Reply-To: <OF2AB6BEDC.2F2FBBBC-ON002584C1.00526444-802584C1.00532B8F@notes.na.collabserv.com>
References: <OFAEE3F9B5.FE0FCF43-ON002584BD.0036E6E0-802584BD.00372D04@notes.na.collabserv.com>
 <CACzrW9DxU-xgr_UoKfxYSDoHuyE736o_dfT8XVJpfW+9G=AFyg@mail.gmail.com>
 <OFCDA8CD12.CD17FC03-ON002584C0.004FA6A4-802584C0.0056D25D@notes.na.collabserv.com>
 <6ebb0947-c169-1b4c-5408-f2edbd59f252@oracle.com>
 <OF2AB6BEDC.2F2FBBBC-ON002584C1.00526444-802584C1.00532B8F@notes.na.collabserv.com>
Message-ID: <18c1d085-697e-b72e-c2bb-9fce29d17e78@oracle.com>

On 29/11/2019 15:08, Andrew Leonard wrote:
> The .zip contains the tzupdater "program" along with the latest tzdb.dat.
> The user then unzips this and runs the "program" in the desired "mode".
> Currently, it distinguishes jdk8 from jdk11+ only, and the only 
> version update is that contained within the new tzdb.dat eg."2019c". 
> So you can run the tool in "discovery" mode which will simply print 
> out what tzdb version each JDK is at...
> The basis of updating any jdk8,11,13,.. with the tzdb.dat is based 
> upon the fact that it's currently producing a "rearguard" tzdb.dat 
> which is compatible with all these versions... This would need 
> changing going forward when vanguard is used, and perhaps with that in 
> sight it maybe best to update the tool to only patch the same versions 
> from which the updater was built from...
>
> I can thus see several improvements being discussed here:
> - Better JDK version detection
> - Possibly provide release/version file update somewhere to identify 
> the update other than just in the tzdb.dat
> - Make the tool "version" specific,ie. a jdk13 "updater.zip" will only 
> patch a jdk13 JDK.
I assume "program" means something platform specific or maybe you mean a 
script?

You haven't mentioned it yet but I assume it needs to update more than 
just tzdb. For JDK 9+ at least, it will need to update the TZ data in 
the packaged module (java.base.jmod) so that any replication with jlink 
will use the new TZ data too.

There are lots of other questions but it might be better if you started 
a document to capture the needs, issues, and the possible technical 
approaches. That should help the discussion and help to see whether it 
make sense or not for something like this to be part of the JDK build or 
a separate patching tool.

-Alan

From sean.coffey at oracle.com  Mon Dec  2 09:40:29 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 2 Dec 2019 09:40:29 +0000
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <d4e9a285-1d9f-2914-68c7-9b3d108cf467@oracle.com>

Vote: yes

Regards,
Sean.

On 29/11/19 19:12, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Julia Boes (jboes) to JDK Committer.
>
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
>
> Votes are due by 12:00 UTC December 14th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
>
> -- daniel
>
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
>
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From dmitry.markov at oracle.com  Mon Dec  2 10:35:15 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 2 Dec 2019 10:35:15 +0000
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <D4C0027F-36D5-4D2F-8594-F0D90E783C63@oracle.com>

Vote: Yes

Thanks,
Dmitry

> On 29 Nov 2019, at 19:12, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> I hereby nominate Julia Boes (jboes) to JDK Committer.
> 
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
> 
> Votes are due by 12:00 UTC December 14th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> 
> -- daniel
> 
> [1] https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
> 
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From alexey.ivanov at oracle.com  Mon Dec  2 10:49:48 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 2 Dec 2019 10:49:48 +0000
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <5219a565-a0cf-8faa-fe3f-bd5756c70dc0@oracle.com>

Vote: yes

On 29/11/2019 19:12, Daniel Fuchs wrote:
> I hereby nominate Julia Boes (jboes) to JDK Committer.
-- 
Regards,
Alexey

From sean.coffey at oracle.com  Mon Dec  2 11:01:22 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 2 Dec 2019 11:01:22 +0000
Subject: Result: New JDK Reviewer: Alexey Ivanov
Message-ID: <c6554082-87bb-8d8f-f88a-beced5b1ccd9@oracle.com>

Voting for Alexey Ivanov [1] is now closed.

Yes: 18
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

regards,
Sean.

[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003593.html

From neugens.limasoftware at gmail.com  Mon Dec  2 11:53:10 2019
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Mon, 2 Dec 2019 06:53:10 -0500
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <CAGUMyaRso+omBzXkzqTG9jvqQyFkDnTZqUFzY=p+ss162r8dQA@mail.gmail.com>

Vote: yes

Cheers,
Mario

On Fri 29. Nov 2019 at 14:13, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Hi,
>
> I hereby nominate Julia Boes (jboes) to JDK Committer.
>
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
>
> Votes are due by 12:00 UTC December 14th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
>
> -- daniel
>
> [1]
>
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
>
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
>
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From aleksej.efimov at oracle.com  Mon Dec  2 12:10:55 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Mon, 2 Dec 2019 12:10:55 +0000
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <93578116-700f-266f-41cd-83300e264d15@oracle.com>

Vote: yes

Best Regards,
Aleksei

On 29/11/2019 19:12, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Julia Boes (jboes) to JDK Committer.
>
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
>
> Votes are due by 12:00 UTC December 14th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
>
> -- daniel
>
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
>
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From sean.coffey at oracle.com  Mon Dec  2 12:55:06 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 2 Dec 2019 12:55:06 +0000
Subject: TimeZone Updater Tool/Project, where would we put it?
In-Reply-To: <18c1d085-697e-b72e-c2bb-9fce29d17e78@oracle.com>
References: <OFAEE3F9B5.FE0FCF43-ON002584BD.0036E6E0-802584BD.00372D04@notes.na.collabserv.com>
 <CACzrW9DxU-xgr_UoKfxYSDoHuyE736o_dfT8XVJpfW+9G=AFyg@mail.gmail.com>
 <OFCDA8CD12.CD17FC03-ON002584C0.004FA6A4-802584C0.0056D25D@notes.na.collabserv.com>
 <6ebb0947-c169-1b4c-5408-f2edbd59f252@oracle.com>
 <OF2AB6BEDC.2F2FBBBC-ON002584C1.00526444-802584C1.00532B8F@notes.na.collabserv.com>
 <18c1d085-697e-b72e-c2bb-9fce29d17e78@oracle.com>
Message-ID: <802293b8-07a5-1f42-319f-ade9a4cd4d5d@oracle.com>

I think Alan and Stephen Colebourne's comment may be on the right track 
for this proposal.

The current tzupdater process is due an upgrade in how it operates. 
We've also considered open sourcing a similar version of our tzupdater 
tool but felt that it needs to be modernized. We should move away from 
updating specific internals (like the tzdb.dat file which is not part or 
Java SE spec AFAIK). Similar concerns were made in 2016 when proposals 
to control the location of tzdb.dat were raised [1]

Moving to a service provider and/or upgradeable module solution may be a 
good approach. At the moment,  JDK 8+ uses the 
java.time.zone.ZoneRulesProvider class as the default service provider. 
It can be substituted with use of the 
`java.time.zone.DefaultZoneRulesProvider' system property.

[1] 
https://bugs.openjdk.java.net/browse/JDK-8153044?focusedCommentId=13970444&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13970444

Regards,
Sean.

On 02/12/19 09:23, Alan Bateman wrote:
> On 29/11/2019 15:08, Andrew Leonard wrote:
>> The .zip contains the tzupdater "program" along with the latest 
>> tzdb.dat.
>> The user then unzips this and runs the "program" in the desired "mode".
>> Currently, it distinguishes jdk8 from jdk11+ only, and the only 
>> version update is that contained within the new tzdb.dat eg."2019c". 
>> So you can run the tool in "discovery" mode which will simply print 
>> out what tzdb version each JDK is at...
>> The basis of updating any jdk8,11,13,.. with the tzdb.dat is based 
>> upon the fact that it's currently producing a "rearguard" tzdb.dat 
>> which is compatible with all these versions... This would need 
>> changing going forward when vanguard is used, and perhaps with that 
>> in sight it maybe best to update the tool to only patch the same 
>> versions from which the updater was built from...
>>
>> I can thus see several improvements being discussed here:
>> - Better JDK version detection
>> - Possibly provide release/version file update somewhere to identify 
>> the update other than just in the tzdb.dat
>> - Make the tool "version" specific,ie. a jdk13 "updater.zip" will 
>> only patch a jdk13 JDK.
> I assume "program" means something platform specific or maybe you mean 
> a script?
>
> You haven't mentioned it yet but I assume it needs to update more than 
> just tzdb. For JDK 9+ at least, it will need to update the TZ data in 
> the packaged module (java.base.jmod) so that any replication with 
> jlink will use the new TZ data too.
>
> There are lots of other questions but it might be better if you 
> started a document to capture the needs, issues, and the possible 
> technical approaches. That should help the discussion and help to see 
> whether it make sense or not for something like this to be part of the 
> JDK build or a separate patching tool.
>
> -Alan


From martin.doerr at sap.com  Mon Dec  2 13:34:26 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 2 Dec 2019 13:34:26 +0000
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <93578116-700f-266f-41cd-83300e264d15@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
 <93578116-700f-266f-41cd-83300e264d15@oracle.com>
Message-ID: <AM0PR0202MB329713134DA54C0055FE085D9A430@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Vote: yes

Best Regards,
Martin


> -----Original Message-----
> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Aleks
> Efimov
> Sent: Montag, 2. Dezember 2019 13:11
> To: jdk-dev at openjdk.java.net
> Subject: Re: CFV: New JDK Committer: Julia Boes
> 
> Vote: yes
> 
> Best Regards,
> Aleksei
> 
> On 29/11/2019 19:12, Daniel Fuchs wrote:
> > Hi,
> >
> > I hereby nominate Julia Boes (jboes) to JDK Committer.
> >
> > Julia is a member of the java core libraries team at Oracle.
> > Julia already contributed 16 fixes to the JDK project [1].
> >
> > Votes are due by 12:00 UTC December 14th, 2019.
> >
> > Only current JDK Committers [2] 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 [3].
> >
> > Best regards,
> >
> > -- daniel
> >
> > [1]
> >
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keywor
> d(julia.boes)+or+keyword(jboes)&revcount=20
> >
> > [2] http://openjdk.java.net/census
> > [3] http://openjdk.java.net/bylaws#lazy-consensus


From andrew_m_leonard at uk.ibm.com  Mon Dec  2 14:33:13 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Mon, 2 Dec 2019 14:33:13 +0000
Subject: TimeZone Updater Tool/Project, where would we put it?
In-Reply-To: <802293b8-07a5-1f42-319f-ade9a4cd4d5d@oracle.com>
References: <OFAEE3F9B5.FE0FCF43-ON002584BD.0036E6E0-802584BD.00372D04@notes.na.collabserv.com>
 <CACzrW9DxU-xgr_UoKfxYSDoHuyE736o_dfT8XVJpfW+9G=AFyg@mail.gmail.com>
 <OFCDA8CD12.CD17FC03-ON002584C0.004FA6A4-802584C0.0056D25D@notes.na.collabserv.com>
 <6ebb0947-c169-1b4c-5408-f2edbd59f252@oracle.com>
 <OF2AB6BEDC.2F2FBBBC-ON002584C1.00526444-802584C1.00532B8F@notes.na.collabserv.com>
 <18c1d085-697e-b72e-c2bb-9fce29d17e78@oracle.com>
 <802293b8-07a5-1f42-319f-ade9a4cd4d5d@oracle.com>
Message-ID: <OFA3FB7870.510810A6-ON002584C4.004F13C4-802584C4.004FF229@notes.na.collabserv.com>

Hi Sean,
Yes, I can see where you're going, it does seem more structured to define 
an upgradeable module method... has anyone had a go at producing a 
build/make mechanism to build one of those from the latest IANA data?
Could we modularise the current TzdbZoneRuleProvider into it's own module, 
and then allow a openjdk make target to build just that with the latest 
IANA and produce a upgradeable module replacement image for it...?
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:   "Se?n Coffey" <sean.coffey at oracle.com>
To:     Alan Bateman <Alan.Bateman at oracle.com>, Andrew Leonard 
<andrew_m_leonard at uk.ibm.com>
Cc:     jdk-dev <jdk-dev at openjdk.java.net>
Date:   02/12/2019 12:55
Subject:        [EXTERNAL] Re: TimeZone Updater Tool/Project, where would 
we put it?



I think Alan and Stephen Colebourne's comment may be on the right track 
for this proposal.

The current tzupdater process is due an upgrade in how it operates. 
We've also considered open sourcing a similar version of our tzupdater 
tool but felt that it needs to be modernized. We should move away from 
updating specific internals (like the tzdb.dat file which is not part or 
Java SE spec AFAIK). Similar concerns were made in 2016 when proposals 
to control the location of tzdb.dat were raised [1]

Moving to a service provider and/or upgradeable module solution may be a 
good approach. At the moment,  JDK 8+ uses the 
java.time.zone.ZoneRulesProvider class as the default service provider. 
It can be substituted with use of the 
`java.time.zone.DefaultZoneRulesProvider' system property.

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8153044-3FfocusedCommentId-3D13970444-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-253Acomment-2Dtabpanel-23comment-2D13970444&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=kUG0ybdJrp9uFosvwuDyIBKhr1b4R9POoYCFA81bk4c&s=0NmENnWxOJT5e40_QBVQp6lXE5NMyIALdG0ZYSw2dFw&e= 


Regards,
Sean.

On 02/12/19 09:23, Alan Bateman wrote:
> On 29/11/2019 15:08, Andrew Leonard wrote:
>> The .zip contains the tzupdater "program" along with the latest 
>> tzdb.dat.
>> The user then unzips this and runs the "program" in the desired "mode".
>> Currently, it distinguishes jdk8 from jdk11+ only, and the only 
>> version update is that contained within the new tzdb.dat eg."2019c". 
>> So you can run the tool in "discovery" mode which will simply print 
>> out what tzdb version each JDK is at...
>> The basis of updating any jdk8,11,13,.. with the tzdb.dat is based 
>> upon the fact that it's currently producing a "rearguard" tzdb.dat 
>> which is compatible with all these versions... This would need 
>> changing going forward when vanguard is used, and perhaps with that 
>> in sight it maybe best to update the tool to only patch the same 
>> versions from which the updater was built from...
>>
>> I can thus see several improvements being discussed here:
>> - Better JDK version detection
>> - Possibly provide release/version file update somewhere to identify 
>> the update other than just in the tzdb.dat
>> - Make the tool "version" specific,ie. a jdk13 "updater.zip" will 
>> only patch a jdk13 JDK.
> I assume "program" means something platform specific or maybe you mean 
> a script?
>
> You haven't mentioned it yet but I assume it needs to update more than 
> just tzdb. For JDK 9+ at least, it will need to update the TZ data in 
> the packaged module (java.base.jmod) so that any replication with 
> jlink will use the new TZ data too.
>
> There are lots of other questions but it might be better if you 
> started a document to capture the needs, issues, and the possible 
> technical approaches. That should help the discussion and help to see 
> whether it make sense or not for something like this to be part of the 
> JDK build or a separate patching tool.
>
> -Alan





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 Roger.Riggs at oracle.com  Mon Dec  2 14:47:34 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 2 Dec 2019 09:47:34 -0500
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <3560a296-a8df-23c4-7ad2-b6cb318af304@oracle.com>

Vote: yes

On 11/29/19 2:12 PM, Daniel Fuchs wrote:
> I hereby nominate Julia Boes (jboes) to JDK Committer. 


From bevans at newrelic.com  Mon Dec  2 15:07:10 2019
From: bevans at newrelic.com (Ben Evans)
Date: Mon, 2 Dec 2019 16:07:10 +0100
Subject: TimeZone Updater Tool/Project, where would we put it?
In-Reply-To: <802293b8-07a5-1f42-319f-ade9a4cd4d5d@oracle.com>
References: <OFAEE3F9B5.FE0FCF43-ON002584BD.0036E6E0-802584BD.00372D04@notes.na.collabserv.com>
 <CACzrW9DxU-xgr_UoKfxYSDoHuyE736o_dfT8XVJpfW+9G=AFyg@mail.gmail.com>
 <OFCDA8CD12.CD17FC03-ON002584C0.004FA6A4-802584C0.0056D25D@notes.na.collabserv.com>
 <6ebb0947-c169-1b4c-5408-f2edbd59f252@oracle.com>
 <OF2AB6BEDC.2F2FBBBC-ON002584C1.00526444-802584C1.00532B8F@notes.na.collabserv.com>
 <18c1d085-697e-b72e-c2bb-9fce29d17e78@oracle.com>
 <802293b8-07a5-1f42-319f-ade9a4cd4d5d@oracle.com>
Message-ID: <CAGw=730vubgQAAnSQKyNxGZcFA8_7Cj+Y5FKixew9gSHbMo9+Q@mail.gmail.com>

Hi Se?n,

>From my perspective, I agree that this seems like a superior
technical solution. However, I am concerned about how quickly that solution
could be made available.

In the case of Brazil's change - it made it into the timezone data in 2018,
but the JDK only picked it up in October 2019. Depending on the criticality
of a service, that's not a huge window for changing your runtime. We had
already started to experience issues regarding the change before 8u232 was
available.

If IBM have a tool that is close to being usable today, then in my opinion,
it would be far better to get it out there now (perhaps as part of Adopt
rather than upstream if that's easier for you). It can then be replaced by
a cleaner (modular) solution at a more leisurely pace.

In terms of how we'd use it - once available we'd run this tool as part of
our Docker base image builds. While that makes it still possible for an
infrequently changing service to get out of date, it's far less likely and
the fix is just a rebuild away. Other organisations will have other
requirements, of course, but this is an obvious quick-and-dirty solution
that will work for a large number of people.

Just my 2c, of course.

Thanks,

Ben




On Mon, Dec 2, 2019 at 1:57 PM Se?n Coffey <sean.coffey at oracle.com> wrote:

> I think Alan and Stephen Colebourne's comment may be on the right track
> for this proposal.
>
> The current tzupdater process is due an upgrade in how it operates.
> We've also considered open sourcing a similar version of our tzupdater
> tool but felt that it needs to be modernized. We should move away from
> updating specific internals (like the tzdb.dat file which is not part or
> Java SE spec AFAIK). Similar concerns were made in 2016 when proposals
> to control the location of tzdb.dat were raised [1]
>
> Moving to a service provider and/or upgradeable module solution may be a
> good approach. At the moment,  JDK 8+ uses the
> java.time.zone.ZoneRulesProvider class as the default service provider.
> It can be substituted with use of the
> `java.time.zone.DefaultZoneRulesProvider' system property.
>
> [1]
>
> https://bugs.openjdk.java.net/browse/JDK-8153044?focusedCommentId=13970444&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13970444
>
> Regards,
> Sean.
>
> On 02/12/19 09:23, Alan Bateman wrote:
> > On 29/11/2019 15:08, Andrew Leonard wrote:
> >> The .zip contains the tzupdater "program" along with the latest
> >> tzdb.dat.
> >> The user then unzips this and runs the "program" in the desired "mode".
> >> Currently, it distinguishes jdk8 from jdk11+ only, and the only
> >> version update is that contained within the new tzdb.dat eg."2019c".
> >> So you can run the tool in "discovery" mode which will simply print
> >> out what tzdb version each JDK is at...
> >> The basis of updating any jdk8,11,13,.. with the tzdb.dat is based
> >> upon the fact that it's currently producing a "rearguard" tzdb.dat
> >> which is compatible with all these versions... This would need
> >> changing going forward when vanguard is used, and perhaps with that
> >> in sight it maybe best to update the tool to only patch the same
> >> versions from which the updater was built from...
> >>
> >> I can thus see several improvements being discussed here:
> >> - Better JDK version detection
> >> - Possibly provide release/version file update somewhere to identify
> >> the update other than just in the tzdb.dat
> >> - Make the tool "version" specific,ie. a jdk13 "updater.zip" will
> >> only patch a jdk13 JDK.
> > I assume "program" means something platform specific or maybe you mean
> > a script?
> >
> > You haven't mentioned it yet but I assume it needs to update more than
> > just tzdb. For JDK 9+ at least, it will need to update the TZ data in
> > the packaged module (java.base.jmod) so that any replication with
> > jlink will use the new TZ data too.
> >
> > There are lots of other questions but it might be better if you
> > started a document to capture the needs, issues, and the possible
> > technical approaches. That should help the discussion and help to see
> > whether it make sense or not for something like this to be part of the
> > JDK build or a separate patching tool.
> >
> > -Alan
>
>

From scolebourne at joda.org  Mon Dec  2 15:34:37 2019
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 2 Dec 2019 15:34:37 +0000
Subject: TimeZone Updater Tool/Project, where would we put it?
In-Reply-To: <OFA3FB7870.510810A6-ON002584C4.004F13C4-802584C4.004FF229@notes.na.collabserv.com>
References: <OFAEE3F9B5.FE0FCF43-ON002584BD.0036E6E0-802584BD.00372D04@notes.na.collabserv.com>
 <CACzrW9DxU-xgr_UoKfxYSDoHuyE736o_dfT8XVJpfW+9G=AFyg@mail.gmail.com>
 <OFCDA8CD12.CD17FC03-ON002584C0.004FA6A4-802584C0.0056D25D@notes.na.collabserv.com>
 <6ebb0947-c169-1b4c-5408-f2edbd59f252@oracle.com>
 <OF2AB6BEDC.2F2FBBBC-ON002584C1.00526444-802584C1.00532B8F@notes.na.collabserv.com>
 <18c1d085-697e-b72e-c2bb-9fce29d17e78@oracle.com>
 <802293b8-07a5-1f42-319f-ade9a4cd4d5d@oracle.com>
 <OFA3FB7870.510810A6-ON002584C4.004F13C4-802584C4.004FF229@notes.na.collabserv.com>
Message-ID: <CACzrW9CydW4uYgW1+sEfmpUfG3d_taAg3HZehCQr4YDAd9_J3A@mail.gmail.com>

I've just tried adding a later tzdb file with the current setup.

* It is possible to set -Djava.time.zone.DefaultZoneRulesProvider and
replace the standard TZDB provider.
* The replacement class cannot just be a clone of
TzdbZoneRulesProvider because it needs access to a restricted
deserialization API in java.time.zone.Ser. (The Java module system
makes this hard to work around)
* Because of the restricted deserialization API, I'd be concerned
about startup time if construction had to go through the main public
API of ZoneRules etc.
* It is not possible to just add a second TZDB provider with a
different version via the service loader. The current design is based
on the idea that a provider owns all the zone identifiers it provides,
and thus no other provider can supply the same zone identifiers.

The original code [1] looked for all files named tzdb.dat on the
classpath, which allowed multiple versions to be loaded just by adding
to the classpath. This ability was lost during integration, so there
is a need to change the JDK code to find a way to get a modular jar to
work well. It will need a bit of design work I suspect.

My desire is that updating tzdb should be as easy as updating any
other maven artifact. One possible approach would be for the
TzdbZoneRulesProvider to use a second service loader call to get the
actual tzdb .dat files.

Stephen

[1] https://github.com/ThreeTen/threetenbp/blob/master/src/main/java/org/threeten/bp/zone/TzdbZoneRulesProvider.java#L158


On Mon, 2 Dec 2019 at 14:35, Andrew Leonard <andrew_m_leonard at uk.ibm.com> wrote:
>
> Hi Sean,
> Yes, I can see where you're going, it does seem more structured to define
> an upgradeable module method... has anyone had a go at producing a
> build/make mechanism to build one of those from the latest IANA data?
> Could we modularise the current TzdbZoneRuleProvider into it's own module,
> and then allow a openjdk make target to build just that with the latest
> IANA and produce a upgradeable module replacement image for it...?
> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
>
>
>
> From:   "Se?n Coffey" <sean.coffey at oracle.com>
> To:     Alan Bateman <Alan.Bateman at oracle.com>, Andrew Leonard
> <andrew_m_leonard at uk.ibm.com>
> Cc:     jdk-dev <jdk-dev at openjdk.java.net>
> Date:   02/12/2019 12:55
> Subject:        [EXTERNAL] Re: TimeZone Updater Tool/Project, where would
> we put it?
>
>
>
> I think Alan and Stephen Colebourne's comment may be on the right track
> for this proposal.
>
> The current tzupdater process is due an upgrade in how it operates.
> We've also considered open sourcing a similar version of our tzupdater
> tool but felt that it needs to be modernized. We should move away from
> updating specific internals (like the tzdb.dat file which is not part or
> Java SE spec AFAIK). Similar concerns were made in 2016 when proposals
> to control the location of tzdb.dat were raised [1]
>
> Moving to a service provider and/or upgradeable module solution may be a
> good approach. At the moment,  JDK 8+ uses the
> java.time.zone.ZoneRulesProvider class as the default service provider.
> It can be substituted with use of the
> `java.time.zone.DefaultZoneRulesProvider' system property.
>
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8153044-3FfocusedCommentId-3D13970444-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-253Acomment-2Dtabpanel-23comment-2D13970444&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=kUG0ybdJrp9uFosvwuDyIBKhr1b4R9POoYCFA81bk4c&s=0NmENnWxOJT5e40_QBVQp6lXE5NMyIALdG0ZYSw2dFw&e=
>
>
> Regards,
> Sean.
>
> On 02/12/19 09:23, Alan Bateman wrote:
> > On 29/11/2019 15:08, Andrew Leonard wrote:
> >> The .zip contains the tzupdater "program" along with the latest
> >> tzdb.dat.
> >> The user then unzips this and runs the "program" in the desired "mode".
> >> Currently, it distinguishes jdk8 from jdk11+ only, and the only
> >> version update is that contained within the new tzdb.dat eg."2019c".
> >> So you can run the tool in "discovery" mode which will simply print
> >> out what tzdb version each JDK is at...
> >> The basis of updating any jdk8,11,13,.. with the tzdb.dat is based
> >> upon the fact that it's currently producing a "rearguard" tzdb.dat
> >> which is compatible with all these versions... This would need
> >> changing going forward when vanguard is used, and perhaps with that
> >> in sight it maybe best to update the tool to only patch the same
> >> versions from which the updater was built from...
> >>
> >> I can thus see several improvements being discussed here:
> >> - Better JDK version detection
> >> - Possibly provide release/version file update somewhere to identify
> >> the update other than just in the tzdb.dat
> >> - Make the tool "version" specific,ie. a jdk13 "updater.zip" will
> >> only patch a jdk13 JDK.
> > I assume "program" means something platform specific or maybe you mean
> > a script?
> >
> > You haven't mentioned it yet but I assume it needs to update more than
> > just tzdb. For JDK 9+ at least, it will need to update the TZ data in
> > the packaged module (java.base.jmod) so that any replication with
> > jlink will use the new TZ data too.
> >
> > There are lots of other questions but it might be better if you
> > started a document to capture the needs, issues, and the possible
> > technical approaches. That should help the discussion and help to see
> > whether it make sense or not for something like this to be part of the
> > JDK build or a separate patching tool.
> >
> > -Alan
>
>
>
>
>
> 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 naoto.sato at oracle.com  Mon Dec  2 15:52:49 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 2 Dec 2019 07:52:49 -0800
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <2c1cdd8f-9747-a327-8f28-44ecb3c01a29@oracle.com>

Vote: yes

Naoto

On 11/29/19 11:12 AM, Daniel Fuchs wrote:
> Hi,
> 
> I hereby nominate Julia Boes (jboes) to JDK Committer.
> 
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
> 
> Votes are due by 12:00 UTC December 14th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> 
> -- daniel
> 
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20 
> 
> 
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus

From maurizio.cimadamore at oracle.com  Mon Dec  2 16:06:55 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 2 Dec 2019 16:06:55 +0000
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <3f6429b1-f58e-ef32-3158-a9ea918dc075@oracle.com>

Vote: yes!

Maurizio

On 29/11/2019 19:12, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Julia Boes (jboes) to JDK Committer.
>
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
>
> Votes are due by 12:00 UTC December 14th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
>
> -- daniel
>
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
>
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus

From brian.burkhalter at oracle.com  Mon Dec  2 16:38:13 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 2 Dec 2019 08:38:13 -0800
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <4E7AD9C7-EEE7-45D9-A748-5D10C4A0C7E8@oracle.com>

Vote: Yes

Brian

> On Nov 29, 2019, at 11:12 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> I hereby nominate Julia Boes (jboes) to JDK Committer.


From huizhe.wang at oracle.com  Mon Dec  2 17:10:54 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 2 Dec 2019 09:10:54 -0800
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <ae76a1fb-bc7e-32c7-00db-6a1f1fa10c50@oracle.com>

Vote: yes

On 11/29/19 11:12 AM, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Julia Boes (jboes) to JDK Committer.
>
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
>
> Votes are due by 12:00 UTC December 14th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
>
> -- daniel
>
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
>
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From brent.christian at oracle.com  Mon Dec  2 17:33:24 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 2 Dec 2019 09:33:24 -0800
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <98e6104d-824e-efb3-f69b-4796f75aeab9@oracle.com>

Vote: Yes

On 11/29/19 11:12 AM, Daniel Fuchs wrote:
> 
> I hereby nominate Julia Boes (jboes) to JDK Committer.
> 


From mandy.chung at oracle.com  Mon Dec  2 18:34:45 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 2 Dec 2019 10:34:45 -0800
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <29dedb36-b48e-15d2-e40a-9e3d002b74ac@oracle.com>

Vote: yes

Mandy

On 11/29/19 11:12 AM, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Julia Boes (jboes) to JDK Committer.
>
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
>
> Votes are due by 12:00 UTC December 14th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
>
> -- daniel
>
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
>
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From sgehwolf at redhat.com  Mon Dec  2 19:27:26 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 02 Dec 2019 20:27:26 +0100
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <0694aa9a14782be6e34bedcc8b7ba8f71bde58b4.camel@redhat.com>

Vote: yes.

On Fri, 2019-11-29 at 19:12 +0000, Daniel Fuchs wrote:
> Hi,
> 
> I hereby nominate Julia Boes (jboes) to JDK Committer.
> 
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
> 
> Votes are due by 12:00 UTC December 14th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> 
> -- daniel
> 
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
> 
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 


From adinn at redhat.com  Mon Dec  2 19:35:26 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 2 Dec 2019 19:35:26 +0000
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <4c766cc6-2e45-cf5f-6fd1-db47526a7808@redhat.com>

Vote: yes

On 29/11/2019 19:12, Daniel Fuchs wrote:
> Hi,
> 
> I hereby nominate Julia Boes (jboes) to JDK Committer.
> 
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
> 
> Votes are due by 12:00 UTC December 14th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> 
> -- daniel
> 
> [1]
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
> 
> 
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 

-- 
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


From andrew_m_leonard at uk.ibm.com  Mon Dec  2 21:11:40 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Mon, 2 Dec 2019 21:11:40 +0000
Subject: TimeZone Updater Tool/Project, where would we put it?
In-Reply-To: <CACzrW9CydW4uYgW1+sEfmpUfG3d_taAg3HZehCQr4YDAd9_J3A@mail.gmail.com>
References: <OFAEE3F9B5.FE0FCF43-ON002584BD.0036E6E0-802584BD.00372D04@notes.na.collabserv.com>
 <CACzrW9DxU-xgr_UoKfxYSDoHuyE736o_dfT8XVJpfW+9G=AFyg@mail.gmail.com>
 <OFCDA8CD12.CD17FC03-ON002584C0.004FA6A4-802584C0.0056D25D@notes.na.collabserv.com>
 <6ebb0947-c169-1b4c-5408-f2edbd59f252@oracle.com>
 <OF2AB6BEDC.2F2FBBBC-ON002584C1.00526444-802584C1.00532B8F@notes.na.collabserv.com>
 <18c1d085-697e-b72e-c2bb-9fce29d17e78@oracle.com>
 <802293b8-07a5-1f42-319f-ade9a4cd4d5d@oracle.com>
 <OFA3FB7870.510810A6-ON002584C4.004F13C4-802584C4.004FF229@notes.na.collabserv.com>
 <CACzrW9CydW4uYgW1+sEfmpUfG3d_taAg3HZehCQr4YDAd9_J3A@mail.gmail.com>
Message-ID: <OF2D860818.D300D03E-ON002584C4.00741AE9-802584C4.00746C9F@notes.na.collabserv.com>

Hi Stephen,
Thanks for your detailed test and description, you've highlighted some 
good issues here, which I don't think we've fully thought about, so that's 
great to discuss. I'll have a ponder on it, and discuss with my colleague.
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:   Stephen Colebourne <scolebourne at joda.org>
To:     jdk-dev <jdk-dev at openjdk.java.net>
Date:   02/12/2019 15:35
Subject:        [EXTERNAL] Re: TimeZone Updater Tool/Project, where would 
we put it?
Sent by:        "jdk-dev" <jdk-dev-bounces at openjdk.java.net>



I've just tried adding a later tzdb file with the current setup.

* It is possible to set -Djava.time.zone.DefaultZoneRulesProvider and
replace the standard TZDB provider.
* The replacement class cannot just be a clone of
TzdbZoneRulesProvider because it needs access to a restricted
deserialization API in java.time.zone.Ser. (The Java module system
makes this hard to work around)
* Because of the restricted deserialization API, I'd be concerned
about startup time if construction had to go through the main public
API of ZoneRules etc.
* It is not possible to just add a second TZDB provider with a
different version via the service loader. The current design is based
on the idea that a provider owns all the zone identifiers it provides,
and thus no other provider can supply the same zone identifiers.

The original code [1] looked for all files named tzdb.dat on the
classpath, which allowed multiple versions to be loaded just by adding
to the classpath. This ability was lost during integration, so there
is a need to change the JDK code to find a way to get a modular jar to
work well. It will need a bit of design work I suspect.

My desire is that updating tzdb should be as easy as updating any
other maven artifact. One possible approach would be for the
TzdbZoneRulesProvider to use a second service loader call to get the
actual tzdb .dat files.

Stephen

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ThreeTen_threetenbp_blob_master_src_main_java_org_threeten_bp_zone_TzdbZoneRulesProvider.java-23L158&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=9qQDqnSn7Ktdv8hydCo_Ax1DlUfEzXPHa5-LZ_rdwfo&s=x_imqjkXxxomzFanxuU_oU9QiiCZgai8U0EULWkAWIE&e= 



On Mon, 2 Dec 2019 at 14:35, Andrew Leonard <andrew_m_leonard at uk.ibm.com> 
wrote:
>
> Hi Sean,
> Yes, I can see where you're going, it does seem more structured to 
define
> an upgradeable module method... has anyone had a go at producing a
> build/make mechanism to build one of those from the latest IANA data?
> Could we modularise the current TzdbZoneRuleProvider into it's own 
module,
> and then allow a openjdk make target to build just that with the latest
> IANA and produce a upgradeable module replacement image for it...?
> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
>
>
>
> From:   "Se?n Coffey" <sean.coffey at oracle.com>
> To:     Alan Bateman <Alan.Bateman at oracle.com>, Andrew Leonard
> <andrew_m_leonard at uk.ibm.com>
> Cc:     jdk-dev <jdk-dev at openjdk.java.net>
> Date:   02/12/2019 12:55
> Subject:        [EXTERNAL] Re: TimeZone Updater Tool/Project, where 
would
> we put it?
>
>
>
> I think Alan and Stephen Colebourne's comment may be on the right track
> for this proposal.
>
> The current tzupdater process is due an upgrade in how it operates.
> We've also considered open sourcing a similar version of our tzupdater
> tool but felt that it needs to be modernized. We should move away from
> updating specific internals (like the tzdb.dat file which is not part or
> Java SE spec AFAIK). Similar concerns were made in 2016 when proposals
> to control the location of tzdb.dat were raised [1]
>
> Moving to a service provider and/or upgradeable module solution may be a
> good approach. At the moment,  JDK 8+ uses the
> java.time.zone.ZoneRulesProvider class as the default service provider.
> It can be substituted with use of the
> `java.time.zone.DefaultZoneRulesProvider' system property.
>
> [1]
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8153044-3FfocusedCommentId-3D13970444-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-253Acomment-2Dtabpanel-23comment-2D13970444&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=kUG0ybdJrp9uFosvwuDyIBKhr1b4R9POoYCFA81bk4c&s=0NmENnWxOJT5e40_QBVQp6lXE5NMyIALdG0ZYSw2dFw&e=

>
>
> Regards,
> Sean.
>
> On 02/12/19 09:23, Alan Bateman wrote:
> > On 29/11/2019 15:08, Andrew Leonard wrote:
> >> The .zip contains the tzupdater "program" along with the latest
> >> tzdb.dat.
> >> The user then unzips this and runs the "program" in the desired 
"mode".
> >> Currently, it distinguishes jdk8 from jdk11+ only, and the only
> >> version update is that contained within the new tzdb.dat eg."2019c".
> >> So you can run the tool in "discovery" mode which will simply print
> >> out what tzdb version each JDK is at...
> >> The basis of updating any jdk8,11,13,.. with the tzdb.dat is based
> >> upon the fact that it's currently producing a "rearguard" tzdb.dat
> >> which is compatible with all these versions... This would need
> >> changing going forward when vanguard is used, and perhaps with that
> >> in sight it maybe best to update the tool to only patch the same
> >> versions from which the updater was built from...
> >>
> >> I can thus see several improvements being discussed here:
> >> - Better JDK version detection
> >> - Possibly provide release/version file update somewhere to identify
> >> the update other than just in the tzdb.dat
> >> - Make the tool "version" specific,ie. a jdk13 "updater.zip" will
> >> only patch a jdk13 JDK.
> > I assume "program" means something platform specific or maybe you mean
> > a script?
> >
> > You haven't mentioned it yet but I assume it needs to update more than
> > just tzdb. For JDK 9+ at least, it will need to update the TZ data in
> > the packaged module (java.base.jmod) so that any replication with
> > jlink will use the new TZ data too.
> >
> > There are lots of other questions but it might be better if you
> > started a document to capture the needs, issues, and the possible
> > technical approaches. That should help the discussion and help to see
> > whether it make sense or not for something like this to be part of the
> > JDK build or a separate patching tool.
> >
> > -Alan
>
>
>
>
>
> 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 naoto.sato at oracle.com  Mon Dec  2 21:53:46 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 2 Dec 2019 13:53:46 -0800
Subject: TimeZone Updater Tool/Project, where would we put it?
In-Reply-To: <OF2D860818.D300D03E-ON002584C4.00741AE9-802584C4.00746C9F@notes.na.collabserv.com>
References: <OFAEE3F9B5.FE0FCF43-ON002584BD.0036E6E0-802584BD.00372D04@notes.na.collabserv.com>
 <CACzrW9DxU-xgr_UoKfxYSDoHuyE736o_dfT8XVJpfW+9G=AFyg@mail.gmail.com>
 <OFCDA8CD12.CD17FC03-ON002584C0.004FA6A4-802584C0.0056D25D@notes.na.collabserv.com>
 <6ebb0947-c169-1b4c-5408-f2edbd59f252@oracle.com>
 <OF2AB6BEDC.2F2FBBBC-ON002584C1.00526444-802584C1.00532B8F@notes.na.collabserv.com>
 <18c1d085-697e-b72e-c2bb-9fce29d17e78@oracle.com>
 <802293b8-07a5-1f42-319f-ade9a4cd4d5d@oracle.com>
 <OFA3FB7870.510810A6-ON002584C4.004F13C4-802584C4.004FF229@notes.na.collabserv.com>
 <CACzrW9CydW4uYgW1+sEfmpUfG3d_taAg3HZehCQr4YDAd9_J3A@mail.gmail.com>
 <OF2D860818.D300D03E-ON002584C4.00741AE9-802584C4.00746C9F@notes.na.collabserv.com>
Message-ID: <785a9dea-5e3c-c550-abd2-9cd618376f37@oracle.com>

Hi,

It'd be good to not relying on tzdb.dat file but on the provider 
interface, but I would like to point out that client of tzdb.dat is not 
only java.time, but also is the old java.util date/time API. If we were 
to adopt the approach to update time zone data through java.time's 
provider, there should be some kind of bridging to java.util date/time.

Naoto

On 12/2/19 1:11 PM, Andrew Leonard wrote:
> Hi Stephen,
> Thanks for your detailed test and description, you've highlighted some
> good issues here, which I don't think we've fully thought about, so that's
> great to discuss. I'll have a ponder on it, and discuss with my colleague.
> Thanks
> Andrew
> 
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
> 
> 
> 
> 
> From:   Stephen Colebourne <scolebourne at joda.org>
> To:     jdk-dev <jdk-dev at openjdk.java.net>
> Date:   02/12/2019 15:35
> Subject:        [EXTERNAL] Re: TimeZone Updater Tool/Project, where would
> we put it?
> Sent by:        "jdk-dev" <jdk-dev-bounces at openjdk.java.net>
> 
> 
> 
> I've just tried adding a later tzdb file with the current setup.
> 
> * It is possible to set -Djava.time.zone.DefaultZoneRulesProvider and
> replace the standard TZDB provider.
> * The replacement class cannot just be a clone of
> TzdbZoneRulesProvider because it needs access to a restricted
> deserialization API in java.time.zone.Ser. (The Java module system
> makes this hard to work around)
> * Because of the restricted deserialization API, I'd be concerned
> about startup time if construction had to go through the main public
> API of ZoneRules etc.
> * It is not possible to just add a second TZDB provider with a
> different version via the service loader. The current design is based
> on the idea that a provider owns all the zone identifiers it provides,
> and thus no other provider can supply the same zone identifiers.
> 
> The original code [1] looked for all files named tzdb.dat on the
> classpath, which allowed multiple versions to be loaded just by adding
> to the classpath. This ability was lost during integration, so there
> is a need to change the JDK code to find a way to get a modular jar to
> work well. It will need a bit of design work I suspect.
> 
> My desire is that updating tzdb should be as easy as updating any
> other maven artifact. One possible approach would be for the
> TzdbZoneRulesProvider to use a second service loader call to get the
> actual tzdb .dat files.
> 
> Stephen
> 
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ThreeTen_threetenbp_blob_master_src_main_java_org_threeten_bp_zone_TzdbZoneRulesProvider.java-23L158&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=9qQDqnSn7Ktdv8hydCo_Ax1DlUfEzXPHa5-LZ_rdwfo&s=x_imqjkXxxomzFanxuU_oU9QiiCZgai8U0EULWkAWIE&e=
> 
> 
> 
> On Mon, 2 Dec 2019 at 14:35, Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> wrote:
>>
>> Hi Sean,
>> Yes, I can see where you're going, it does seem more structured to
> define
>> an upgradeable module method... has anyone had a go at producing a
>> build/make mechanism to build one of those from the latest IANA data?
>> Could we modularise the current TzdbZoneRuleProvider into it's own
> module,
>> and then allow a openjdk make target to build just that with the latest
>> IANA and produce a upgradeable module replacement image for it...?
>> Thanks
>> Andrew
>>
>> Andrew Leonard
>> Java Runtimes Development
>> IBM Hursley
>> IBM United Kingdom Ltd
>> internet email: andrew_m_leonard at uk.ibm.com
>>
>>
>>
>>
>> From:   "Se?n Coffey" <sean.coffey at oracle.com>
>> To:     Alan Bateman <Alan.Bateman at oracle.com>, Andrew Leonard
>> <andrew_m_leonard at uk.ibm.com>
>> Cc:     jdk-dev <jdk-dev at openjdk.java.net>
>> Date:   02/12/2019 12:55
>> Subject:        [EXTERNAL] Re: TimeZone Updater Tool/Project, where
> would
>> we put it?
>>
>>
>>
>> I think Alan and Stephen Colebourne's comment may be on the right track
>> for this proposal.
>>
>> The current tzupdater process is due an upgrade in how it operates.
>> We've also considered open sourcing a similar version of our tzupdater
>> tool but felt that it needs to be modernized. We should move away from
>> updating specific internals (like the tzdb.dat file which is not part or
>> Java SE spec AFAIK). Similar concerns were made in 2016 when proposals
>> to control the location of tzdb.dat were raised [1]
>>
>> Moving to a service provider and/or upgradeable module solution may be a
>> good approach. At the moment,  JDK 8+ uses the
>> java.time.zone.ZoneRulesProvider class as the default service provider.
>> It can be substituted with use of the
>> `java.time.zone.DefaultZoneRulesProvider' system property.
>>
>> [1]
>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8153044-3FfocusedCommentId-3D13970444-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-253Acomment-2Dtabpanel-23comment-2D13970444&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=kUG0ybdJrp9uFosvwuDyIBKhr1b4R9POoYCFA81bk4c&s=0NmENnWxOJT5e40_QBVQp6lXE5NMyIALdG0ZYSw2dFw&e=
> 
>>
>>
>> Regards,
>> Sean.
>>
>> On 02/12/19 09:23, Alan Bateman wrote:
>>> On 29/11/2019 15:08, Andrew Leonard wrote:
>>>> The .zip contains the tzupdater "program" along with the latest
>>>> tzdb.dat.
>>>> The user then unzips this and runs the "program" in the desired
> "mode".
>>>> Currently, it distinguishes jdk8 from jdk11+ only, and the only
>>>> version update is that contained within the new tzdb.dat eg."2019c".
>>>> So you can run the tool in "discovery" mode which will simply print
>>>> out what tzdb version each JDK is at...
>>>> The basis of updating any jdk8,11,13,.. with the tzdb.dat is based
>>>> upon the fact that it's currently producing a "rearguard" tzdb.dat
>>>> which is compatible with all these versions... This would need
>>>> changing going forward when vanguard is used, and perhaps with that
>>>> in sight it maybe best to update the tool to only patch the same
>>>> versions from which the updater was built from...
>>>>
>>>> I can thus see several improvements being discussed here:
>>>> - Better JDK version detection
>>>> - Possibly provide release/version file update somewhere to identify
>>>> the update other than just in the tzdb.dat
>>>> - Make the tool "version" specific,ie. a jdk13 "updater.zip" will
>>>> only patch a jdk13 JDK.
>>> I assume "program" means something platform specific or maybe you mean
>>> a script?
>>>
>>> You haven't mentioned it yet but I assume it needs to update more than
>>> just tzdb. For JDK 9+ at least, it will need to update the TZ data in
>>> the packaged module (java.base.jmod) so that any replication with
>>> jlink will use the new TZ data too.
>>>
>>> There are lots of other questions but it might be better if you
>>> started a document to capture the needs, issues, and the possible
>>> technical approaches. That should help the discussion and help to see
>>> whether it make sense or not for something like this to be part of the
>>> JDK build or a separate patching tool.
>>>
>>> -Alan
>>
>>
>>
>>
>>
>> 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 mark.reinhold at oracle.com  Tue Dec  3 02:34:28 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 02 Dec 2019 18:34:28 -0800
Subject: JEP proposed to target JDK 14: 365: ZGC on Windows
In-Reply-To: <20191121232543.1F0FD30EF17@eggemoggin.niobe.net>
References: <20191121232543.1F0FD30EF17@eggemoggin.niobe.net>
Message-ID: <20191202183428.330921603@eggemoggin.niobe.net>

2019/11/21 15:25:43 -0800, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 14:
> 
>   365: ZGC on Windows
>        https://openjdk.java.net/jeps/365
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:30 UTC on Monday, 2 December, or if they?re raised and
> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> I?ll target this JEP to JDK 14.

Hearing no objections, I?ve targeted this JEP to JDK 14.

- Mark

From sean.coffey at oracle.com  Tue Dec  3 14:18:26 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 3 Dec 2019 14:18:26 +0000
Subject: TimeZone Updater Tool/Project, where would we put it?
In-Reply-To: <OF2D860818.D300D03E-ON002584C4.00741AE9-802584C4.00746C9F@notes.na.collabserv.com>
References: <OFAEE3F9B5.FE0FCF43-ON002584BD.0036E6E0-802584BD.00372D04@notes.na.collabserv.com>
 <CACzrW9DxU-xgr_UoKfxYSDoHuyE736o_dfT8XVJpfW+9G=AFyg@mail.gmail.com>
 <OFCDA8CD12.CD17FC03-ON002584C0.004FA6A4-802584C0.0056D25D@notes.na.collabserv.com>
 <6ebb0947-c169-1b4c-5408-f2edbd59f252@oracle.com>
 <OF2AB6BEDC.2F2FBBBC-ON002584C1.00526444-802584C1.00532B8F@notes.na.collabserv.com>
 <18c1d085-697e-b72e-c2bb-9fce29d17e78@oracle.com>
 <802293b8-07a5-1f42-319f-ade9a4cd4d5d@oracle.com>
 <OFA3FB7870.510810A6-ON002584C4.004F13C4-802584C4.004FF229@notes.na.collabserv.com>
 <CACzrW9CydW4uYgW1+sEfmpUfG3d_taAg3HZehCQr4YDAd9_J3A@mail.gmail.com>
 <OF2D860818.D300D03E-ON002584C4.00741AE9-802584C4.00746C9F@notes.na.collabserv.com>
Message-ID: <b00d63f8-941f-0c2f-795a-6581bc017036@oracle.com>

Hi Andrew,

Just to answer your earlier question, no - we haven't invested cycles in 
developing a new tzupdater tool just yet. As per other comments on this 
mail thread, it looks like a fair degree of work to get to a cleaner, 
more well designed tzupdater.

Regards,
Sean.

On 02/12/19 21:11, Andrew Leonard wrote:
> Hi Stephen,
> Thanks for your detailed test and description, you've highlighted some
> good issues here, which I don't think we've fully thought about, so that's
> great to discuss. I'll have a ponder on it, and discuss with my colleague.
> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
>
>
>
> From:   Stephen Colebourne <scolebourne at joda.org>
> To:     jdk-dev <jdk-dev at openjdk.java.net>
> Date:   02/12/2019 15:35
> Subject:        [EXTERNAL] Re: TimeZone Updater Tool/Project, where would
> we put it?
> Sent by:        "jdk-dev" <jdk-dev-bounces at openjdk.java.net>
>
>
>
> I've just tried adding a later tzdb file with the current setup.
>
> * It is possible to set -Djava.time.zone.DefaultZoneRulesProvider and
> replace the standard TZDB provider.
> * The replacement class cannot just be a clone of
> TzdbZoneRulesProvider because it needs access to a restricted
> deserialization API in java.time.zone.Ser. (The Java module system
> makes this hard to work around)
> * Because of the restricted deserialization API, I'd be concerned
> about startup time if construction had to go through the main public
> API of ZoneRules etc.
> * It is not possible to just add a second TZDB provider with a
> different version via the service loader. The current design is based
> on the idea that a provider owns all the zone identifiers it provides,
> and thus no other provider can supply the same zone identifiers.
>
> The original code [1] looked for all files named tzdb.dat on the
> classpath, which allowed multiple versions to be loaded just by adding
> to the classpath. This ability was lost during integration, so there
> is a need to change the JDK code to find a way to get a modular jar to
> work well. It will need a bit of design work I suspect.
>
> My desire is that updating tzdb should be as easy as updating any
> other maven artifact. One possible approach would be for the
> TzdbZoneRulesProvider to use a second service loader call to get the
> actual tzdb .dat files.
>
> Stephen
>
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ThreeTen_threetenbp_blob_master_src_main_java_org_threeten_bp_zone_TzdbZoneRulesProvider.java-23L158&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=9qQDqnSn7Ktdv8hydCo_Ax1DlUfEzXPHa5-LZ_rdwfo&s=x_imqjkXxxomzFanxuU_oU9QiiCZgai8U0EULWkAWIE&e=
>
>
>
> On Mon, 2 Dec 2019 at 14:35, Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> wrote:
>> Hi Sean,
>> Yes, I can see where you're going, it does seem more structured to
> define
>> an upgradeable module method... has anyone had a go at producing a
>> build/make mechanism to build one of those from the latest IANA data?
>> Could we modularise the current TzdbZoneRuleProvider into it's own
> module,
>> and then allow a openjdk make target to build just that with the latest
>> IANA and produce a upgradeable module replacement image for it...?
>> Thanks
>> Andrew
>>
>> Andrew Leonard
>> Java Runtimes Development
>> IBM Hursley
>> IBM United Kingdom Ltd
>> internet email: andrew_m_leonard at uk.ibm.com
>>
>>
>>
>>
>> From:   "Se?n Coffey" <sean.coffey at oracle.com>
>> To:     Alan Bateman <Alan.Bateman at oracle.com>, Andrew Leonard
>> <andrew_m_leonard at uk.ibm.com>
>> Cc:     jdk-dev <jdk-dev at openjdk.java.net>
>> Date:   02/12/2019 12:55
>> Subject:        [EXTERNAL] Re: TimeZone Updater Tool/Project, where
> would
>> we put it?
>>
>>
>>
>> I think Alan and Stephen Colebourne's comment may be on the right track
>> for this proposal.
>>
>> The current tzupdater process is due an upgrade in how it operates.
>> We've also considered open sourcing a similar version of our tzupdater
>> tool but felt that it needs to be modernized. We should move away from
>> updating specific internals (like the tzdb.dat file which is not part or
>> Java SE spec AFAIK). Similar concerns were made in 2016 when proposals
>> to control the location of tzdb.dat were raised [1]
>>
>> Moving to a service provider and/or upgradeable module solution may be a
>> good approach. At the moment,  JDK 8+ uses the
>> java.time.zone.ZoneRulesProvider class as the default service provider.
>> It can be substituted with use of the
>> `java.time.zone.DefaultZoneRulesProvider' system property.
>>
>> [1]
>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8153044-3FfocusedCommentId-3D13970444-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-253Acomment-2Dtabpanel-23comment-2D13970444&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=kUG0ybdJrp9uFosvwuDyIBKhr1b4R9POoYCFA81bk4c&s=0NmENnWxOJT5e40_QBVQp6lXE5NMyIALdG0ZYSw2dFw&e=
>
>>
>> Regards,
>> Sean.
>>
>> On 02/12/19 09:23, Alan Bateman wrote:
>>> On 29/11/2019 15:08, Andrew Leonard wrote:
>>>> The .zip contains the tzupdater "program" along with the latest
>>>> tzdb.dat.
>>>> The user then unzips this and runs the "program" in the desired
> "mode".
>>>> Currently, it distinguishes jdk8 from jdk11+ only, and the only
>>>> version update is that contained within the new tzdb.dat eg."2019c".
>>>> So you can run the tool in "discovery" mode which will simply print
>>>> out what tzdb version each JDK is at...
>>>> The basis of updating any jdk8,11,13,.. with the tzdb.dat is based
>>>> upon the fact that it's currently producing a "rearguard" tzdb.dat
>>>> which is compatible with all these versions... This would need
>>>> changing going forward when vanguard is used, and perhaps with that
>>>> in sight it maybe best to update the tool to only patch the same
>>>> versions from which the updater was built from...
>>>>
>>>> I can thus see several improvements being discussed here:
>>>> - Better JDK version detection
>>>> - Possibly provide release/version file update somewhere to identify
>>>> the update other than just in the tzdb.dat
>>>> - Make the tool "version" specific,ie. a jdk13 "updater.zip" will
>>>> only patch a jdk13 JDK.
>>> I assume "program" means something platform specific or maybe you mean
>>> a script?
>>>
>>> You haven't mentioned it yet but I assume it needs to update more than
>>> just tzdb. For JDK 9+ at least, it will need to update the TZ data in
>>> the packaged module (java.base.jmod) so that any replication with
>>> jlink will use the new TZ data too.
>>>
>>> There are lots of other questions but it might be better if you
>>> started a document to capture the needs, issues, and the possible
>>> technical approaches. That should help the discussion and help to see
>>> whether it make sense or not for something like this to be part of the
>>> JDK build or a separate patching tool.
>>>
>>> -Alan
>>
>>
>>
>>
>> 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 stuart.marks at oracle.com  Tue Dec  3 17:38:22 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 3 Dec 2019 09:38:22 -0800
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <68810382-2be7-851b-c57a-3b3f75f80e41@oracle.com>

Vote: yes

On 11/29/19 11:12 AM, Daniel Fuchs wrote:
> Hi,
> 
> I hereby nominate Julia Boes (jboes) to JDK Committer.
> 
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
> 
> Votes are due by 12:00 UTC December 14th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> 
> -- daniel
> 
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20 
> 
> 
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus

From mark.reinhold at oracle.com  Tue Dec  3 23:31:22 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue,  3 Dec 2019 15:31:22 -0800 (PST)
Subject: JEP proposed to target JDK 14: 362: Deprecate the Solaris and SPARC
 Ports
Message-ID: <20191203233122.09CA03102DB@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 14:

  362: Deprecate the Solaris and SPARC Ports
       https://openjdk.java.net/jeps/362

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Tuesday, 10 December, or if they?re raised
and then satisfactorily answered, then per the JEP 2.0 process proposal
[2] I?ll target this JEP to JDK 14.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From chris at noodles.org.uk  Wed Dec  4 18:02:30 2019
From: chris at noodles.org.uk (Chris Mason)
Date: Wed, 4 Dec 2019 18:02:30 +0000
Subject: HTTP/2 Support in com.sun.net.httpserver?
Message-ID: <CAKTM3kCfnpBkKCvd6CG2K_QkpgANvdS02=4mUF9n76OM70w0AQ@mail.gmail.com>

Hi,

Following the introduction of HTTP/2 Client support via JEP 110, are there
any plans to improve the implementation of HttpServer and HttpsServer in
com.sun.net.httpserver to support HTTP/2?

I know there are third party libraries which could be used (e.g. Undertow),
but as the internal httpserver implementation isn?t deprecated or marked
for removal, I assume it is staying around for a while. Especially as it
was updated with TLS 1.3 support in Java 9.

Regards,
Chris
-- 
Sent from my iPhone

From pavel.rappo at oracle.com  Wed Dec  4 18:18:49 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 4 Dec 2019 18:18:49 +0000
Subject: Fwd: HTTP/2 Support in com.sun.net.httpserver?
References: <CAKTM3kCfnpBkKCvd6CG2K_QkpgANvdS02=4mUF9n76OM70w0AQ@mail.gmail.com>
Message-ID: <44DD918F-89F2-4B5C-8C93-DAB1551B284E@oracle.com>

Forwarding to a more relevant mailing list. When answering, 
please remove jdk-dev from the list of recipients.

Thanks.

> Begin forwarded message:
> 
> From: Chris Mason <chris at noodles.org.uk>
> Subject: HTTP/2 Support in com.sun.net.httpserver?
> Date: 4 December 2019 at 18:02:30 GMT
> To: "jdk-dev at openjdk.java.net" <jdk-dev at openjdk.java.net>
> 
> Hi,
> 
> Following the introduction of HTTP/2 Client support via JEP 110, are there
> any plans to improve the implementation of HttpServer and HttpsServer in
> com.sun.net.httpserver to support HTTP/2?
> 
> I know there are third party libraries which could be used (e.g. Undertow),
> but as the internal httpserver implementation isn?t deprecated or marked
> for removal, I assume it is staying around for a while. Especially as it
> was updated with TLS 1.3 support in Java 9.
> 
> Regards,
> Chris
> -- 
> Sent from my iPhone


From michael.x.mcmahon at oracle.com  Thu Dec  5 14:17:17 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 5 Dec 2019 14:17:17 +0000
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <3b620564-24c9-b87c-ee54-4e0a3a8aa4bc@oracle.com>

Vote: Yes

On 29/11/2019 19:12, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Julia Boes (jboes) to JDK Committer.
>
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
>
> Votes are due by 12:00 UTC December 14th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
>
> -- daniel
>
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
>
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus

From vladimir.kozlov at oracle.com  Thu Dec  5 18:59:15 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 5 Dec 2019 10:59:15 -0800
Subject: CFV: New JDK Committer: Sandhya Viswanathan
Message-ID: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>

I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.

Sandhya is a long-term member of the Java team at Intel from the time when we start collaboration with Intel.

She contributed (and participated in) 14 OpenJDK changesets from which 8 are significant [3]. And she contributed when 
Intel was not part of OpenJDK - it is not listed here. Her work concentrated on x86 code generation, vectorization and 
intrinsics for modern Intel CPUs.

Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.

Only current JDK 9 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].

Regards,
Vladimir Kozlov

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

[3] Changesets list:

8222074: Enhance auto vectorization for x86
http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe

8215888: Register to register spill may use AVX 512 move instruction on unsupported platform.
http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41

8211251: Default mask register for avx512 instructions
http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22

8210764: Update avx512 implementation
http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371

8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour
http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160

8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103

8141132: JEP 254: Compact Strings
http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8

8081778: Use Intel x64 CPU instructions for RSA acceleration
http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1

From vladimir.kozlov at oracle.com  Thu Dec  5 19:02:24 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 5 Dec 2019 11:02:24 -0800
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <4de4429c-63a7-a988-56cb-abd8883eb752@oracle.com>

Vote: yes

On 12/5/19 10:59 AM, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
> 
> Sandhya is a long-term member of the Java team at Intel from the time when we start collaboration with Intel.
> 
> She contributed (and participated in) 14 OpenJDK changesets from which 8 are significant [3]. And she contributed when 
> Intel was not part of OpenJDK - it is not listed here. Her work concentrated on x86 code generation, vectorization and 
> intrinsics for modern Intel CPUs.
> 
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
> 
> Only current JDK 9 Committers [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying 

Should be 'JDK'. It was long time since I nominated someone ;)

> to this mailing list. >
> For Lazy Consensus voting instructions, see [2].
> 
> Regards,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> [3] Changesets list:
> 
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
> 
> 8215888: Register to register spill may use AVX 512 move instruction on unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
> 
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
> 
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
> 
> 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
> 
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
> 
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
> 
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1

From adinn at redhat.com  Thu Dec  5 19:16:11 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 5 Dec 2019 19:16:11 +0000
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <4de4429c-63a7-a988-56cb-abd8883eb752@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
 <4de4429c-63a7-a988-56cb-abd8883eb752@oracle.com>
Message-ID: <d91696be-ba25-4707-b58a-4c7092675adc@redhat.com>

Vote: yes

On 05/12/2019 19:02, Vladimir Kozlov wrote:
> Vote: yes
> 
> On 12/5/19 10:59 AM, Vladimir Kozlov wrote:
>> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
>>
>> Sandhya is a long-term member of the Java team at Intel from the time
>> when we start collaboration with Intel.
>>
>> She contributed (and participated in) 14 OpenJDK changesets from which
>> 8 are significant [3]. And she contributed when Intel was not part of
>> OpenJDK - it is not listed here. Her work concentrated on x86 code
>> generation, vectorization and intrinsics for modern Intel CPUs.
>>
>> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
>>
>> Only current JDK 9 Committers [1] are eligible to vote on this
>> nomination.? Votes must be cast in the open by replying 
> 
> Should be 'JDK'. It was long time since I nominated someone ;)
> 
>> to this mailing list. >
>> For Lazy Consensus voting instructions, see [2].
>>
>> Regards,
>> Vladimir Kozlov
>>
>> [1] http://openjdk.java.net/census
>> [2] http://openjdk.java.net/projects/#committer-vote
>>
>> [3] Changesets list:
>>
>> 8222074: Enhance auto vectorization for x86
>> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
>>
>> 8215888: Register to register spill may use AVX 512 move instruction
>> on unsupported platform.
>> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
>>
>> 8211251: Default mask register for avx512 instructions
>> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
>>
>> 8210764: Update avx512 implementation
>> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
>>
>> 8020860: cluster Hashtable/Vector field updates for better
>> transactional memory behaviour
>> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
>>
>> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage
>> Collector (Experimental)
>> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
>>
>> 8141132: JEP 254: Compact Strings
>> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
>>
>> 8081778: Use Intel x64 CPU instructions for RSA acceleration
>> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1
> 

-- 
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


From Alan.Bateman at oracle.com  Thu Dec  5 19:29:26 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 5 Dec 2019 19:29:26 +0000
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <ca11c1ef-0d07-0d48-1077-963000754cf0@oracle.com>

Vote: yes

From hohensee at amazon.com  Thu Dec  5 20:51:56 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 5 Dec 2019 20:51:56 +0000
Subject: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <CD89C607-1F13-4020-9B56-9867A06C16C4@amazon.com>

Vote: yes

?On 12/5/19, 11:00 AM, "jdk-dev on behalf of Vladimir Kozlov" <jdk-dev-bounces at openjdk.java.net on behalf of vladimir.kozlov at oracle.com> wrote:

    I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
    
    Sandhya is a long-term member of the Java team at Intel from the time when we start collaboration with Intel.
    
    She contributed (and participated in) 14 OpenJDK changesets from which 8 are significant [3]. And she contributed when 
    Intel was not part of OpenJDK - it is not listed here. Her work concentrated on x86 code generation, vectorization and 
    intrinsics for modern Intel CPUs.
    
    Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
    
    Only current JDK 9 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].
    
    Regards,
    Vladimir Kozlov
    
    [1] http://openjdk.java.net/census
    [2] http://openjdk.java.net/projects/#committer-vote
    
    [3] Changesets list:
    
    8222074: Enhance auto vectorization for x86
    http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
    
    8215888: Register to register spill may use AVX 512 move instruction on unsupported platform.
    http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
    
    8211251: Default mask register for avx512 instructions
    http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
    
    8210764: Update avx512 implementation
    http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
    
    8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour
    http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
    
    8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
    http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
    
    8141132: JEP 254: Compact Strings
    http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
    
    8081778: Use Intel x64 CPU instructions for RSA acceleration
    http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1
    


From gromero at linux.vnet.ibm.com  Thu Dec  5 21:01:52 2019
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Thu, 5 Dec 2019 18:01:52 -0300
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <5dd71232-deca-1e65-ce63-d7b2e26d081b@linux.vnet.ibm.com>

Vote: yes

On 12/05/2019 03:59 PM, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
> 
> Sandhya is a long-term member of the Java team at Intel from the time when we start collaboration with Intel.
> 
> She contributed (and participated in) 14 OpenJDK changesets from which 8 are significant [3]. And she contributed when Intel was not part of OpenJDK - it is not listed here. Her work concentrated on x86 code generation, vectorization and intrinsics for modern Intel CPUs.
> 
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
> 
> Only current JDK 9 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].
> 
> Regards,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> [3] Changesets list:
> 
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
> 
> 8215888: Register to register spill may use AVX 512 move instruction on unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
> 
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
> 
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
> 
> 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
> 
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
> 
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
> 
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1

From vladimir.x.ivanov at oracle.com  Thu Dec  5 21:42:39 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 6 Dec 2019 00:42:39 +0300
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <33f9641b-3108-398f-8db2-07f86bbe4e48@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

On 05.12.2019 21:59, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.

From paul.sandoz at oracle.com  Thu Dec  5 22:10:08 2019
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 5 Dec 2019 14:10:08 -0800
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <6EDE988A-6DD6-45E4-BCCB-2C44306B45AE@oracle.com>

Vote: yes

From mark.reinhold at oracle.com  Thu Dec  5 22:31:09 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  5 Dec 2019 14:31:09 -0800 (PST)
Subject: JEP proposed to target JDK 14: 370: Foreign-Memory Access API
 (Incubator)
Message-ID: <20191205223109.63BFB3107AA@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 14:

  370: Foreign-Memory Access API (Incubator)
       https://openjdk.java.net/jeps/370

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:00 UTC on Thursday, 12 December, or if they?re raised
and then satisfactorily answered, then per the JEP 2.0 process proposal
[2] I?ll target this JEP to JDK 14.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Thu Dec  5 22:46:29 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  5 Dec 2019 14:46:29 -0800 (PST)
Subject: JDK 14 enters Rampdown Phase One next week
Message-ID: <20191205224629.73B5C3107B8@eggemoggin.niobe.net>

JDK 14 enters Rampdown Phase One next week, on Thursday, 12 December.
Changes intended for JDK 14 should be in the main-line repository
(https://hg.openjdk.java.net/jdk/jdk) by 16:00 UTC on that day [1].

At that time we?ll fork jdk/jdk to the JDK 14 stabilization repository,
jdk/jdk14, and promote next week?s build (jdk-14+27) and all remaining
JDK 14 builds from there.

We'll semi-automatically merge changes pushed to jdk/jdk14 into the
main-line jdk/jdk repository, as we have in previous feature-release
transitions.  This means that:

  - If you make a change in JDK 14 then you needn't do any extra
    work to get it into the main line, though if a merge conflict
    arises then you might be asked to help resolve it.

  - If you need to make a change in both JDK 14 and the main line
    then just push it to JDK 14, and wait for the automatic merge
    to complete.

Changes pushed to jdk/jdk after 16:00 UTC next Thursday will be bound
for JDK 15 only, unless they're back-ported.

The jdk/submit repo will continue to be for main-line (jdk/jdk) work.
We?ll set up a jdk/submit14 repo for jdk/jdk14 work.

The Rampdown Phase One process is defined in JEP 3 [2].

- Mark


[1] https://time.is/1600_12_Dec_2019_in_UTC?JDK_14_Rampdown_Phase_One
[2] https://openjdk.java.net/jeps/3

From anthony.scarpino at oracle.com  Fri Dec  6 00:34:11 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 5 Dec 2019 16:34:11 -0800
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <d530024e-edde-4c60-b896-214e329c0670@oracle.com>

Vote: yes

On 12/5/19 10:59 AM, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
> 
> Sandhya is a long-term member of the Java team at Intel from the time 
> when we start collaboration with Intel.
> 
> She contributed (and participated in) 14 OpenJDK changesets from which 8 
> are significant [3]. And she contributed when Intel was not part of 
> OpenJDK - it is not listed here. Her work concentrated on x86 code 
> generation, vectorization and intrinsics for modern Intel CPUs.
> 
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
> 
> Only current JDK 9 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].
> 
> Regards,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> [3] Changesets list:
> 
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
> 
> 8215888: Register to register spill may use AVX 512 move instruction on 
> unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
> 
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
> 
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
> 
> 8020860: cluster Hashtable/Vector field updates for better transactional 
> memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
> 
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage 
> Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
> 
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
> 
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1


From jeremy.kuhn1 at gmail.com  Fri Dec  6 00:01:38 2019
From: jeremy.kuhn1 at gmail.com (Jeremy Kuhn)
Date: Fri, 6 Dec 2019 01:01:38 +0100
Subject: Annotation Processing issues on modules
Message-ID: <CAOMtk7heu+ad+dMEMCZObLK-sjaY+=SsZ5JQZbMrC_Ed5pofhw@mail.gmail.com>

Hi,

I've been working lately on an IoC/DI framework for Java 9+ which relies on
annotation processing and code generation. I'm actually defining
annotations on modules and I discovered couple of bugs during the
processing of these annotations in the Java compiler.

The first one is when we want to print a compilation message targeting a
module's annotation, it exists on all versions since JDK 9. Let's say we
have the following module descriptor:

    @SampleAnnotation
    module sampleModule {

    }

and a properly configured annotation processor to process the
@SampleAnnotation, if we do:

    this.processingEnv.getMessager().printMessage(Kind.MANDATORY_WARNING,
"Module warning", element, annotationMirror);

where element corresponds to the sampleModule and annotationMirror to the
@SampleAnnotation, the compiler crash with a java.lang.AssertionError:

An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.AssertionError
     at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
     at
jdk.compiler/com.sun.tools.javac.tree.JCTree$Visitor.visitTree(JCTree.java:3235)
     at
jdk.compiler/com.sun.tools.javac.tree.JCTree$Visitor.visitModuleDef(JCTree.java:3227)
     at
jdk.compiler/com.sun.tools.javac.tree.JCTree$JCModuleDecl.accept(JCTree.java:2780)
     at
jdk.compiler/com.sun.tools.javac.model.JavacElements.matchAnnoToTree(JavacElements.java:298)
     at
jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:743)
     at
jdk.compiler/com.sun.tools.javac.processing.JavacMessager.printMessage(JavacMessager.java:108)
     at
jdk.compiler/com.sun.tools.javac.processing.JavacMessager.printMessage(JavacMessager.java:87)
     at
processor/com.example.processor.ModuleWarnProcessor.lambda$process$1(ModuleWarnProcessor.java:21)
     at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
     at
java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
     at
java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
     at
java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
     at
java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
     at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
     at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
     at
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
     at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
     at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
     at
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
     at
processor/com.example.processor.ModuleWarnProcessor.process(ModuleWarnProcessor.java:19)
     at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1023)
     at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:939)
     at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1267)
     at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1381)
     at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1263)
     at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:935)
     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318)
     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
     at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
     at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)

I've been able to track down the issue in
com.sun.tools.javac.model.JavacElements#matchAnnoToTree(), the Vis class
does not implement the visitModuleDef() method and as a result it is not
possible to find module's annotations hence the AssertionError.

The second issue occurs when you want to use imports in a module-info.java
file, if you do so the file is simply ignored during annotation processing.
This issue also exists on all versions since JDK 9. Let's say we have the
following module descriptor:

    import com.example.SampleAnnotation;

    @SampleAnnotation
    module sampleModule {

    }

and a properly configured annotation processor to process the
@com.example.SampleAnnotation, the compiler simply doesn't take the module
into account when processing annotation.

I've been able to track down the issue in
com.sun.tools.javac.processing.JavacProcessingEnvironment#getModuleInfoFiles()

    private List<ModuleSymbol> getModuleInfoFiles(List<? extends
JCCompilationUnit> units) {
        List<ModuleSymbol> modules = List.nil();
        for (JCCompilationUnit unit : units) {
            if (isModuleInfo(unit.sourcefile, JavaFileObject.Kind.SOURCE) &&
                unit.defs.nonEmpty() &&
                unit.defs.head.hasTag(Tag.MODULEDEF)) {
                modules = modules.prepend(unit.modle);
            }
        }
        return modules.reverse();
    }

Here it is assumed that the first unit in a module descriptor has to be a
module statement however according to the java language specification, a
module descriptor can have import statements before (and this actually
compiles just fine) as a result the module is not added to the list of
modules candidates for annotation processing.

I've also found another more tricky one which relates to the usage of
deprecated module in the module providing the annotation processor: if we
create a module which depends on a jdk deprecated module and which provides
an annotation processor, having that module on the processor module path
will make the compiler to return with nothing compiled, no error and no
output. I didn't dig too much into this as this only impacts jdk9 which
comes with deprecated modules (eg. java.se.ee), later versions don't have
any issues for now. I've stopped my investigation in the
java.lang.module.Resolver class line 181, deprecated modules are actually
not resolved.

I have prepared patches with jtreg tests for the first two issues on the
repository head and I'd be happy to submit them. Please let me know if the
description of the issues is clear enough and how we can proceed to fix
them, I've already signed the OCA.

Jeremy

From david.holmes at oracle.com  Fri Dec  6 01:29:31 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Dec 2019 11:29:31 +1000
Subject: Annotation Processing issues on modules
In-Reply-To: <CAOMtk7heu+ad+dMEMCZObLK-sjaY+=SsZ5JQZbMrC_Ed5pofhw@mail.gmail.com>
References: <CAOMtk7heu+ad+dMEMCZObLK-sjaY+=SsZ5JQZbMrC_Ed5pofhw@mail.gmail.com>
Message-ID: <7aa9a0bf-2e5d-26b3-4ce3-c4b8288dad5f@oracle.com>

Hi Jeremy,

Please take this to the compiler-dev at openjdk.java.net mailing list. [1]

Thanks,
David

[1] https://mail.openjdk.java.net/mailman/listinfo/compiler-dev

On 6/12/2019 10:01 am, Jeremy Kuhn wrote:
> Hi,
> 
> I've been working lately on an IoC/DI framework for Java 9+ which relies on
> annotation processing and code generation. I'm actually defining
> annotations on modules and I discovered couple of bugs during the
> processing of these annotations in the Java compiler.
> 
> The first one is when we want to print a compilation message targeting a
> module's annotation, it exists on all versions since JDK 9. Let's say we
> have the following module descriptor:
> 
>      @SampleAnnotation
>      module sampleModule {
> 
>      }
> 
> and a properly configured annotation processor to process the
> @SampleAnnotation, if we do:
> 
>      this.processingEnv.getMessager().printMessage(Kind.MANDATORY_WARNING,
> "Module warning", element, annotationMirror);
> 
> where element corresponds to the sampleModule and annotationMirror to the
> @SampleAnnotation, the compiler crash with a java.lang.AssertionError:
> 
> An annotation processor threw an uncaught exception.
> Consult the following stack trace for details.
> java.lang.AssertionError
>       at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>       at
> jdk.compiler/com.sun.tools.javac.tree.JCTree$Visitor.visitTree(JCTree.java:3235)
>       at
> jdk.compiler/com.sun.tools.javac.tree.JCTree$Visitor.visitModuleDef(JCTree.java:3227)
>       at
> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCModuleDecl.accept(JCTree.java:2780)
>       at
> jdk.compiler/com.sun.tools.javac.model.JavacElements.matchAnnoToTree(JavacElements.java:298)
>       at
> jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:743)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacMessager.printMessage(JavacMessager.java:108)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacMessager.printMessage(JavacMessager.java:87)
>       at
> processor/com.example.processor.ModuleWarnProcessor.lambda$process$1(ModuleWarnProcessor.java:21)
>       at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>       at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>       at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>       at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
>       at
> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
>       at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>       at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>       at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>       at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>       at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>       at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>       at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>       at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
>       at
> processor/com.example.processor.ModuleWarnProcessor.process(ModuleWarnProcessor.java:19)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1023)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:939)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1267)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1381)
>       at
> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1263)
>       at
> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:935)
>       at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318)
>       at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>       at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>       at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
> 
> I've been able to track down the issue in
> com.sun.tools.javac.model.JavacElements#matchAnnoToTree(), the Vis class
> does not implement the visitModuleDef() method and as a result it is not
> possible to find module's annotations hence the AssertionError.
> 
> The second issue occurs when you want to use imports in a module-info.java
> file, if you do so the file is simply ignored during annotation processing.
> This issue also exists on all versions since JDK 9. Let's say we have the
> following module descriptor:
> 
>      import com.example.SampleAnnotation;
> 
>      @SampleAnnotation
>      module sampleModule {
> 
>      }
> 
> and a properly configured annotation processor to process the
> @com.example.SampleAnnotation, the compiler simply doesn't take the module
> into account when processing annotation.
> 
> I've been able to track down the issue in
> com.sun.tools.javac.processing.JavacProcessingEnvironment#getModuleInfoFiles()
> 
>      private List<ModuleSymbol> getModuleInfoFiles(List<? extends
> JCCompilationUnit> units) {
>          List<ModuleSymbol> modules = List.nil();
>          for (JCCompilationUnit unit : units) {
>              if (isModuleInfo(unit.sourcefile, JavaFileObject.Kind.SOURCE) &&
>                  unit.defs.nonEmpty() &&
>                  unit.defs.head.hasTag(Tag.MODULEDEF)) {
>                  modules = modules.prepend(unit.modle);
>              }
>          }
>          return modules.reverse();
>      }
> 
> Here it is assumed that the first unit in a module descriptor has to be a
> module statement however according to the java language specification, a
> module descriptor can have import statements before (and this actually
> compiles just fine) as a result the module is not added to the list of
> modules candidates for annotation processing.
> 
> I've also found another more tricky one which relates to the usage of
> deprecated module in the module providing the annotation processor: if we
> create a module which depends on a jdk deprecated module and which provides
> an annotation processor, having that module on the processor module path
> will make the compiler to return with nothing compiled, no error and no
> output. I didn't dig too much into this as this only impacts jdk9 which
> comes with deprecated modules (eg. java.se.ee), later versions don't have
> any issues for now. I've stopped my investigation in the
> java.lang.module.Resolver class line 181, deprecated modules are actually
> not resolved.
> 
> I have prepared patches with jtreg tests for the first two issues on the
> repository head and I'd be happy to submit them. Please let me know if the
> description of the issues is clear enough and how we can proceed to fix
> them, I've already signed the OCA.
> 
> Jeremy
> 

From jonathan.gibbons at oracle.com  Fri Dec  6 01:22:44 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 5 Dec 2019 17:22:44 -0800
Subject: Annotation Processing issues on modules
In-Reply-To: <CAOMtk7heu+ad+dMEMCZObLK-sjaY+=SsZ5JQZbMrC_Ed5pofhw@mail.gmail.com>
References: <CAOMtk7heu+ad+dMEMCZObLK-sjaY+=SsZ5JQZbMrC_Ed5pofhw@mail.gmail.com>
Message-ID: <7d2c482f-81fb-2e3c-6476-8a70cff28978@oracle.com>

Forwarding to compiler-dev; dropping jdk-dev.

-- Jon


On 12/05/2019 04:01 PM, Jeremy Kuhn wrote:
> Hi,
>
> I've been working lately on an IoC/DI framework for Java 9+ which relies on
> annotation processing and code generation. I'm actually defining
> annotations on modules and I discovered couple of bugs during the
> processing of these annotations in the Java compiler.
>
> The first one is when we want to print a compilation message targeting a
> module's annotation, it exists on all versions since JDK 9. Let's say we
> have the following module descriptor:
>
>      @SampleAnnotation
>      module sampleModule {
>
>      }
>
> and a properly configured annotation processor to process the
> @SampleAnnotation, if we do:
>
>      this.processingEnv.getMessager().printMessage(Kind.MANDATORY_WARNING,
> "Module warning", element, annotationMirror);
>
> where element corresponds to the sampleModule and annotationMirror to the
> @SampleAnnotation, the compiler crash with a java.lang.AssertionError:
>
> An annotation processor threw an uncaught exception.
> Consult the following stack trace for details.
> java.lang.AssertionError
>       at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>       at
> jdk.compiler/com.sun.tools.javac.tree.JCTree$Visitor.visitTree(JCTree.java:3235)
>       at
> jdk.compiler/com.sun.tools.javac.tree.JCTree$Visitor.visitModuleDef(JCTree.java:3227)
>       at
> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCModuleDecl.accept(JCTree.java:2780)
>       at
> jdk.compiler/com.sun.tools.javac.model.JavacElements.matchAnnoToTree(JavacElements.java:298)
>       at
> jdk.compiler/com.sun.tools.javac.model.JavacElements.getTreeAndTopLevel(JavacElements.java:743)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacMessager.printMessage(JavacMessager.java:108)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacMessager.printMessage(JavacMessager.java:87)
>       at
> processor/com.example.processor.ModuleWarnProcessor.lambda$process$1(ModuleWarnProcessor.java:21)
>       at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>       at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>       at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>       at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
>       at
> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
>       at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>       at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>       at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>       at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>       at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>       at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>       at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>       at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
>       at
> processor/com.example.processor.ModuleWarnProcessor.process(ModuleWarnProcessor.java:19)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1023)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:939)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1267)
>       at
> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1381)
>       at
> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1263)
>       at
> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:935)
>       at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318)
>       at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>       at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>       at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>
> I've been able to track down the issue in
> com.sun.tools.javac.model.JavacElements#matchAnnoToTree(), the Vis class
> does not implement the visitModuleDef() method and as a result it is not
> possible to find module's annotations hence the AssertionError.
>
> The second issue occurs when you want to use imports in a module-info.java
> file, if you do so the file is simply ignored during annotation processing.
> This issue also exists on all versions since JDK 9. Let's say we have the
> following module descriptor:
>
>      import com.example.SampleAnnotation;
>
>      @SampleAnnotation
>      module sampleModule {
>
>      }
>
> and a properly configured annotation processor to process the
> @com.example.SampleAnnotation, the compiler simply doesn't take the module
> into account when processing annotation.
>
> I've been able to track down the issue in
> com.sun.tools.javac.processing.JavacProcessingEnvironment#getModuleInfoFiles()
>
>      private List<ModuleSymbol> getModuleInfoFiles(List<? extends
> JCCompilationUnit> units) {
>          List<ModuleSymbol> modules = List.nil();
>          for (JCCompilationUnit unit : units) {
>              if (isModuleInfo(unit.sourcefile, JavaFileObject.Kind.SOURCE) &&
>                  unit.defs.nonEmpty() &&
>                  unit.defs.head.hasTag(Tag.MODULEDEF)) {
>                  modules = modules.prepend(unit.modle);
>              }
>          }
>          return modules.reverse();
>      }
>
> Here it is assumed that the first unit in a module descriptor has to be a
> module statement however according to the java language specification, a
> module descriptor can have import statements before (and this actually
> compiles just fine) as a result the module is not added to the list of
> modules candidates for annotation processing.
>
> I've also found another more tricky one which relates to the usage of
> deprecated module in the module providing the annotation processor: if we
> create a module which depends on a jdk deprecated module and which provides
> an annotation processor, having that module on the processor module path
> will make the compiler to return with nothing compiled, no error and no
> output. I didn't dig too much into this as this only impacts jdk9 which
> comes with deprecated modules (eg. java.se.ee), later versions don't have
> any issues for now. I've stopped my investigation in the
> java.lang.module.Resolver class line 181, deprecated modules are actually
> not resolved.
>
> I have prepared patches with jtreg tests for the first two issues on the
> repository head and I'd be happy to submit them. Please let me know if the
> description of the issues is clear enough and how we can proceed to fix
> them, I've already signed the OCA.
>
> Jeremy


From tobias.hartmann at oracle.com  Fri Dec  6 08:27:27 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 6 Dec 2019 09:27:27 +0100
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <ecf94884-f0d2-0046-d57f-1ccc29c481a1@oracle.com>

Vote: yes

Best regards,
Tobias

On 05.12.19 19:59, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
> 
> Sandhya is a long-term member of the Java team at Intel from the time when we start collaboration
> with Intel.
> 
> She contributed (and participated in) 14 OpenJDK changesets from which 8 are significant [3]. And
> she contributed when Intel was not part of OpenJDK - it is not listed here. Her work concentrated on
> x86 code generation, vectorization and intrinsics for modern Intel CPUs.
> 
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
> 
> Only current JDK 9 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].
> 
> Regards,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> [3] Changesets list:
> 
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
> 
> 8215888: Register to register spill may use AVX 512 move instruction on unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
> 
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
> 
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
> 
> 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
> 
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
> 
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
> 
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1

From dalibor.topic at oracle.com  Fri Dec  6 10:09:21 2019
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 6 Dec 2019 11:09:21 +0100
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <33f9641b-3108-398f-8db2-07f86bbe4e48@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
 <33f9641b-3108-398f-8db2-07f86bbe4e48@oracle.com>
Message-ID: <3a7e0007-e9b6-4f63-4a7e-96d8455ca25f@oracle.com>

Vote: yes.

On 05.12.2019 22:42, Vladimir Ivanov wrote:
> Vote: yes
> 
> Best regards,
> Vladimir Ivanov
> 
> On 05.12.2019 21:59, Vladimir Kozlov wrote:
>> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.

-- 
<http://www.oracle.com>
Dalibor Topic | Consulting Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961> | Video: dalibor.topic at oracle.com
<sip:dalibor.topic at oracle.com>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From martin.doerr at sap.com  Fri Dec  6 10:12:35 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 6 Dec 2019 10:12:35 +0000
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <5dd71232-deca-1e65-ce63-d7b2e26d081b@linux.vnet.ibm.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
 <5dd71232-deca-1e65-ce63-d7b2e26d081b@linux.vnet.ibm.com>
Message-ID: <AM0PR0202MB3297E947E1F64A09893122E99A5F0@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Vote: yes

Best regards,
Martin


From goetz.lindenmaier at sap.com  Fri Dec  6 11:34:33 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 6 Dec 2019 11:34:33 +0000
Subject: JDK-8029528
In-Reply-To: <7EC26C87-AB75-4267-B437-E32379E87F35@oracle.com>
References: <b2a87064afb8501cfec45d0541879bc811dc1180.camel@redhat.com>
 <5DECDC70-8409-415D-A2DB-B3BD4DDE9FBA@oracle.com>
 <AM6PR02MB534724AD915BD5387B8B7DF3EC630@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <A01E0316-0AB4-4E06-8AD6-5197BAF40BD2@oracle.com>
 <AM6PR02MB53470F3B3803D81786F015C8EC630@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <9ddd5fac-42bb-c910-4498-07f173402c26@oracle.com>
 <AM6PR02MB5347B8573CF5282E72686C9EEC7F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <7EC26C87-AB75-4267-B437-E32379E87F35@oracle.com>
Message-ID: <AM6PR02MB534762BB3E2CDAC92EFF2BA3EC5F0@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi,

I just saw that "8234267: DelegationPermission implementation doesn't completely follow the updated specification"
https://hg.openjdk.java.net/jdk/jdk/rev/18420160287b
was pushed with a closed bug. 

Is it possible to open this one up?

(Would it be possible to extend jcheck to reject closed bugs in jdk/jdk?)

Best regards,
  Goetz.

> -----Original Message-----
> From: jesper.wilhelmsson at oracle.com <jesper.wilhelmsson at oracle.com>
> Sent: Montag, 4. November 2019 18:06
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Ioi Lam <ioi.lam at oracle.com>; jdk-dev at openjdk.java.net
> Subject: Re: JDK-8029528
> 
> We have an internal policy saying that any change in the open code should
> have an open JBS issue, so in theory there shouldn't be any reviews for closed
> issues on the open lists. If this is happening (enough to be a problem) I'd be
> happy to take that discussion internally, so please let me know.
> 
> As for closed bug ids in the problemList this is mainly the result of issues that
> was moved from closed problemList to open as part of opening different
> features like JFR, ZGC and others. These bugs should be opened a far as it is
> possible. I think creating a new open bug and close the old one as a duplicate is
> a good solution if the old bug can't be opened.
> 
> /Jesper
> 
> > On 4 Nov 2019, at 10:14, Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> wrote:
> >
> > Hi,
> >
> > If a fix for the closed bug is pushed under the "mirror" bug
> > in first place, no open source developer will ever run into
> > the bug id of the closed bug.  Similar for entries in the
> > ProblemLists.
> >
> > As reviews are in the open, reviewers could demand to
> > open a "mirror" bug before a change is pushed.
> >
> > Best regards,
> >  Goetz.
> >
> >> -----Original Message-----
> >> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Ioi Lam
> >> Sent: Donnerstag, 31. Oktober 2019 23:24
> >> To: jdk-dev at openjdk.java.net
> >> Subject: Re: JDK-8029528
> >>
> >> For this to work (smoothly), we would also need a mechanism that
> >> automatically redirects from the closed bug to the new "mirror" bug (for
> >> users that don't have access to closed bugs). Otherwise, you will still
> >> be staring at a "this bug is not accessible" page scratching your head.
> >>
> >> Thanks
> >> - Ioi
> >>
> >> On 10/31/19 6:04 AM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> this could be a general way to deal with bugs you
> >>> can not make public.  Editing the text of the bug
> >>> is not possible as you are saying, but that is not the
> >>> only way to make such a bug public.
> >>>
> >>> Also, us non-Oracle reviewers should watch out that no
> >>> closed bugs are mentioned in the ProblemLists. And
> >>> maybe no closed bugs should be pushed, Oracle could
> >>> always open a "mirror-bug" just describing the problem
> >>> and the fix.
> >>>
> >>> And no, me personally, I'm not working on this special
> >>> bug currently.
> >>>
> >>> Best regrards,
> >>>   Goetz.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: jesper.wilhelmsson at oracle.com
> <jesper.wilhelmsson at oracle.com>
> >>>> Sent: Donnerstag, 31. Oktober 2019 13:14
> >>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >>>> Cc: Severin Gehwolf <sgehwolf at redhat.com>; jdk-dev <jdk-
> >>>> dev at openjdk.java.net>
> >>>> Subject: Re: JDK-8029528
> >>>>
> >>>> Is there anything in particular with this bug that motivates the extra
> work,
> >> or
> >>>> do you mean in general for all bugs like this?
> >>>> /Jesper
> >>>>
> >>>>> On 31 Oct 2019, at 10:16, Lindenmaier, Goetz
> >> <goetz.lindenmaier at sap.com>
> >>>> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> you could open a new bug with the non-sensitive information.
> >>>>> Add the hidden bug as duplicate and close it.
> >>>>> Then reference the public bug in the exclude list.
> >>>>>
> >>>>> Best regards,
> >>>>>  Goetz.
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
> >>>>>> jesper.wilhelmsson at oracle.com
> >>>>>> Sent: Mittwoch, 30. Oktober 2019 19:08
> >>>>>> To: Severin Gehwolf <sgehwolf at redhat.com>
> >>>>>> Cc: jdk-dev <jdk-dev at openjdk.java.net>
> >>>>>> Subject: Re: JDK-8029528
> >>>>>>
> >>>>>>> On 30 Oct 2019, at 17:22, Severin Gehwolf <sgehwolf at redhat.com>
> >>>> wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Is there a good reason why JDK-8029528 isn't visible? It's a bug
> >>>>>>> referenced in ProblemList.txt[1] and I'd like to see some details. If
> >>>>>>> at all possible, could it be made public?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Severin
> >>>>>>>
> >>>>>>> [1]
> >>>>
> >>
> http://hg.openjdk.java.net/jdk/jdk/file/2c3cc4b01880/test/hotspot/jtreg/Prob
> >>>>>> lemList.txt#l43
> >>>>>>
> >>>>>> I've said it over and over, year after year, I've written it in our process
> >>>>>> documentation, I've communicated it through emails: Never ever put
> any
> >>>>>> confidential information in the description of a bug. Regardless if the
> bug
> >>>>>> concerns a closed feature or internal tests - at some point in the future
> >> we
> >>>>>> might want to open the bug. If I've had a dime for every time I was
> right I
> >>>>>> would finally get my first dime.
> >>>>>>
> >>>>>> The bug was filed in 2013, it's about JFR which at the time was an
> Oracle
> >>>>>> internal feature. As JFR has been open sourced I'd be happy to open the
> >> bug,
> >>>>>> but the description of the bug contains confidential information (for no
> >>>> good
> >>>>>> reason, as always). There is no point in cleaning up the description
> since
> >> the
> >>>> old
> >>>>>> description will still be available in the history of the bug.
> >>>>>>
> >>>>>> I'll share the bulk of the details below, let me know if you need more.
> >>>>>>
> >>>>>> JDK-8029528 - compiler/ciReplay/TestSA.sh fails: Error while parsing
> line
> >>>> 1002:
> >>>>>> unknown command
> >>>>>> Type: Bug
> >>>>>> Priority: P5
> >>>>>> Affects: hs25, 8, 9, 10
> >>>>>> Fix version: tbd
> >>>>>> Conponent: hotspot / svc-sgent
> >>>>>> OS: linux (comment below indicate that this is not only linux though)
> >>>>>>
> >>>>>> Description:
> >>>>>> This test failure was spotted in the 2013.12.03 RT_Baseline nightly
> >>>>>>
> >>>>>> JDK: Java(TM) SE Runtime Environment 1.8.0 b118 (1.8.0-ea-
> fastdebug-
> >>>> b118)
> >>>>>> VM: Java HotSpot(TM) 64-Bit Server VM 25.0 b62 (25.0-b62-internal-
> >>>>>> 201312032153.sspitsyn.hotspot-fastdebug)
> >>>>>>
> >>>>>> compiler/ciReplay/TestSA.sh
> >>>>>>
> >>>>>> Tests fails because of the following error:
> >>>>>>
> >>>>>> Warning: entry was unresolved in the replay data
> >>>>>> Warning: entry was unresolved in the replay data
> >>>>>> Warning: entry was unresolved in the replay data
> >>>>>> Warning: entry was unresolved in the replay data
> >>>>>> Warning: entry was unresolved in the replay data
> >>>>>> Error while parsing line 1002: unknown command
> >>>>>>
> >>>>>> Error: java.lang.NullPointerException
> >>>>>> Failed on unknown command
> >>>>>>
> >>>>>> Options: -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -
> >>>>>> XX:NativeMemoryTracking=detail -XX:ReservedCodeCacheSize=256M
> >>>>>> Hosts: Linux-amd64
> >>>>>>
> >>>>>>
> >>>>>> Relates to: JDK-8155219 - [TESTBUG] Rewrite
> >> compiler/ciReplay/TestVM.sh
> >>>> in
> >>>>>> java
> >>>>>>
> >>>>>> Comments:
> >>>>>>
> >>>>>> ILW=LMH=P5. Not a production feature. Intermittent. No known
> >>>> workaround.
> >>>>>> This test is going to be rewritten in java by JDK-8155219, so, problem
> >> might
> >>>> be
> >>>>>> gone after that.
> >>>>>>
> >>>>>> after rewriting to java, test(renamed) still fails:
> >>>>>> compiler/ciReplay/TestSAServer.java" Exception
> java.lang.AssertionError:
> >>>>>> CLHSDB wasn't run successfully: Warning! JS Engine can't start, some
> >>>>>> commands will not be available. hsdb> Opening core file, please wait...
> >>>>>> javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not
> a
> >>>>>> function in sa.js at line number ... javax.script.ScriptException:
> TypeError:
> >>>>>> sapkg.runtime.VM.getVM is not a function in sa.js at line number ...
> >>>> Exception
> >>>>>> in thread "main" java.lang.InternalError: ciMetadata does not appear
> to
> >> be
> >>>>>> polymorphic at
> >>>>>>
> >>>>
> >>
> sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(j
> >>>>>> dk.hotspot.agent...-internal/BasicTypeDataBase.java:...) at
> >>>>>>
> >>>>
> >>
> sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(jdk.ho
> >>>>>> tspot.agent...-internal/VirtualBaseConstructor.java:...) at
> >>>>>> sun.jvm.hotspot.utilities.GrowableArray.at(jdk.hotspot.agent...-
> >>>>>> internal/GrowableArray.java:...) at
> >>>>>> sun.jvm.hotspot.ci.ciEnv.dumpReplayData(jdk.hotspot.agent...-
> >>>>>> internal/ciEnv.java:...) at
> >>>>>> sun.jvm.hotspot.CommandProcessor$5.doit(jdk.hotspot.agent...-
> >>>>>> internal/CommandProcessor.java:...) at
> >>>>>>
> >>>>
> >>
> sun.jvm.hotspot.CommandProcessor.executeCommand(jdk.hotspot.agent...-
> >>>>>> internal/CommandProcessor.java:...) at
> >>>>>>
> >>>>
> >>
> sun.jvm.hotspot.CommandProcessor.executeCommand(jdk.hotspot.agent...-
> >>>>>> internal/CommandProcessor.java:...) at
> >>>>>> sun.jvm.hotspot.CommandProcessor.run(jdk.hotspot.agent...-
> >>>>>> internal/CommandProcessor.java:...) at
> >>>>>> sun.jvm.hotspot.CLHSDB.run(jdk.hotspot.agent...-
> >> internal/CLHSDB.java:...)
> >>>> at
> >>>>>> sun.jvm.hotspot.CLHSDB.main(jdk.hotspot.agent...-
> >> internal/CLHSDB.java:...)
> >>>>>>
> >>>>>> Here's the failures of this test that we're seeing in the 2017-08-04
> JDK10-
> >> hs
> >>>>>> nightly:
> >>>>>> MacOS X failure:
> >>>>>> compiler/ciReplay/TestSAServer.java: Exception java.lang.InternalError:
> >>>>>> ciMetadata does not appear to be polymorphic
> >>>>>> Win-64 and Win32 failures:
> >>>>>> compiler/ciReplay/TestSAServer.java: Timeout
> >>>>>>
> >>>>>> /Jesper
> >


From Alan.Bateman at oracle.com  Fri Dec  6 11:44:42 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 6 Dec 2019 11:44:42 +0000
Subject: JDK-8029528
In-Reply-To: <AM6PR02MB534762BB3E2CDAC92EFF2BA3EC5F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
References: <b2a87064afb8501cfec45d0541879bc811dc1180.camel@redhat.com>
 <5DECDC70-8409-415D-A2DB-B3BD4DDE9FBA@oracle.com>
 <AM6PR02MB534724AD915BD5387B8B7DF3EC630@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <A01E0316-0AB4-4E06-8AD6-5197BAF40BD2@oracle.com>
 <AM6PR02MB53470F3B3803D81786F015C8EC630@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <9ddd5fac-42bb-c910-4498-07f173402c26@oracle.com>
 <AM6PR02MB5347B8573CF5282E72686C9EEC7F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <7EC26C87-AB75-4267-B437-E32379E87F35@oracle.com>
 <AM6PR02MB534762BB3E2CDAC92EFF2BA3EC5F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
Message-ID: <e835f8da-b2d3-cb0c-9150-eafd8a910b75@oracle.com>

On 06/12/2019 11:34, Lindenmaier, Goetz wrote:
> Hi,
>
> I just saw that "8234267: DelegationPermission implementation doesn't completely follow the updated specification"
> https://hg.openjdk.java.net/jdk/jdk/rev/18420160287b
> was pushed with a closed bug.
>
> Is it possible to open this one up?
>
It was created as a confidential issue in error, it has been fixed now. 
The archives for security-dev have the discussion on this issue.

-Alan.

From goetz.lindenmaier at sap.com  Fri Dec  6 11:50:20 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 6 Dec 2019 11:50:20 +0000
Subject: JDK-8029528
In-Reply-To: <e835f8da-b2d3-cb0c-9150-eafd8a910b75@oracle.com>
References: <b2a87064afb8501cfec45d0541879bc811dc1180.camel@redhat.com>
 <5DECDC70-8409-415D-A2DB-B3BD4DDE9FBA@oracle.com>
 <AM6PR02MB534724AD915BD5387B8B7DF3EC630@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <A01E0316-0AB4-4E06-8AD6-5197BAF40BD2@oracle.com>
 <AM6PR02MB53470F3B3803D81786F015C8EC630@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <9ddd5fac-42bb-c910-4498-07f173402c26@oracle.com>
 <AM6PR02MB5347B8573CF5282E72686C9EEC7F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <7EC26C87-AB75-4267-B437-E32379E87F35@oracle.com>
 <AM6PR02MB534762BB3E2CDAC92EFF2BA3EC5F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <e835f8da-b2d3-cb0c-9150-eafd8a910b75@oracle.com>
Message-ID: <AM6PR02MB5347055A4D8441F5CA5F61ABEC5F0@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi Alan, 

I'm not interested in the discussion, I would like to see the bug.
In case we downport it to 11u, I would like that everybody can 
see in JBS that this happened.

Best regards,
  Goetz.

> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Freitag, 6. Dezember 2019 12:45
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> jesper.wilhelmsson at oracle.com
> Cc: jdk-dev at openjdk.java.net
> Subject: Re: JDK-8029528
> 
> On 06/12/2019 11:34, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > I just saw that "8234267: DelegationPermission implementation doesn't
> completely follow the updated specification"
> > https://hg.openjdk.java.net/jdk/jdk/rev/18420160287b
> > was pushed with a closed bug.
> >
> > Is it possible to open this one up?
> >
> It was created as a confidential issue in error, it has been fixed now.
> The archives for security-dev have the discussion on this issue.
> 
> -Alan.

From Alan.Bateman at oracle.com  Fri Dec  6 12:02:54 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 6 Dec 2019 12:02:54 +0000
Subject: JDK-8029528
In-Reply-To: <AM6PR02MB5347055A4D8441F5CA5F61ABEC5F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
References: <b2a87064afb8501cfec45d0541879bc811dc1180.camel@redhat.com>
 <5DECDC70-8409-415D-A2DB-B3BD4DDE9FBA@oracle.com>
 <AM6PR02MB534724AD915BD5387B8B7DF3EC630@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <A01E0316-0AB4-4E06-8AD6-5197BAF40BD2@oracle.com>
 <AM6PR02MB53470F3B3803D81786F015C8EC630@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <9ddd5fac-42bb-c910-4498-07f173402c26@oracle.com>
 <AM6PR02MB5347B8573CF5282E72686C9EEC7F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <7EC26C87-AB75-4267-B437-E32379E87F35@oracle.com>
 <AM6PR02MB534762BB3E2CDAC92EFF2BA3EC5F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <e835f8da-b2d3-cb0c-9150-eafd8a910b75@oracle.com>
 <AM6PR02MB5347055A4D8441F5CA5F61ABEC5F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
Message-ID: <ab74c55c-2440-6b5c-d454-6ff5e6049e8d@oracle.com>

On 06/12/2019 11:50, Lindenmaier, Goetz wrote:
> Hi Alan,
>
> I'm not interested in the discussion, I would like to see the bug.
> In case we downport it to 11u, I would like that everybody can
> see in JBS that this happened.
>
I fixed the bug status, are you still have problems? It's relates to a 
spec update in Java SE 14 and security-dev is the right place if there 
is follow-up.

-Alan


From goetz.lindenmaier at sap.com  Fri Dec  6 13:06:50 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 6 Dec 2019 13:06:50 +0000
Subject: JDK-8029528
In-Reply-To: <ab74c55c-2440-6b5c-d454-6ff5e6049e8d@oracle.com>
References: <b2a87064afb8501cfec45d0541879bc811dc1180.camel@redhat.com>
 <5DECDC70-8409-415D-A2DB-B3BD4DDE9FBA@oracle.com>
 <AM6PR02MB534724AD915BD5387B8B7DF3EC630@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <A01E0316-0AB4-4E06-8AD6-5197BAF40BD2@oracle.com>
 <AM6PR02MB53470F3B3803D81786F015C8EC630@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <9ddd5fac-42bb-c910-4498-07f173402c26@oracle.com>
 <AM6PR02MB5347B8573CF5282E72686C9EEC7F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <7EC26C87-AB75-4267-B437-E32379E87F35@oracle.com>
 <AM6PR02MB534762BB3E2CDAC92EFF2BA3EC5F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <e835f8da-b2d3-cb0c-9150-eafd8a910b75@oracle.com>
 <AM6PR02MB5347055A4D8441F5CA5F61ABEC5F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <ab74c55c-2440-6b5c-d454-6ff5e6049e8d@oracle.com>
Message-ID: <AM6PR02MB534756A3863BF1652B5BC93EEC5F0@AM6PR02MB5347.eurprd02.prod.outlook.com>

That's great, thank you very much!

Best regards,
  Goetz. 

> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Freitag, 6. Dezember 2019 13:03
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> jesper.wilhelmsson at oracle.com
> Cc: jdk-dev at openjdk.java.net
> Subject: Re: JDK-8029528
> 
> On 06/12/2019 11:50, Lindenmaier, Goetz wrote:
> > Hi Alan,
> >
> > I'm not interested in the discussion, I would like to see the bug.
> > In case we downport it to 11u, I would like that everybody can
> > see in JBS that this happened.
> >
> I fixed the bug status, are you still have problems? It's relates to a
> spec update in Java SE 14 and security-dev is the right place if there
> is follow-up.
> 
> -Alan


From eric.caspole at oracle.com  Fri Dec  6 14:26:54 2019
From: eric.caspole at oracle.com (eric.caspole at oracle.com)
Date: Fri, 6 Dec 2019 09:26:54 -0500
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <f46ce3f9-4acf-7631-9fac-b49f3dd34b53@oracle.com>

Vote: yes


On 12/5/19 1:59 PM, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
> 
> Sandhya is a long-term member of the Java team at Intel from the time 
> when we start collaboration with Intel.
> 
> She contributed (and participated in) 14 OpenJDK changesets from which 8 
> are significant [3]. And she contributed when Intel was not part of 
> OpenJDK - it is not listed here. Her work concentrated on x86 code 
> generation, vectorization and intrinsics for modern Intel CPUs.
> 
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
> 
> Only current JDK 9 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].
> 
> Regards,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> [3] Changesets list:
> 
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
> 
> 8215888: Register to register spill may use AVX 512 move instruction on 
> unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
> 
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
> 
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
> 
> 8020860: cluster Hashtable/Vector field updates for better transactional 
> memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
> 
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage 
> Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
> 
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
> 
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1

From Roger.Riggs at oracle.com  Fri Dec  6 15:00:29 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 6 Dec 2019 10:00:29 -0500
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <21b56ac4-9f68-bc15-9f8f-347f489a7aea@oracle.com>

Vote: Yes

On 12/5/19 1:59 PM, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer. 


From sangheon.kim at oracle.com  Fri Dec  6 18:16:05 2019
From: sangheon.kim at oracle.com (sangheon.kim at oracle.com)
Date: Fri, 6 Dec 2019 10:16:05 -0800
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <8da7c594-5fb0-d7ff-eaf3-6348222c3baa@oracle.com>

Vote: yes

Thanks,
Sangheon


On 12/5/19 10:59 AM, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
>
> Sandhya is a long-term member of the Java team at Intel from the time 
> when we start collaboration with Intel.
>
> She contributed (and participated in) 14 OpenJDK changesets from which 
> 8 are significant [3]. And she contributed when Intel was not part of 
> OpenJDK - it is not listed here. Her work concentrated on x86 code 
> generation, vectorization and intrinsics for modern Intel CPUs.
>
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
>
> Only current JDK 9 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].
>
> Regards,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
> [3] Changesets list:
>
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
>
> 8215888: Register to register spill may use AVX 512 move instruction 
> on unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
>
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
>
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
>
> 8020860: cluster Hashtable/Vector field updates for better 
> transactional memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
>
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage 
> Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
>
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
>
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1


From john.r.rose at oracle.com  Sat Dec  7 01:32:55 2019
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 6 Dec 2019 17:32:55 -0800
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <D39A413E-9A67-4B54-BEF5-8C431D08CC26@oracle.com>

Vote: yes!!

From erik.osterlund at oracle.com  Sat Dec  7 08:07:46 2019
From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=)
Date: Sat, 7 Dec 2019 09:07:46 +0100
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <89CE174A-9431-49A6-81FF-AA6E3342EAAF@oracle.com>

Vote: yes

/Erik

> On 5 Dec 2019, at 19:59, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> ?I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
> 
> Sandhya is a long-term member of the Java team at Intel from the time when we start collaboration with Intel.
> 
> She contributed (and participated in) 14 OpenJDK changesets from which 8 are significant [3]. And she contributed when Intel was not part of OpenJDK - it is not listed here. Her work concentrated on x86 code generation, vectorization and intrinsics for modern Intel CPUs.
> 
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
> 
> Only current JDK 9 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].
> 
> Regards,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> [3] Changesets list:
> 
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
> 
> 8215888: Register to register spill may use AVX 512 move instruction on unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
> 
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
> 
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
> 
> 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
> 
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
> 
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
> 
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1


From maurizio.cimadamore at oracle.com  Sun Dec  8 21:11:05 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sun, 8 Dec 2019 21:11:05 +0000
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <8868fc3f-1a7a-6372-e8ff-363b02d9723b@oracle.com>

Vote: yes!

Maurizio

On 05/12/2019 18:59, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
>
> Sandhya is a long-term member of the Java team at Intel from the time 
> when we start collaboration with Intel.
>
> She contributed (and participated in) 14 OpenJDK changesets from which 
> 8 are significant [3]. And she contributed when Intel was not part of 
> OpenJDK - it is not listed here. Her work concentrated on x86 code 
> generation, vectorization and intrinsics for modern Intel CPUs.
>
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
>
> Only current JDK 9 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].
>
> Regards,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
> [3] Changesets list:
>
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
>
> 8215888: Register to register spill may use AVX 512 move instruction 
> on unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
>
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
>
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
>
> 8020860: cluster Hashtable/Vector field updates for better 
> transactional memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
>
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage 
> Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
>
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
>
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1

From per.liden at oracle.com  Sun Dec  8 22:35:01 2019
From: per.liden at oracle.com (Per Liden)
Date: Sun, 8 Dec 2019 23:35:01 +0100
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <4706ed19-e97a-89c4-a2e5-8ffd94b65c9e@oracle.com>

Vote: yes

/Per

On 2019-12-05 19:59, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
> 
> Sandhya is a long-term member of the Java team at Intel from the time 
> when we start collaboration with Intel.
> 
> She contributed (and participated in) 14 OpenJDK changesets from which 8 
> are significant [3]. And she contributed when Intel was not part of 
> OpenJDK - it is not listed here. Her work concentrated on x86 code 
> generation, vectorization and intrinsics for modern Intel CPUs.
> 
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
> 
> Only current JDK 9 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].
> 
> Regards,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> [3] Changesets list:
> 
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
> 
> 8215888: Register to register spill may use AVX 512 move instruction on 
> unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
> 
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
> 
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
> 
> 8020860: cluster Hashtable/Vector field updates for better transactional 
> memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
> 
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage 
> Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
> 
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
> 
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1

From jesper.wilhelmsson at oracle.com  Mon Dec  9 12:39:11 2019
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 9 Dec 2019 13:39:11 +0100
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <B15852BB-53D8-4C4F-89DF-F3BDF37EB1E5@oracle.com>

Vote: Yes
/Jesper

> On 5 Dec 2019, at 19:59, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
> 
> Sandhya is a long-term member of the Java team at Intel from the time when we start collaboration with Intel.
> 
> She contributed (and participated in) 14 OpenJDK changesets from which 8 are significant [3]. And she contributed when Intel was not part of OpenJDK - it is not listed here. Her work concentrated on x86 code generation, vectorization and intrinsics for modern Intel CPUs.
> 
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
> 
> Only current JDK 9 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].
> 
> Regards,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> [3] Changesets list:
> 
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
> 
> 8215888: Register to register spill may use AVX 512 move instruction on unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
> 
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
> 
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
> 
> 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
> 
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
> 
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
> 
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1


From neugens.limasoftware at gmail.com  Mon Dec  9 13:49:26 2019
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Mon, 9 Dec 2019 14:49:26 +0100
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <CAGUMyaQm=iAPgKCJx_+aRVnFh6j_FJTAzNs2UvjmV=+3pc_ygA@mail.gmail.com>

Vote: Yes

Cheers,
Mario

On Thu 5. Dec 2019 at 20:00, Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
>
> Sandhya is a long-term member of the Java team at Intel from the time when
> we start collaboration with Intel.
>
> She contributed (and participated in) 14 OpenJDK changesets from which 8
> are significant [3]. And she contributed when
> Intel was not part of OpenJDK - it is not listed here. Her work
> concentrated on x86 code generation, vectorization and
> intrinsics for modern Intel CPUs.
>
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
>
> Only current JDK 9 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].
>
> Regards,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
> [3] Changesets list:
>
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
>
> 8215888: Register to register spill may use AVX 512 move instruction on
> unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
>
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
>
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
>
> 8020860: cluster Hashtable/Vector field updates for better transactional
> memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
>
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage
> Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
>
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
>
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1
>
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From goetz.lindenmaier at sap.com  Mon Dec  9 14:52:15 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 9 Dec 2019 14:52:15 +0000
Subject: Please open 8152988: [AOT] Update test batch definitions to include
 aot-ed java.base module mode into hs-comp testing
Message-ID: <AM6PR02MB53479EB3A6378F4C1EFC9FADEC580@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi,

I would like to downport this change.
It would be great if the bug could be opened up.

http://hg.openjdk.java.net/jdk/jdk/rev/ff10f8f3a583
https://bugs.openjdk.java.net/browse/JDK-8152988

Best regards,
  Goetz.

From fenix_young at hotmail.com  Tue Dec 10 02:13:55 2019
From: fenix_young at hotmail.com (Felix Yang)
Date: Tue, 10 Dec 2019 02:13:55 +0000
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <3b620564-24c9-b87c-ee54-4e0a3a8aa4bc@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>,
 <3b620564-24c9-b87c-ee54-4e0a3a8aa4bc@oracle.com>
Message-ID: <MN2PR13MB3264ED074C0CD15D9B299848865B0@MN2PR13MB3264.namprd13.prod.outlook.com>

Vote: Yes

-Felix Yang
________________________________
From: jdk-dev <jdk-dev-bounces at openjdk.java.net> on behalf of Michael McMahon <michael.x.mcmahon at oracle.com>
Sent: Thursday, December 5, 2019 22:17
To: jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>
Subject: Re: CFV: New JDK Committer: Julia Boes

Vote: Yes

On 29/11/2019 19:12, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Julia Boes (jboes) to JDK Committer.
>
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
>
> Votes are due by 12:00 UTC December 14th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
>
> -- daniel
>
> [1]
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
>
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus

From tobias.hartmann at oracle.com  Tue Dec 10 08:40:56 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 10 Dec 2019 09:40:56 +0100
Subject: CFV: New JDK Committer: Christian Hagedorn
Message-ID: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>

Hi,

I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.

Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
significant and affect complex code in the JIT compilers.

Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
implementing C1 JIT compiler support for Inline Types. He made excellent progress including
developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
today's C1 implementation in project Valhalla.

Votes are due by 08:30 UTC, December 24th, 2019.

Only current JDK Committers [2] 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 [3].

Best regards,
Tobias

[1]
http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
[2] http://openjdk.java.net/census
[3] http://openjdk.java.net/bylaws#lazy-consensus

From tobias.hartmann at oracle.com  Tue Dec 10 08:42:51 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 10 Dec 2019 09:42:51 +0100
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <1ac7c8b3-8781-ec13-1892-ad47134c1ecc@oracle.com>

Vote: yes

Best regards,
Tobias

On 10.12.19 09:40, Tobias Hartmann wrote:
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 

From fujie at loongson.cn  Tue Dec 10 08:57:19 2019
From: fujie at loongson.cn (Jie Fu)
Date: Tue, 10 Dec 2019 16:57:19 +0800
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <02e50108-c599-374e-4281-81dfab115a19@loongson.cn>

Vote: yes

Best regards,
Jie

On 2019/12/10 ??4:40, Tobias Hartmann wrote:
> Hi,
>
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
>
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
>
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
>
> Votes are due by 08:30 UTC, December 24th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
> Tobias
>
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From jamsheed.c.m at oracle.com  Tue Dec 10 09:19:53 2019
From: jamsheed.c.m at oracle.com (Jamsheed C M)
Date: Tue, 10 Dec 2019 14:49:53 +0530
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <38881c7f-2357-0cc0-e483-423b838abf56@oracle.com>

Vote: Yes

Best regards,

Jamsheed

On 10/12/19 2:10 pm, Tobias Hartmann wrote:
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.

From david.holmes at oracle.com  Tue Dec 10 09:31:21 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Dec 2019 19:31:21 +1000
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <1a12c6d2-8ba4-e1ff-718f-d6516266b68e@oracle.com>

Vote: yes

David

On 10/12/2019 6:40 pm, Tobias Hartmann wrote:
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 

From adinn at redhat.com  Tue Dec 10 09:35:40 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 10 Dec 2019 09:35:40 +0000
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <1fdeb07c-c971-2bfc-30ce-9078e27cf572@redhat.com>

Vote: yes

On 10/12/2019 08:40, Tobias Hartmann wrote:
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 

-- 
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


From christoph.langer at sap.com  Tue Dec 10 10:08:12 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 10 Dec 2019 10:08:12 +0000
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <DB8PR02MB55474ED300C3730DD92E1C6D8A5B0@DB8PR02MB5547.eurprd02.prod.outlook.com>

Vote: yes

/Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Tobias
> Hartmann
> Sent: Dienstag, 10. Dezember 2019 09:41
> To: jdk-dev at openjdk.java.net
> Subject: CFV: New JDK Committer: Christian Hagedorn
> 
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he
> only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1],
> from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis
> project on
> implementing C1 JIT compiler support for Inline Types. He made excellent
> progress including
> developing aggressive optimizations to avoid heap buffering. His work served
> as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hage
> dorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=1
> 00
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus

From felix.yang at huawei.com  Tue Dec 10 10:32:56 2019
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Tue, 10 Dec 2019 10:32:56 +0000
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <1ac7c8b3-8781-ec13-1892-ad47134c1ecc@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
 <1ac7c8b3-8781-ec13-1892-ad47134c1ecc@oracle.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE3DD7C1D@dggeml527-mbx.china.huawei.com>

Vote: yes

> -----Original Message-----
> From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Tobias
> Hartmann
> Sent: Tuesday, December 10, 2019 4:43 PM
> To: jdk-dev at openjdk.java.net
> Subject: Re: CFV: New JDK Committer: Christian Hagedorn
> 
> Vote: yes
> 
> Best regards,
> Tobias
> 
> On 10.12.19 09:40, Tobias Hartmann wrote:
> > Hi,
> >
> > I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> >
> > Christian is a member of the HotSpot Compiler Team at Oracle. Although
> > he only joined in mid July this year, Christian already contributed 19
> > changes to the JDK project [1], from which 11 are significant and affect
> complex code in the JIT compilers.
> >
> > Back in 2017, Christian already worked on the JDK as part of his
> > masters thesis project on implementing C1 JIT compiler support for
> > Inline Types. He made excellent progress including developing
> > aggressive optimizations to avoid heap buffering. His work served as a
> guidance for today's C1 implementation in project Valhalla.
> >
> > Votes are due by 08:30 UTC, December 24th, 2019.
> >
> > Only current JDK Committers [2] 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 [3].
> >
> > Best regards,
> > Tobias
> >
> > [1]
> > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hag
> >
> edorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=1
> 00
> > [2] http://openjdk.java.net/census
> > [3] http://openjdk.java.net/bylaws#lazy-consensus
> >

From daniel.fuchs at oracle.com  Tue Dec 10 11:49:05 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 10 Dec 2019 11:49:05 +0000
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <8a95deca-6293-1906-aa4a-60ca44f2fa8d@oracle.com>

Vote: yes

best regards,

-- daniel

On 05/12/2019 18:59, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.


From daniel.fuchs at oracle.com  Tue Dec 10 11:48:06 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 10 Dec 2019 11:48:06 +0000
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <95786089-21cc-623f-2bd2-65f2cfc23eea@oracle.com>

Vote: yes

best regards,

-- daniel

On 10/12/2019 08:40, Tobias Hartmann wrote:
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.



From naoto.sato at oracle.com  Tue Dec 10 12:45:44 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 10 Dec 2019 04:45:44 -0800
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <f95cec94-f829-0b23-497d-1a1959369ad4@oracle.com>

Vote: yes

Naoto

On 11/29/19 11:12 AM, Daniel Fuchs wrote:
> Hi,
> 
> I hereby nominate Julia Boes (jboes) to JDK Committer.
> 
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
> 
> Votes are due by 12:00 UTC December 14th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> 
> -- daniel
> 
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20 
> 
> 
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus

From dalibor.topic at oracle.com  Tue Dec 10 12:57:36 2019
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Tue, 10 Dec 2019 13:57:36 +0100
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <37db958a-f4f3-86b0-92db-43669588dd7e@oracle.com>

Vote: Yes.


-- 
<http://www.oracle.com>
Dalibor Topic | Consulting Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961> | Video: dalibor.topic at oracle.com
<sip:dalibor.topic at oracle.com>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From claes.redestad at oracle.com  Tue Dec 10 13:02:02 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 10 Dec 2019 14:02:02 +0100
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <68321e11-bb73-fdb4-8346-01f7c40d6d3d@oracle.com>

Vote: yes

On 2019-12-10 09:40, Tobias Hartmann wrote:
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 

From claes.redestad at oracle.com  Tue Dec 10 13:02:17 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 10 Dec 2019 14:02:17 +0100
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <60275d06-d63f-28b7-ad9c-a393536e592d@oracle.com>

Vote: yes

On 2019-11-29 20:12, Daniel Fuchs wrote:
> Hi,
> 
> I hereby nominate Julia Boes (jboes) to JDK Committer.
> 
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
> 
> Votes are due by 12:00 UTC December 14th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> 
> -- daniel
> 
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20 
> 
> 
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus

From claes.redestad at oracle.com  Tue Dec 10 13:02:34 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 10 Dec 2019 14:02:34 +0100
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <45fd94d4-5d0e-18b7-1df3-e29cd2e76513@oracle.com>

Vote: yes

On 2019-12-05 19:59, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
> 
> Sandhya is a long-term member of the Java team at Intel from the time 
> when we start collaboration with Intel.
> 
> She contributed (and participated in) 14 OpenJDK changesets from which 8 
> are significant [3]. And she contributed when Intel was not part of 
> OpenJDK - it is not listed here. Her work concentrated on x86 code 
> generation, vectorization and intrinsics for modern Intel CPUs.
> 
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
> 
> Only current JDK 9 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].
> 
> Regards,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> [3] Changesets list:
> 
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
> 
> 8215888: Register to register spill may use AVX 512 move instruction on 
> unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
> 
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
> 
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
> 
> 8020860: cluster Hashtable/Vector field updates for better transactional 
> memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
> 
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage 
> Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
> 
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
> 
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1

From sgehwolf at redhat.com  Tue Dec 10 13:02:51 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 10 Dec 2019 14:02:51 +0100
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <fffe2a000e43326a43d5dd16b1a3cf4a2f5a4745.camel@redhat.com>

Vote: yes.

On Tue, 2019-12-10 at 09:40 +0100, Tobias Hartmann wrote:
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 


From coleen.phillimore at oracle.com  Tue Dec 10 13:02:58 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 10 Dec 2019 08:02:58 -0500
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <8da6a1c7-3afa-5b86-3100-f98e4a5e6e2d@oracle.com>

Vote: yes

On 12/10/19 3:40 AM, Tobias Hartmann wrote:
> Hi,
>
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
>
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
>
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
>
> Votes are due by 08:30 UTC, December 24th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
> Tobias
>
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From rahul.v.raghavan at oracle.com  Tue Dec 10 14:55:24 2019
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Tue, 10 Dec 2019 20:25:24 +0530
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <e9f33302-2187-e7ff-79b4-5ddccf81b238@oracle.com>

Vote: yes

Rahul

On 10/12/19 2:10 pm, Tobias Hartmann wrote:
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 

From rahul.v.raghavan at oracle.com  Tue Dec 10 14:56:41 2019
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Tue, 10 Dec 2019 20:26:41 +0530
Subject: CFV: New JDK Committer: Jie Fu
In-Reply-To: <d4d7e27c-16b2-e495-abea-b75529164fbd@oracle.com>
References: <d4d7e27c-16b2-e495-abea-b75529164fbd@oracle.com>
Message-ID: <a6ba6c33-448f-9105-ebd4-a4b4a544cea4@oracle.com>

Vote: yes

-Rahul

On 07/11/19 11:35 am, Ioi Lam wrote:
> I hereby nominate Jie Fu (jiefu) to JDK Committer.
> 
> Jie has been with Loongson's JVM team for more than 7 years.
> He is working on the mips-port of OpenJDK, mainly on the JIT compiler.
> One of his notable contribution is the backend of C2 for mips.
> Now his interests also include GC and runtime.
> He already has the Author status in JDK Project,
> 
> Jie has contributed 37 fixes to the JDK Project.
> A list of his contributions can be found at [3].
> 
> Jie has also contributed 9 fixes to the jdk11u-dev Project.
> A list of his contributions can be found at [4].
> 
> Votes are due by 12:00 UTC November 21th, 2019.
> 
> Only current JDK 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].
> 
> Thanks,
> Ioi
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] List of changes in jdk/jdk:
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(jiefu)+or+desc(%22fujie at loongson.cn%22))+and+not+merge() 
> 
> [4] List of changes in jdk11u-dev:
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(jiefu)+or+desc(%22fujie at loongson.cn%22))+and+not+merge() 
> 

From rahul.v.raghavan at oracle.com  Tue Dec 10 14:57:40 2019
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Tue, 10 Dec 2019 20:27:40 +0530
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <957fd6ba-a13f-afd5-e5f8-8c17bf96be0d@oracle.com>

Vote: yes

-Rahul

On 06/12/19 12:29 am, Vladimir Kozlov wrote:
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
> 
> Sandhya is a long-term member of the Java team at Intel from the time 
> when we start collaboration with Intel.
> 
> She contributed (and participated in) 14 OpenJDK changesets from which 8 
> are significant [3]. And she contributed when Intel was not part of 
> OpenJDK - it is not listed here. Her work concentrated on x86 code 
> generation, vectorization and intrinsics for modern Intel CPUs.
> 
> Votes are due by 11:00 AM PDT, Wednesday December 19, 2019.
> 
> Only current JDK 9 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].
> 
> Regards,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> [3] Changesets list:
> 
> 8222074: Enhance auto vectorization for x86
> http://hg.openjdk.java.net/jdk/jdk/rev/1851a532ddfe
> 
> 8215888: Register to register spill may use AVX 512 move instruction on 
> unsupported platform.
> http://hg.openjdk.java.net/jdk/jdk/rev/3ab3cb8a8d41
> 
> 8211251: Default mask register for avx512 instructions
> http://hg.openjdk.java.net/jdk/jdk/rev/390f529f4f22
> 
> 8210764: Update avx512 implementation
> http://hg.openjdk.java.net/jdk/jdk/rev/9978fea8a371
> 
> 8020860: cluster Hashtable/Vector field updates for better transactional 
> memory behaviour
> http://hg.openjdk.java.net/jdk/jdk/rev/91f5e4399160
> 
> 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage 
> Collector (Experimental)
> http://hg.openjdk.java.net/jdk/jdk/rev/767cdb97f103
> 
> 8141132: JEP 254: Compact Strings
> http://hg.openjdk.java.net/jdk/jdk/rev/09241459a8b8
> 
> 8081778: Use Intel x64 CPU instructions for RSA acceleration
> http://hg.openjdk.java.net/jdk/jdk/rev/02ee7609f0e1

From martin.doerr at sap.com  Tue Dec 10 15:13:49 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 10 Dec 2019 15:13:49 +0000
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <DB8PR02MB55474ED300C3730DD92E1C6D8A5B0@DB8PR02MB5547.eurprd02.prod.outlook.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
 <DB8PR02MB55474ED300C3730DD92E1C6D8A5B0@DB8PR02MB5547.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB329717C09856571259D603DB9A5B0@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Vote: yes

Best regards,
Martin


From rwestrel at redhat.com  Tue Dec 10 15:27:25 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 10 Dec 2019 16:27:25 +0100
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <875zio9p5u.fsf@redhat.com>


Vote: yes

Roland.


From eric.caspole at oracle.com  Tue Dec 10 15:40:06 2019
From: eric.caspole at oracle.com (Eric Caspole)
Date: Tue, 10 Dec 2019 10:40:06 -0500
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <fca88cd1-b178-d3c8-e4d8-a78394c888ec@oracle.com>

Vote: yes

On 12/10/19 03:40, Tobias Hartmann wrote:
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 

From Roger.Riggs at oracle.com  Tue Dec 10 15:38:28 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 10 Dec 2019 10:38:28 -0500
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <c262152f-3a6b-bd89-232a-9d61c01adb3f@oracle.com>

Vote: Yes

On 12/10/19 3:40 AM, Tobias Hartmann wrote:
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.


From jesper.wilhelmsson at oracle.com  Tue Dec 10 16:39:28 2019
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 10 Dec 2019 17:39:28 +0100
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <DD908365-DFD4-4902-9C5C-E785FD3D0D43@oracle.com>

Vote: Yes
/Jesper

> On 10 Dec 2019, at 09:40, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From vladimir.x.ivanov at oracle.com  Tue Dec 10 16:40:40 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 10 Dec 2019 19:40:40 +0300
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <fa10e97b-4840-19e3-c708-9e44fa655941@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

On 10.12.2019 11:40, Tobias Hartmann wrote:
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.

From calvin.cheung at oracle.com  Tue Dec 10 17:06:51 2019
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Tue, 10 Dec 2019 09:06:51 -0800
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <c4d05b2f-c510-e3b6-440d-ae873404fa8c@oracle.com>

Vote: yes

On 12/10/19 12:40 AM, Tobias Hartmann wrote:
> Hi,
>
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
>
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
>
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
>
> Votes are due by 08:30 UTC, December 24th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
> Tobias
>
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus

From vladimir.kozlov at oracle.com  Tue Dec 10 17:09:40 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 10 Dec 2019 09:09:40 -0800
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <2b122cba-e932-9994-f481-872ed765ef21@oracle.com>

Vote: yes

On 12/10/19 12:40 AM, Tobias Hartmann wrote:
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 

From jonathan.gibbons at oracle.com  Tue Dec 10 18:42:26 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 10 Dec 2019 10:42:26 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
Message-ID: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>

|I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant 
contributor to OpenJDK, and has made over 90 commits so far, in both JDK 
and the sandbox. He has worked on both core-libs and, more recently, on 
javadoc. Votes are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1] 
http://openjdk.java.net/census [2] 
http://openjdk.java.net/projects/#reviewer-vote|

-------------- next part --------------
user = prappo
email = pavel.rappo

All my commits:
8227461: Update dejavu-fonts to the latest release v2.37
8234348: Review the DejaVu font files used for the JDK javadocs
8213431: Improve file protocol handling
8181612: More stable connection processing
8181646: Add SQE WebSocket tests
8170116: Remove qualified exports from java.base to java.corba
8042888: Remove extcheck tool
8042888: Remove extcheck tool
8042888: Remove extcheck tool
8044627: Update JNDI to work with modules
8043839: TEST closed/com/sun/jndi/dns/RandomXID.java failed intermittently in nightly
8048175: Remove redundant use of reflection on core classes from JNDI
 = 12

But these were someone else's change that I committed:
8181646: Add SQE WebSocket tests
8170116: Remove qualified exports from java.base to java.corba
 = 2

These were Contributed-by me:
8204679: HTTP Client refresh
8197564: HTTP Client implementation
8191494: Refresh incubating HTTP Client
8170648: Move java.net.http package out of Java SE to incubator namespace
 = 4

Total commits: 14

user = prappo
email = pavel.rappo

All my commits:
8235435: Remove (obsolete) @author info from javadoc source and tests
8228580: DnsClient TCP socket timeout
8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect
8217606: LdapContext
8213431: Improve file protocol handling
8226602: Test convenience reactive primitives from java.net.http with RS TCK
8226303: Examine the HttpRequest.BodyPublishers for exception handling
8218022: Repeated words typos in java.base
8215292: Back out changes for node- and link- local ipv6 multicast address
8213490: Networking area typos and inconsistencies cleanup
8210493: Bind to node- or linklocal ipv6 multicast address fails
8212001: Verify exported symbols in java.base (libjava)
8212000: Verify exported symbols in java.base (libnet, libnio/ch)
8181612: More stable connection processing
8180155: WebSocket secure connection get stuck after onOpen
8179021: Latest bugfixes to WebSocket/HPACK from the sandbox repo
8177738: Runtime.Version must be a value-based class
8176882: Incorrect integer comparison in version numbers
8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem
8164625: Pooled HttpConnection should be removed during close
8175305: Typos in net.properties
8170116: Remove qualified exports from java.base to java.corba
8170116: Remove qualified exports from java.base to java.corba
8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url
8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url
8038079: Re-examine integration of SPNEGO authentication
8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url
8168417: Pending exceptions in java.base/windows/native/libnio
8168405: Pending exceptions in java.base/windows/native
8163586: java.net.http.RawChannel has been made public by mistake
8161474: Extract interface from java.net.http.RawChannel
8160218: HPack decoder fails when processing header in multiple ByteBuffers
8156742: Miscellaneous WebSocket API improvements
8159039: sun/net/httpclient/hpack/HeaderTableTest.java fails on some locales
8156693: Improve usability of CompletableFuture use in WebSocket API
8156650: Simplify Text message support in WebSocket API
8150785: (bf) Hoist slice and duplicate methods up to java.nio.Buffer
8156931: java.nio.Buffer tests cleanup
8087113: Websocket API and implementation
8154487: java.httpclient/sun.net.httpclient.hpack.DecoderTest failing on Windows
8153353: HPACK implementation
8151065: Typo in javax.naming.CompoundName
8064925: URLConnection::getContent needs to be updated to work with modules
8029689: (spec) Reader.read(char[], int, int) throws unspecified IndexOutOfBoundsException
8075959: Change parameter names in some IOException subclasses
8067870: Fix java.io.ObjectInputStream.PeekInputStream
8066642: Fix deprecation warnings in jdk.naming module
8066867: Add InputStream transferTo to transfer content to an OutputStream
8066678: java.nio.channels.Channels cleanup
8059311: com/sun/jndi/ldap/LdapTimeoutTest.java fails with exit_code == 0
8062759: Update test/javax/naming/spi/providers/InitialContextTest.java to use classpath
8042888: Remove extcheck tool
8042888: Remove extcheck tool
8044627: Update JNDI to work with modules
8054857: Fix typos in java.lang.** packages
8054158: Fix typos in JNDI-related packages
8051991: Flatten VersionHelper hierarchies
8051422: Remove JNDI dependency on java.applet.Applet
8051350: Update javadoc for com.sun.jndi.toolkit.corba.CorbaUtils
8050869: Convert runtime dependency to Applet to a static dependency in cosnaming
8048175: Remove redundant use of reflection on core classes from JNDI
8049884: Reduce possible timing noise in com/sun/jndi/ldap/LdapTimeoutTest.java
8047062: Improve diagnostic output in com/sun/jndi/ldap/LdapTimeoutTest.java
8048874: Replace uses of 'new Byte', 'new Short' and 'new Character' with appropriate alternative across core classes
8048267: Replace uses of 'new Long()' with appropriate alternative across core classes
8027308: HttpURLConnection should better handle URLs with literal IPv6 addresses
8024832: ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound
 = 67

But these were someone else's change that I committed:
8228580: DnsClient TCP socket timeout
8217606: LdapContext#reconnect always opens a new connection
8218022: Repeated words typos in java.base
8170116: Remove qualified exports from java.base to java.corba
8170116: Remove qualified exports from java.base to java.corba
8151065: Typo in javax.naming.CompoundName
8048874: Replace uses of 'new Byte', 'new Short' and 'new Character' with appropriate alternative across core classes
8048267: Replace uses of 'new Long()' with appropriate alternative across core classes
 = 8

These were Contributed-by me:
8204679: HTTP Client refresh
8202423: Small HTTP Client refresh
8197564: HTTP Client implementation
8191494: Refresh incubating HTTP Client
8177738: Runtime.Version must be a value-based class
8170648: Move java.net.http package out of Java SE to incubator namespace
8170648: Move java.net.http package out of Java SE to incubator namespace
8066867: Add InputStream transferTo to transfer content to an OutputStream
8055326: Fix typos in client-related packages
8042887: Remove serialver -show, this tool does not need a GUI
7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize 
8034057: Files.getFileStore and Files.isWritable do not work with SUBST'ed drives (win)
8038178: Fix corrupt license header
8040262: (fs) Misc. typos in comments and implementation
8037781: Remove sun.misc.Regexp* classes
8035158: Remove dependency on sun.misc.RegexpPool and friends
8038163: Build failure on Mac OS 10.9.2 (Mavericks) due to warning treated as error
 = 17

Total commits: 76


From daniel.fuchs at oracle.com  Tue Dec 10 18:49:37 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 10 Dec 2019 18:49:37 +0000
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <de03ac51-5b7b-e13a-1939-034806ed1d3f@oracle.com>

Vote: Yes!

best regards,

-- daniel

On 10/12/2019 18:42, Jonathan Gibbons wrote:
> I hereby nominate Pavel Rappo to jdk Reviewer.


From jonathan.gibbons at oracle.com  Tue Dec 10 18:49:36 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 10 Dec 2019 10:49:36 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <23c2dd9c-c6e3-c0ed-06df-cc1432013b84@oracle.com>


Well, I don't know what happened to the formatting in my previous email. 
Let's try again ...
-------------------


I hereby nominate Pavel Rappo to jdk Reviewer.

Pavel is a significant contributor to OpenJDK, and has made over 90 
commits so far, in both JDK and the sandbox. He has worked on both 
core-libs and, more recently, on javadoc.

Votes are due by Dec 24.

Only current jdk Reviewers [1] 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 [2].

Jonathan Gibbons

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#reviewer-vote|

-------------- next part --------------
user = prappo
email = pavel.rappo

All my commits:
8227461: Update dejavu-fonts to the latest release v2.37
8234348: Review the DejaVu font files used for the JDK javadocs
8213431: Improve file protocol handling
8181612: More stable connection processing
8181646: Add SQE WebSocket tests
8170116: Remove qualified exports from java.base to java.corba
8042888: Remove extcheck tool
8042888: Remove extcheck tool
8042888: Remove extcheck tool
8044627: Update JNDI to work with modules
8043839: TEST closed/com/sun/jndi/dns/RandomXID.java failed intermittently in nightly
8048175: Remove redundant use of reflection on core classes from JNDI
 = 12

But these were someone else's change that I committed:
8181646: Add SQE WebSocket tests
8170116: Remove qualified exports from java.base to java.corba
 = 2

These were Contributed-by me:
8204679: HTTP Client refresh
8197564: HTTP Client implementation
8191494: Refresh incubating HTTP Client
8170648: Move java.net.http package out of Java SE to incubator namespace
 = 4

Total commits: 14

user = prappo
email = pavel.rappo

All my commits:
8235435: Remove (obsolete) @author info from javadoc source and tests
8228580: DnsClient TCP socket timeout
8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect
8217606: LdapContext
8213431: Improve file protocol handling
8226602: Test convenience reactive primitives from java.net.http with RS TCK
8226303: Examine the HttpRequest.BodyPublishers for exception handling
8218022: Repeated words typos in java.base
8215292: Back out changes for node- and link- local ipv6 multicast address
8213490: Networking area typos and inconsistencies cleanup
8210493: Bind to node- or linklocal ipv6 multicast address fails
8212001: Verify exported symbols in java.base (libjava)
8212000: Verify exported symbols in java.base (libnet, libnio/ch)
8181612: More stable connection processing
8180155: WebSocket secure connection get stuck after onOpen
8179021: Latest bugfixes to WebSocket/HPACK from the sandbox repo
8177738: Runtime.Version must be a value-based class
8176882: Incorrect integer comparison in version numbers
8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem
8164625: Pooled HttpConnection should be removed during close
8175305: Typos in net.properties
8170116: Remove qualified exports from java.base to java.corba
8170116: Remove qualified exports from java.base to java.corba
8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url
8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url
8038079: Re-examine integration of SPNEGO authentication
8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url
8168417: Pending exceptions in java.base/windows/native/libnio
8168405: Pending exceptions in java.base/windows/native
8163586: java.net.http.RawChannel has been made public by mistake
8161474: Extract interface from java.net.http.RawChannel
8160218: HPack decoder fails when processing header in multiple ByteBuffers
8156742: Miscellaneous WebSocket API improvements
8159039: sun/net/httpclient/hpack/HeaderTableTest.java fails on some locales
8156693: Improve usability of CompletableFuture use in WebSocket API
8156650: Simplify Text message support in WebSocket API
8150785: (bf) Hoist slice and duplicate methods up to java.nio.Buffer
8156931: java.nio.Buffer tests cleanup
8087113: Websocket API and implementation
8154487: java.httpclient/sun.net.httpclient.hpack.DecoderTest failing on Windows
8153353: HPACK implementation
8151065: Typo in javax.naming.CompoundName
8064925: URLConnection::getContent needs to be updated to work with modules
8029689: (spec) Reader.read(char[], int, int) throws unspecified IndexOutOfBoundsException
8075959: Change parameter names in some IOException subclasses
8067870: Fix java.io.ObjectInputStream.PeekInputStream
8066642: Fix deprecation warnings in jdk.naming module
8066867: Add InputStream transferTo to transfer content to an OutputStream
8066678: java.nio.channels.Channels cleanup
8059311: com/sun/jndi/ldap/LdapTimeoutTest.java fails with exit_code == 0
8062759: Update test/javax/naming/spi/providers/InitialContextTest.java to use classpath
8042888: Remove extcheck tool
8042888: Remove extcheck tool
8044627: Update JNDI to work with modules
8054857: Fix typos in java.lang.** packages
8054158: Fix typos in JNDI-related packages
8051991: Flatten VersionHelper hierarchies
8051422: Remove JNDI dependency on java.applet.Applet
8051350: Update javadoc for com.sun.jndi.toolkit.corba.CorbaUtils
8050869: Convert runtime dependency to Applet to a static dependency in cosnaming
8048175: Remove redundant use of reflection on core classes from JNDI
8049884: Reduce possible timing noise in com/sun/jndi/ldap/LdapTimeoutTest.java
8047062: Improve diagnostic output in com/sun/jndi/ldap/LdapTimeoutTest.java
8048874: Replace uses of 'new Byte', 'new Short' and 'new Character' with appropriate alternative across core classes
8048267: Replace uses of 'new Long()' with appropriate alternative across core classes
8027308: HttpURLConnection should better handle URLs with literal IPv6 addresses
8024832: ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound
 = 67

But these were someone else's change that I committed:
8228580: DnsClient TCP socket timeout
8217606: LdapContext#reconnect always opens a new connection
8218022: Repeated words typos in java.base
8170116: Remove qualified exports from java.base to java.corba
8170116: Remove qualified exports from java.base to java.corba
8151065: Typo in javax.naming.CompoundName
8048874: Replace uses of 'new Byte', 'new Short' and 'new Character' with appropriate alternative across core classes
8048267: Replace uses of 'new Long()' with appropriate alternative across core classes
 = 8

These were Contributed-by me:
8204679: HTTP Client refresh
8202423: Small HTTP Client refresh
8197564: HTTP Client implementation
8191494: Refresh incubating HTTP Client
8177738: Runtime.Version must be a value-based class
8170648: Move java.net.http package out of Java SE to incubator namespace
8170648: Move java.net.http package out of Java SE to incubator namespace
8066867: Add InputStream transferTo to transfer content to an OutputStream
8055326: Fix typos in client-related packages
8042887: Remove serialver -show, this tool does not need a GUI
7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize 
8034057: Files.getFileStore and Files.isWritable do not work with SUBST'ed drives (win)
8038178: Fix corrupt license header
8040262: (fs) Misc. typos in comments and implementation
8037781: Remove sun.misc.Regexp* classes
8035158: Remove dependency on sun.misc.RegexpPool and friends
8038163: Build failure on Mac OS 10.9.2 (Mavericks) due to warning treated as error
 = 17

Total commits: 76


From jonathan.gibbons at oracle.com  Tue Dec 10 18:51:20 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 10 Dec 2019 10:51:20 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <a558e571-41fc-b656-b9bd-184de51ac202@oracle.com>

Vote: yes

From lance.andersen at oracle.com  Tue Dec 10 19:08:36 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 10 Dec 2019 14:08:36 -0500
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <85BFB1E5-90FD-4968-B629-40DF13946F55@oracle.com>

vote: yes

> On Dec 10, 2019, at 1:42 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant contributor to OpenJDK, and has made over 90 commits so far, in both JDK and the sandbox. He has worked on both core-libs and, more recently, on javadoc. Votes are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote|
> 
> <pavel.txt>

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From brian.burkhalter at oracle.com  Tue Dec 10 19:09:33 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 10 Dec 2019 11:09:33 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <66A1B185-BFEB-428D-A161-2C2DEFB28492@oracle.com>

Vote: Yes!

Brian

> On Dec 10, 2019, at 10:42 AM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant contributor to OpenJDK, and has made over 90 commits so far, in both JDK and the sandbox. He has worked on both core-libs and, more recently, on javadoc. Votes are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1] http://openjdk.java.net/census <http://openjdk.java.net/census> [2] http://openjdk.java.net/projects/#reviewer-vote| <http://openjdk.java.net/projects/#reviewer-vote|>

From chris.hegarty at oracle.com  Tue Dec 10 19:16:39 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 10 Dec 2019 19:16:39 +0000
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <B393E8AA-5FA8-42D7-A199-BD7139945DDE@oracle.com>

Vote: YES

-Chris.

> On 10 Dec 2019, at 18:42, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> |I hereby nominate Pavel Rappo to jdk Reviewer.

From naoto.sato at oracle.com  Tue Dec 10 19:18:00 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 10 Dec 2019 11:18:00 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <1d0cc5bc-7fd4-68f2-f0d3-c7bcace6969f@oracle.com>

Vote: yes

Naoto

On 12/10/19 10:42 AM, Jonathan Gibbons wrote:
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant 
> contributor to OpenJDK, and has made over 90 commits so far, in both JDK 
> and the sandbox. He has worked on both core-libs and, more recently, on 
> javadoc. Votes are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1] 
> http://openjdk.java.net/census [2] 
> http://openjdk.java.net/projects/#reviewer-vote|
> 

From james.laskey at oracle.com  Tue Dec 10 19:35:37 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 10 Dec 2019 15:35:37 -0400
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <7D1009A8-A0DC-4955-8E67-62520DD24E97@oracle.com>

Vote: yes

> On Dec 10, 2019, at 2:42 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant contributor to OpenJDK, and has made over 90 commits so far, in both JDK and the sandbox. He has worked on both core-libs and, more recently, on javadoc. Votes are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote|
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pavel.txt
URL: <https://mail.openjdk.java.net/pipermail/jdk-dev/attachments/20191210/90add665/pavel.txt>
-------------- next part --------------


From martinrb at google.com  Tue Dec 10 19:42:30 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 10 Dec 2019 11:42:30 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <CA+kOe09mbbuGVcPEhDEK9c6CimMrxXgjn9Zn_-+H0vd9Vr33Ew@mail.gmail.com>

Vote: yes

From vincent.x.ryan at oracle.com  Tue Dec 10 19:50:19 2019
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Tue, 10 Dec 2019 19:50:19 +0000
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <105B2AF6-7DF5-4B48-9F3C-F2D230162A25@oracle.com>

Vote: Yes

> On 10 Dec 2019, at 18:42, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant contributor to OpenJDK, and has made over 90 commits so far, in both JDK and the sandbox. He has worked on both core-libs and, more recently, on javadoc. Votes are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote|
> 
> <pavel.txt>


From ivan.gerasimov at oracle.com  Tue Dec 10 20:08:40 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 10 Dec 2019 12:08:40 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <cddc8b17-3bde-2fa0-958b-05ce9c98365b@oracle.com>

Vote: Yes

On 12/10/19 10:42 AM, Jonathan Gibbons wrote:
> I hereby nominate Pavel Rappo to jdk Reviewer.
>
-- 
With kind regards,
Ivan Gerasimov


From Alan.Bateman at oracle.com  Tue Dec 10 20:42:53 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Dec 2019 20:42:53 +0000
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <9a76da5d-9209-cb17-ae19-b4a0ad08255e@oracle.com>

Vote: yes

From mandy.chung at oracle.com  Tue Dec 10 20:45:12 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Dec 2019 12:45:12 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <8f322da2-20c5-a12d-0057-aeebb0ac0593@oracle.com>

Vote: yes

Mandy

From brent.christian at oracle.com  Tue Dec 10 20:59:06 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 10 Dec 2019 12:59:06 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <a6c40f41-3dcb-d23c-b481-d700b006ca3b@oracle.com>

Vote: Yes

On 12/10/2019 10:42 AM, Jonathan Gibbons wrote:
> I hereby nominate Pavel Rappo to jdk Reviewer.

From ksrinifmt at gmail.com  Tue Dec 10 21:06:43 2019
From: ksrinifmt at gmail.com (Kumar Srinivasan)
Date: Tue, 10 Dec 2019 13:06:43 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <a558e571-41fc-b656-b9bd-184de51ac202@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
 <a558e571-41fc-b656-b9bd-184de51ac202@oracle.com>
Message-ID: <CAEXt0tQgPUHyBVSnKSYoRSYRayg3e1+rXFgH0w_tbmRF2MQwOQ@mail.gmail.com>

Vote: yes

On Tue, Dec 10, 2019 at 10:51 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Vote: yes
>

From igor.ignatyev at oracle.com  Tue Dec 10 21:17:18 2019
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 10 Dec 2019 13:17:18 -0800
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <DD23D37D-9148-43D5-A0AA-880691E782EC@oracle.com>

Vote: yes

-- Igor

> On Dec 10, 2019, at 12:40 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.


From sean.coffey at oracle.com  Tue Dec 10 22:08:13 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 10 Dec 2019 22:08:13 +0000
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <23c2dd9c-c6e3-c0ed-06df-cc1432013b84@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
 <23c2dd9c-c6e3-c0ed-06df-cc1432013b84@oracle.com>
Message-ID: <454e4192-befc-468f-b013-9c4a9bc48870@oracle.com>

vote: yes

regards,
Sean.

On 10/12/2019 18:49, Jonathan Gibbons wrote:
>
> Well, I don't know what happened to the formatting in my previous 
> email. Let's try again ...
> -------------------
>
>
> I hereby nominate Pavel Rappo to jdk Reviewer.
>
> Pavel is a significant contributor to OpenJDK, and has made over 90 
> commits so far, in both JDK and the sandbox. He has worked on both 
> core-libs and, more recently, on javadoc.
>
> Votes are due by Dec 24.
>
> Only current jdk Reviewers [1] 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 [2].
>
> Jonathan Gibbons
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote|
>

From christoph.langer at sap.com  Tue Dec 10 22:39:02 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 10 Dec 2019 22:39:02 +0000
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <DB8PR02MB55472FCD24EF9FD0AA18D53B8A5B0@DB8PR02MB5547.eurprd02.prod.outlook.com>

Vote: yes

/Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Jonathan
> Gibbons
> Sent: Dienstag, 10. Dezember 2019 19:42
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: CFV: New jdk Reviewer: Pavel Rappo
> 
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant
> contributor to OpenJDK, and has made over 90 commits so far, in both JDK
> and the sandbox. He has worked on both core-libs and, more recently, on
> javadoc. Votes are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1]
> http://openjdk.java.net/census [2]
> http://openjdk.java.net/projects/#reviewer-vote|


From joe.darcy at oracle.com  Tue Dec 10 22:44:34 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 10 Dec 2019 14:44:34 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <13a27fb8-c496-d4cc-17cc-0e631b7b3793@oracle.com>

Vote: yes

On 12/10/2019 10:42 AM, Jonathan Gibbons wrote:
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant 
> contributor to OpenJDK, and has made over 90 commits so far, in both 
> JDK and the sandbox. He has worked on both core-libs and, more 
> recently, on javadoc. Votes are due by Dec 24. Only current jdk 
> Reviewers [1] 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 [2]. Jonathan Gibbons [1] 
> http://openjdk.java.net/census [2] 
> http://openjdk.java.net/projects/#reviewer-vote|
>

From maurizio.cimadamore at oracle.com  Tue Dec 10 23:45:56 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 10 Dec 2019 23:45:56 +0000
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <90fe2980-b8a3-4290-cb98-12788f673bde@oracle.com>

Vote: yes!

Maurizio

On 10/12/2019 18:42, Jonathan Gibbons wrote:
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant 
> contributor to OpenJDK, and has made over 90 commits so far, in both 
> JDK and the sandbox. He has worked on both core-libs and, more 
> recently, on javadoc. Votes are due by Dec 24. Only current jdk 
> Reviewers [1] 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 [2]. Jonathan Gibbons [1] 
> http://openjdk.java.net/census [2] 
> http://openjdk.java.net/projects/#reviewer-vote|
>

From mark.reinhold at oracle.com  Wed Dec 11 00:03:05 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 10 Dec 2019 16:03:05 -0800
Subject: JEP proposed to target JDK 14: 362: Deprecate the Solaris and
 SPARC Ports
In-Reply-To: <20191203233122.09CA03102DB@eggemoggin.niobe.net>
References: <20191203233122.09CA03102DB@eggemoggin.niobe.net>
Message-ID: <20191210160305.859889752@eggemoggin.niobe.net>

2019/12/3 15:31:22 -0800, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 14:
> 
>   362: Deprecate the Solaris and SPARC Ports
>        https://openjdk.java.net/jeps/362
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Tuesday, 10 December, or if they?re raised
> and then satisfactorily answered, then per the JEP 2.0 process proposal
> [2] I?ll target this JEP to JDK 14.

Hearing no objections, I?ve targeted this JEP to JDK 14.

- Mark

From stuart.marks at oracle.com  Wed Dec 11 02:15:34 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 10 Dec 2019 18:15:34 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <8e229d9b-648c-46a9-78c9-ca9caca80902@oracle.com>

Vote: yes

On 12/10/19 10:42 AM, Jonathan Gibbons wrote:
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant 
> contributor to OpenJDK, and has made over 90 commits so far, in both JDK and the 
> sandbox. He has worked on both core-libs and, more recently, on javadoc. Votes 
> are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1] 
> http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote|
> 

From weijun.wang at oracle.com  Wed Dec 11 02:34:14 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 11 Dec 2019 10:34:14 +0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <56E3F9E4-4F87-42F1-9E3B-9ABD38487E3A@oracle.com>

Vote: yes.

--weijun

> On Dec 11, 2019, at 2:42 AM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant contributor to OpenJDK, and has made over 90 commits so far, in both JDK and the sandbox. He has worked on both core-libs and, more recently, on javadoc. Votes are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote|
> 
> <pavel.txt>


From per.liden at oracle.com  Wed Dec 11 07:46:19 2019
From: per.liden at oracle.com (Per Liden)
Date: Wed, 11 Dec 2019 08:46:19 +0100
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <732e86e9-6ce0-d8e3-ba27-3d581a5ccb68@oracle.com>

Vote: yes

/Per

On 12/10/19 9:40 AM, Tobias Hartmann wrote:
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 

From michael.x.mcmahon at oracle.com  Wed Dec 11 09:27:08 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 11 Dec 2019 09:27:08 +0000
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <23c2dd9c-c6e3-c0ed-06df-cc1432013b84@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
 <23c2dd9c-c6e3-c0ed-06df-cc1432013b84@oracle.com>
Message-ID: <df1cbd3f-acbc-a9ba-3eee-aa271defc7ea@oracle.com>

Vote: Yes

On 10/12/2019 18:49, Jonathan Gibbons wrote:
>
> I hereby nominate Pavel Rappo to jdk Reviewer.
>

From hannes.wallnoefer at oracle.com  Wed Dec 11 09:42:33 2019
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 11 Dec 2019 10:42:33 +0100
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <847F83C4-ED30-4B03-B04B-0DA6F4EFC1BE@oracle.com>

Vote: yes!

Hannes


> Am 10.12.2019 um 19:42 schrieb Jonathan Gibbons <jonathan.gibbons at oracle.com>:
> 
> |I hereby nominate Pavel Rappo to jdk Reviewer. 

From dmitry.markov at oracle.com  Wed Dec 11 09:47:31 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Wed, 11 Dec 2019 09:47:31 +0000
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <60790748-EF34-4097-B391-8B7976AE4D80@oracle.com>

Vote: yes

Thanks,
Dmitry

> On 10 Dec 2019, at 18:42, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant contributor to OpenJDK, and has made over 90 commits so far, in both JDK and the sandbox. He has worked on both core-libs and, more recently, on javadoc. Votes are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote|
> 
> <pavel.txt>


From adinn at redhat.com  Wed Dec 11 12:06:01 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 11 Dec 2019 12:06:01 +0000
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <ca473f8a-1482-5a7f-08f5-3819e615dfcf@redhat.com>

Vote: yes

On 10/12/2019 18:42, Jonathan Gibbons wrote:
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant
> contributor to OpenJDK, and has made over 90 commits so far, in both JDK
> and the sandbox. He has worked on both core-libs and, more recently, on
> javadoc. Votes are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1]
> http://openjdk.java.net/census [2]
> http://openjdk.java.net/projects/#reviewer-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


From erik.osterlund at oracle.com  Wed Dec 11 12:13:04 2019
From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=)
Date: Wed, 11 Dec 2019 13:13:04 +0100
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <BA1FB851-4B4F-40A6-9D3B-D5C040723A63@oracle.com>

Vote: yes

/Erik

> On 10 Dec 2019, at 09:41, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> ?Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From kim.barrett at oracle.com  Wed Dec 11 12:52:37 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Dec 2019 07:52:37 -0500
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <94FDA71C-D7F1-46D7-BCD2-BFE497834B7D@oracle.com>

vote: yes

> On Dec 10, 2019, at 3:40 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus



From Roger.Riggs at oracle.com  Wed Dec 11 14:24:12 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 11 Dec 2019 09:24:12 -0500
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <06ca300b-05ff-2e08-7d3d-81e0d58149f0@oracle.com>

Vote: Yes

On 12/10/19 1:42 PM, Jonathan Gibbons wrote:
> I hereby nominate Pavel Rappo to jdk Reviewer. 


From iris.clark at oracle.com  Wed Dec 11 17:39:34 2019
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 11 Dec 2019 09:39:34 -0800 (PST)
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <23c2dd9c-c6e3-c0ed-06df-cc1432013b84@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
 <23c2dd9c-c6e3-c0ed-06df-cc1432013b84@oracle.com>
Message-ID: <5538fe24-7835-49da-9d91-aef5c4f3edc9@default>

Vote: yes

Iris

From anton.litvinov at oracle.com  Thu Dec 12 13:40:57 2019
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Thu, 12 Dec 2019 13:40:57 +0000
Subject: CFV: New JDK Committer: Julia Boes
In-Reply-To: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
References: <5dd0c3af-94df-6113-670e-81fd63bd9be9@oracle.com>
Message-ID: <74050b70-0c58-febb-7581-0847642b346e@oracle.com>

Vote: yes

Thank you,
Anton

On 29/11/2019 19:12, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Julia Boes (jboes) to JDK Committer.
>
> Julia is a member of the java core libraries team at Oracle.
> Julia already contributed 16 fixes to the JDK project [1].
>
> Votes are due by 12:00 UTC December 14th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
>
> -- daniel
>
> [1] 
> https://hg.openjdk.java.net/jdk/jdk/log?rev=keyword(8185898)+or+keyword(julia.boes)+or+keyword(jboes)&revcount=20
>
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From mark.reinhold at oracle.com  Thu Dec 12 17:45:31 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 12 Dec 2019 09:45:31 -0800 (PST)
Subject: JDK 14 is now in Rampdown Phase One
Message-ID: <20191212174531.60C0A31142C@eggemoggin.niobe.net>

Per the JDK 14 schedule [1], we are now in Rampdown Phase One.

The overall feature set is frozen.  No further JEPs will be targeted to
this release except possibly JEP 370 [2], assuming that no one objects by
the end of its review period later today and that it can be integrated
immediately.

We?ve forked the main-line source repository, jdk/jdk, to the jdk/jdk14
stabilization repository.  Any changes pushed to jdk/jdk are now bound
for JDK 15, as noted previously [3].

The stabilization repository is open for select bug fixes and, with
approval, late enhancements per JEP 3, the JDK Release Process [4].
If you?re responsible for any of the bugs on the RDP 1 candidate-bug
list [5] then please see JEP 3 for guidance on how to handle them.

- Mark


[1] https://openjdk.java.net/projects/jdk/14/#Schedule
[2] https://openjdk.java.net/jeps/370
[3] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-December/003709.html
[4] https://openjdk.java.net/jeps/3
[5] https://j.mp/jdk-rdp-1

From mark.reinhold at oracle.com  Thu Dec 12 23:00:14 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 12 Dec 2019 15:00:14 -0800
Subject: JEP proposed to target JDK 14: 370: Foreign-Memory Access API
 (Incubator)
In-Reply-To: <20191205223109.63BFB3107AA@eggemoggin.niobe.net>
References: <20191205223109.63BFB3107AA@eggemoggin.niobe.net>
Message-ID: <20191212150014.723419765@eggemoggin.niobe.net>

2019/12/5 14:31:09 -0800, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 14:
> 
>   370: Foreign-Memory Access API (Incubator)
>        https://openjdk.java.net/jeps/370
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:00 UTC on Thursday, 12 December, or if they?re raised
> and then satisfactorily answered, then per the JEP 2.0 process proposal
> [2] I?ll target this JEP to JDK 14.

Hearing no objections, I?ve targeted this JEP to JDK 14.

- Mark

From goetz.lindenmaier at sap.com  Fri Dec 13 08:12:55 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 13 Dec 2019 08:12:55 +0000
Subject: <AWT Dev> [14] Review Request: 8185041 Incorrect GPL header in
 pnglibconf.h
In-Reply-To: <5DE70CBB.6010602@oracle.com>
References: <cfe24d72-d091-7f49-bf45-b38953afcc44@oracle.com>
 <5DE70CBB.6010602@oracle.com>
Message-ID: <AM6PR02MB5347BAE65086C121F7A4AFE4EC540@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi,

Is there a good reason this is a closed change?
If not, could you please open it up?

Thanks,
  Goetz.

> -----Original Message-----
> From: awt-dev <awt-dev-bounces at openjdk.java.net> On Behalf Of Philip
> Race
> Sent: Wednesday, December 4, 2019 2:33 AM
> To: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [14] Review Request: 8185041 Incorrect GPL header
> in pnglibconf.h
> 
> +1
> 
> -phil.
> 
> On 10/7/19, 12:16 PM, Sergey Bylokhov wrote:
> > Hello.
> > Please review the fix for JDK 14.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8185041
> > Fix: http://cr.openjdk.java.net/~serb/8185041/webrev.00
> >
> > The file header has been updated and formatted as other files of
> > libpng library.
> >

From huizhe.wang at oracle.com  Fri Dec 13 16:56:17 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 13 Dec 2019 08:56:17 -0800
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <d6ebf790-f173-4af2-ad8c-3d6fe0c1635a@oracle.com>

vote: yes


Best regards,
Joe (java.net id: joehw)

On 12/10/19 10:42 AM, Jonathan Gibbons wrote:
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant 
> contributor to OpenJDK, and has made over 90 commits so far, in both 
> JDK and the sandbox. He has worked on both core-libs and, more 
> recently, on javadoc. Votes are due by Dec 24. Only current jdk 
> Reviewers [1] 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 [2]. Jonathan Gibbons [1] 
> http://openjdk.java.net/census [2] 
> http://openjdk.java.net/projects/#reviewer-vote|
>


From bsrbnd at gmail.com  Fri Dec 13 19:31:01 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 13 Dec 2019 20:31:01 +0100
Subject: CFV: New JDK Committer: Sandhya Viswanathan
In-Reply-To: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
References: <03416992-b92b-12f1-690e-9d80bbdfd652@oracle.com>
Message-ID: <CAEgw74D5OavMxRC3yzHnFvLvwtJxkHyRNSYy470si+m9HjKuxg@mail.gmail.com>

Vote: yes

Regards,
Bernard

On Thu, 5 Dec 2019 at 20:00, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
> I hereby nominate Sandhya Viswanathan (sviswanathan) to JDK Committer.
> [...]

From daniel.fuchs at oracle.com  Mon Dec 16 19:44:21 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 16 Dec 2019 20:44:21 +0100
Subject: Result: CFV: New JDK Committer: Julia Boes
Message-ID: <07ae5482-cec8-4484-76da-f8ccda03d402@oracle.com>

Voting for Julia Boes [1] continued in [2] is now closed.

Yes: 29
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

best regards,

-- daniel

[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003661.html
[2] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2019-December/003669.html

From dennis at gesker.com  Mon Dec 16 23:12:28 2019
From: dennis at gesker.com (Dennis Gesker)
Date: Mon, 16 Dec 2019 16:12:28 -0700
Subject: NPE on getEnclosingMethod()
Message-ID: <CAJRXDBOdV9PqDen_YjzgaYB3rY=YwPb5UiQwZziqGy82EhU7_g@mail.gmail.com>

Hello OpenJDK list...

I do hope this is the correct list for user questions. I'm getting a NULL
when calling:

this.getClass().getEnclosingMethod()

I was going to file a bug but I'm not yet a contributor and hope to get
login credentials soon. Any chance an existing member could take a look at
my unit test below? And, if verified and not duplicate file a bug report on
my behalf?

Thanks,
Dennis

Using:

openjdk version "11.0.5-ea" 2019-10-15
OpenJDK Runtime Environment (build 11.0.5-ea+10-post-Ubuntu-0ubuntu1)
OpenJDK 64-Bit Server VM (build 11.0.5-ea+10-post-Ubuntu-0ubuntu1, mixed
mode, sharing)

The following test compiles (-Xlint:all -Werror) but throws and NPE on
execution:

package test;

import static org.junit.Assert.assertTrue;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.junit.jupiter.api.Test;

public class CheckForNullEnclosingMethod {
private Logger logger = Logger.getLogger(this.getClass().getSimpleName());

@Test
public void iSeemToBeLost() {

if (this.getClass().getEnclosingMethod() == null) {
logger.logp(Level.SEVERE, this.getClass().getName(),
this.getClass().getEnclosingMethod().getName(),
"What method am I in?");
assertTrue(this.getClass().getEnclosingMethod() == null);
assertTrue(this.getClass().getEnclosingMethod().getName() == null);
return;
}

logger.logp(Level.INFO, this.getClass().getName(),
this.getClass().getEnclosingMethod().getName(),
"No worries, I'm not lost");
assertTrue(this.getClass().getEnclosingMethod() != null);
assertTrue(this.getClass().getEnclosingMethod().getName() != null);

}
}

From claes.redestad at oracle.com  Tue Dec 17 00:14:41 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 17 Dec 2019 01:14:41 +0100
Subject: NPE on getEnclosingMethod()
In-Reply-To: <CAJRXDBOdV9PqDen_YjzgaYB3rY=YwPb5UiQwZziqGy82EhU7_g@mail.gmail.com>
References: <CAJRXDBOdV9PqDen_YjzgaYB3rY=YwPb5UiQwZziqGy82EhU7_g@mail.gmail.com>
Message-ID: <19df305c-7920-0e35-40dc-eeb6dce03350@oracle.com>

Hi Dennis,

On 2019-12-17 00:12, Dennis Gesker wrote:
> Hello OpenJDK list...
> 
> I do hope this is the correct list for user questions. 

not really, but since you suspected this was a bug I had a look. :-)

> I'm getting a NULL when calling:
> 
> this.getClass().getEnclosingMethod()

according to the javadoc[1], Class::getEnclosingMethod return "the
immediately enclosing method of the underlying class, if that class is a
local or anonymous class; otherwise *null*."

In your test case, 'this' seems to be an instance of the unit test,
which is a regular class. So this.getClass().getEnclosingMethod()
returning null seems to be the expected result.

To demonstrate, see this example of getEnclosingMethod() on a local,
anonymous and a regular class:

public class Enclosing {

   public void foo() {
     class Foo {}; // Local class
     System.out.println(Foo.class.getEnclosingMethod());

     // Anonymous class
     Object bar = new Object() {}; // Anonymous class
     System.out.println(bar.getClass().getEnclosingMethod());

     System.out.println(this.getClass().getEnclosingMethod());
   }

   public static void main(String ... args) {
     new Enclosing().foo();
   }
}

.. which prints:

public void Enclosing.foo()
public void Enclosing.foo()
null

Hope this makes sense!

/Claes

[1] 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Class.html#getEnclosingMethod()

> 
> I was going to file a bug but I'm not yet a contributor and hope to get
> login credentials soon. Any chance an existing member could take a look at
> my unit test below? And, if verified and not duplicate file a bug report on
> my behalf?
> 
> Thanks,
> Dennis
> 
> Using:
> 
> openjdk version "11.0.5-ea" 2019-10-15
> OpenJDK Runtime Environment (build 11.0.5-ea+10-post-Ubuntu-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 11.0.5-ea+10-post-Ubuntu-0ubuntu1, mixed
> mode, sharing)
> 
> The following test compiles (-Xlint:all -Werror) but throws and NPE on
> execution:
> 
> package test;
> 
> import static org.junit.Assert.assertTrue;
> import java.util.logging.Level;
> import java.util.logging.Logger;
> import org.junit.jupiter.api.Test;
> 
> public class CheckForNullEnclosingMethod {
> private Logger logger = Logger.getLogger(this.getClass().getSimpleName());
> 
> @Test
> public void iSeemToBeLost() {
> 
> if (this.getClass().getEnclosingMethod() == null) {
> logger.logp(Level.SEVERE, this.getClass().getName(),
> this.getClass().getEnclosingMethod().getName(),
> "What method am I in?");
> assertTrue(this.getClass().getEnclosingMethod() == null);
> assertTrue(this.getClass().getEnclosingMethod().getName() == null);
> return;
> }
> 
> logger.logp(Level.INFO, this.getClass().getName(),
> this.getClass().getEnclosingMethod().getName(),
> "No worries, I'm not lost");
> assertTrue(this.getClass().getEnclosingMethod() != null);
> assertTrue(this.getClass().getEnclosingMethod().getName() != null);
> 
> }
> }
> 

From david.holmes at oracle.com  Tue Dec 17 00:22:12 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Dec 2019 10:22:12 +1000
Subject: NPE on getEnclosingMethod()
In-Reply-To: <CAJRXDBOdV9PqDen_YjzgaYB3rY=YwPb5UiQwZziqGy82EhU7_g@mail.gmail.com>
References: <CAJRXDBOdV9PqDen_YjzgaYB3rY=YwPb5UiQwZziqGy82EhU7_g@mail.gmail.com>
Message-ID: <77e341c9-02ea-255a-1b4a-9a15088261f6@oracle.com>

Hi Dennis,

On 17/12/2019 9:12 am, Dennis Gesker wrote:
> Hello OpenJDK list...
> 
> I do hope this is the correct list for user questions. 

OpenJDK lists are for OpenJDK developers not end-users.

> I'm getting a NULL when calling:
> 
> this.getClass().getEnclosingMethod()

As you would if not called from a nested type defined within a method.

assertTrue(this.getClass().getEnclosingMethod() == null);
assertTrue(this.getClass().getEnclosingMethod().getName() == null);

If you pass the first assert you're guaranteed to get a NPE when calling 
getName() on the second.

Cheers,
David
-----

> I was going to file a bug but I'm not yet a contributor and hope to get
> login credentials soon. Any chance an existing member could take a look at
> my unit test below? And, if verified and not duplicate file a bug report on
> my behalf?
> 
> Thanks,
> Dennis
> 
> Using:
> 
> openjdk version "11.0.5-ea" 2019-10-15
> OpenJDK Runtime Environment (build 11.0.5-ea+10-post-Ubuntu-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 11.0.5-ea+10-post-Ubuntu-0ubuntu1, mixed
> mode, sharing)
> 
> The following test compiles (-Xlint:all -Werror) but throws and NPE on
> execution:
> 
> package test;
> 
> import static org.junit.Assert.assertTrue;
> import java.util.logging.Level;
> import java.util.logging.Logger;
> import org.junit.jupiter.api.Test;
> 
> public class CheckForNullEnclosingMethod {
> private Logger logger = Logger.getLogger(this.getClass().getSimpleName());
> 
> @Test
> public void iSeemToBeLost() {
> 
> if (this.getClass().getEnclosingMethod() == null) {
> logger.logp(Level.SEVERE, this.getClass().getName(),
> this.getClass().getEnclosingMethod().getName(),
> "What method am I in?");
> assertTrue(this.getClass().getEnclosingMethod() == null);
> assertTrue(this.getClass().getEnclosingMethod().getName() == null);
> return;
> }
> 
> logger.logp(Level.INFO, this.getClass().getName(),
> this.getClass().getEnclosingMethod().getName(),
> "No worries, I'm not lost");
> assertTrue(this.getClass().getEnclosingMethod() != null);
> assertTrue(this.getClass().getEnclosingMethod().getName() != null);
> 
> }
> }
> 

From dennis at gesker.com  Tue Dec 17 00:34:54 2019
From: dennis at gesker.com (Dennis Gesker)
Date: Mon, 16 Dec 2019 17:34:54 -0700
Subject: NPE on getEnclosingMethod()
In-Reply-To: <77e341c9-02ea-255a-1b4a-9a15088261f6@oracle.com>
References: <CAJRXDBOdV9PqDen_YjzgaYB3rY=YwPb5UiQwZziqGy82EhU7_g@mail.gmail.com>
 <77e341c9-02ea-255a-1b4a-9a15088261f6@oracle.com>
Message-ID: <CAJRXDBOGQZWUubqEQCVv5F97VM18KJYqSnmkc3PQ8-BoH15oyQ@mail.gmail.com>

Claes and David:

Thank you both. Much appreciated!

Dennis

On Mon, Dec 16, 2019 at 5:22 PM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Dennis,
>
> On 17/12/2019 9:12 am, Dennis Gesker wrote:
> > Hello OpenJDK list...
> >
> > I do hope this is the correct list for user questions.
>
> OpenJDK lists are for OpenJDK developers not end-users.
>
> > I'm getting a NULL when calling:
> >
> > this.getClass().getEnclosingMethod()
>
> As you would if not called from a nested type defined within a method.
>
> assertTrue(this.getClass().getEnclosingMethod() == null);
> assertTrue(this.getClass().getEnclosingMethod().getName() == null);
>
> If you pass the first assert you're guaranteed to get a NPE when calling
> getName() on the second.
>
> Cheers,
> David
> -----
>
> > I was going to file a bug but I'm not yet a contributor and hope to get
> > login credentials soon. Any chance an existing member could take a look
> at
> > my unit test below? And, if verified and not duplicate file a bug report
> on
> > my behalf?
> >
> > Thanks,
> > Dennis
> >
> > Using:
> >
> > openjdk version "11.0.5-ea" 2019-10-15
> > OpenJDK Runtime Environment (build 11.0.5-ea+10-post-Ubuntu-0ubuntu1)
> > OpenJDK 64-Bit Server VM (build 11.0.5-ea+10-post-Ubuntu-0ubuntu1, mixed
> > mode, sharing)
> >
> > The following test compiles (-Xlint:all -Werror) but throws and NPE on
> > execution:
> >
> > package test;
> >
> > import static org.junit.Assert.assertTrue;
> > import java.util.logging.Level;
> > import java.util.logging.Logger;
> > import org.junit.jupiter.api.Test;
> >
> > public class CheckForNullEnclosingMethod {
> > private Logger logger =
> Logger.getLogger(this.getClass().getSimpleName());
> >
> > @Test
> > public void iSeemToBeLost() {
> >
> > if (this.getClass().getEnclosingMethod() == null) {
> > logger.logp(Level.SEVERE, this.getClass().getName(),
> > this.getClass().getEnclosingMethod().getName(),
> > "What method am I in?");
> > assertTrue(this.getClass().getEnclosingMethod() == null);
> > assertTrue(this.getClass().getEnclosingMethod().getName() == null);
> > return;
> > }
> >
> > logger.logp(Level.INFO, this.getClass().getName(),
> > this.getClass().getEnclosingMethod().getName(),
> > "No worries, I'm not lost");
> > assertTrue(this.getClass().getEnclosingMethod() != null);
> > assertTrue(this.getClass().getEnclosingMethod().getName() != null);
> >
> > }
> > }
> >
>


-- 

Dennis R. Gesker
[image: LinkedIn] <http://www.linkedin.com/in/gesker/>[image: WordPress]
<https://dennis.gesker.com>[image: Gesker] <http://www.gesker.com/>[image:
GPG_PGP] <http://www.gesker.com/home/dennis-gpg-key>[image:
dennis at gesker.com] <dennis at gesker.com>
?Be without fear in the face of your enemies. Be brave and upright that God
may love thee. Speak the truth always, even if it leads to your death.
Safeguard the helpless and do no wrong ? that is your oath.?* -The Knight?s
Oath (Kingdom of Heaven)*

From alexey.ivanov at oracle.com  Tue Dec 17 16:16:43 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 17 Dec 2019 16:16:43 +0000
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <23c2dd9c-c6e3-c0ed-06df-cc1432013b84@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
 <23c2dd9c-c6e3-c0ed-06df-cc1432013b84@oracle.com>
Message-ID: <614cc9d5-dc17-9d84-942e-e12442eb4757@oracle.com>

Vote: yes

On 10/12/2019 18:49, Jonathan Gibbons wrote:
> I hereby nominate Pavel Rappo to jdk Reviewer. 
-- 
Regards,
Alexey

From volker.simonis at gmail.com  Tue Dec 17 16:27:53 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 17 Dec 2019 17:27:53 +0100
Subject: CFV: New jdk Reviewer: Pavel Rappo
In-Reply-To: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
References: <1e337158-81c6-7dce-45df-17d7aef33a22@oracle.com>
Message-ID: <CA+3eh10pnb-uudS4rauxvfMtDv2iUfzipggL3Q1ccsDD4pvNcg@mail.gmail.com>

Vote: yes

On Tue, Dec 10, 2019 at 7:44 PM Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
>
> |I hereby nominate Pavel Rappo to jdk Reviewer. Pavel is a significant
> contributor to OpenJDK, and has made over 90 commits so far, in both JDK
> and the sandbox. He has worked on both core-libs and, more recently, on
> javadoc. Votes are due by Dec 24. Only current jdk Reviewers [1] 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 [2]. Jonathan Gibbons [1]
> http://openjdk.java.net/census [2]
> http://openjdk.java.net/projects/#reviewer-vote|
>

From vladimir.x.ivanov at oracle.com  Wed Dec 18 18:28:42 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 18 Dec 2019 21:28:42 +0300
Subject: CFV: New JDK Committer: Jatin Bhateja
Message-ID: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>

I hereby nominate Jatin Bhateja (jbhateja) to Committer in JDK Project.

Jatin Bhateja is a member of Java team at Intel. So far, he contributed 
12 significant changes [1] to the JDK project. Most notably, one of the 
contributions is a major refactoring of AD files in order to reduce the 
number of AD instructions needed for auto-vectorization support in C2 on 
x86.

Also, Jatin is a Committer in Project Panama and contributes to Vector 
API there.

Votes are due by January, 1, 2020.

Only current JDK Committers [2] 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 [3].

Best regards,
Vladimir Ivanov

[1] 
http://hg.openjdk.java.net/jdk/jdk/search/?rev=author%28jbhateja%29&revcount=20
     http://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a
[2] http://openjdk.java.net/census
[3] http://openjdk.java.net/projects/#reviewer-vote

From vladimir.x.ivanov at oracle.com  Wed Dec 18 18:29:10 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 18 Dec 2019 21:29:10 +0300
Subject: CFV: New JDK Committer: Jatin Bhateja
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <1445494b-bfa2-8e01-152f-748e5d35d29b@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

On 18.12.2019 21:28, Vladimir Ivanov wrote:
> I hereby nominate Jatin Bhateja (jbhateja) to Committer in JDK Project.

From eric.caspole at oracle.com  Wed Dec 18 19:00:13 2019
From: eric.caspole at oracle.com (Eric Caspole)
Date: Wed, 18 Dec 2019 14:00:13 -0500
Subject: CFV: New JDK Committer: Jatin Bhateja
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <42eb7c75-c393-801a-3165-e32f8831b2c3@oracle.com>

Vote: yes

On 12/18/19 13:28, Vladimir Ivanov wrote:
> I hereby nominate Jatin Bhateja (jbhateja) to Committer in JDK Project.
> 
> Jatin Bhateja is a member of Java team at Intel. So far, he contributed 
> 12 significant changes [1] to the JDK project. Most notably, one of the 
> contributions is a major refactoring of AD files in order to reduce the 
> number of AD instructions needed for auto-vectorization support in C2 on 
> x86.
> 
> Also, Jatin is a Committer in Project Panama and contributes to Vector 
> API there.
> 
> Votes are due by January, 1, 2020.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=author%28jbhateja%29&revcount=20 
> 
>  ??? http://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/projects/#reviewer-vote

From john.r.rose at oracle.com  Wed Dec 18 19:14:34 2019
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Dec 2019 11:14:34 -0800
Subject: CFV: New JDK Committer: Jatin Bhateja
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <1B26A946-7DC5-4E43-BF68-709ADDCD9BEE@oracle.com>

Vote: yes


From paul.sandoz at oracle.com  Wed Dec 18 20:14:16 2019
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 18 Dec 2019 12:14:16 -0800
Subject: CFV: New JDK Committer: Jatin Bhateja
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <B1045182-C4C9-4208-A5BA-12839726B77A@oracle.com>

Vote: yes

Paul.

From vladimir.kozlov at oracle.com  Wed Dec 18 20:35:39 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 18 Dec 2019 12:35:39 -0800
Subject: CFV: New JDK Committer: Jatin Bhateja
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <79fa597e-30fd-fe3d-b21b-96247e73ff13@oracle.com>

Vote: yes

On 12/18/19 10:28 AM, Vladimir Ivanov wrote:
> I hereby nominate Jatin Bhateja (jbhateja) to Committer in JDK Project.
> 
> Jatin Bhateja is a member of Java team at Intel. So far, he contributed 12 significant changes [1] to the JDK project. 
> Most notably, one of the contributions is a major refactoring of AD files in order to reduce the number of AD 
> instructions needed for auto-vectorization support in C2 on x86.
> 
> Also, Jatin is a Committer in Project Panama and contributes to Vector API there.
> 
> Votes are due by January, 1, 2020.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=author%28jbhateja%29&revcount=20
>  ??? http://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/projects/#reviewer-vote

From tobias.hartmann at oracle.com  Thu Dec 19 06:09:38 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 19 Dec 2019 07:09:38 +0100
Subject: CFV: New JDK Committer: Jatin Bhateja
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <148b81c0-cbe9-7bda-0c54-dc5be5690128@oracle.com>

Vote: yes

Best regards,
Tobias

On 18.12.19 19:28, Vladimir Ivanov wrote:
> I hereby nominate Jatin Bhateja (jbhateja) to Committer in JDK Project.
> 
> Jatin Bhateja is a member of Java team at Intel. So far, he contributed 12 significant changes [1]
> to the JDK project. Most notably, one of the contributions is a major refactoring of AD files in
> order to reduce the number of AD instructions needed for auto-vectorization support in C2 on x86.
> 
> Also, Jatin is a Committer in Project Panama and contributes to Vector API there.
> 
> Votes are due by January, 1, 2020.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=author%28jbhateja%29&revcount=20
> ??? http://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/projects/#reviewer-vote

From richard.reingruber at sap.com  Thu Dec 19 08:04:16 2019
From: richard.reingruber at sap.com (Reingruber, Richard)
Date: Thu, 19 Dec 2019 08:04:16 +0000
Subject: CFV: New JDK Committer: Jatin Bhateja
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <DB7PR02MB3612519DC895C4176EE35A689B520@DB7PR02MB3612.eurprd02.prod.outlook.com>

Vote: yes

Richard.

-----Original Message-----
From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Vladimir Ivanov
Sent: Mittwoch, 18. Dezember 2019 19:29
To: jdk-dev at openjdk.java.net
Subject: CFV: New JDK Committer: Jatin Bhateja

I hereby nominate Jatin Bhateja (jbhateja) to Committer in JDK Project.

Jatin Bhateja is a member of Java team at Intel. So far, he contributed 
12 significant changes [1] to the JDK project. Most notably, one of the 
contributions is a major refactoring of AD files in order to reduce the 
number of AD instructions needed for auto-vectorization support in C2 on 
x86.

Also, Jatin is a Committer in Project Panama and contributes to Vector 
API there.

Votes are due by January, 1, 2020.

Only current JDK Committers [2] 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 [3].

Best regards,
Vladimir Ivanov

[1] 
http://hg.openjdk.java.net/jdk/jdk/search/?rev=author%28jbhateja%29&revcount=20
     http://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a
[2] http://openjdk.java.net/census
[3] http://openjdk.java.net/projects/#reviewer-vote

From adinn at redhat.com  Thu Dec 19 13:42:25 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 19 Dec 2019 13:42:25 +0000
Subject: CFV: New JDK Committer: Jatin Bhateja
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <93a066b0-b0f1-b628-a7d8-048d86a6e632@redhat.com>

Vote: yes

On 18/12/2019 18:28, Vladimir Ivanov wrote:
> I hereby nominate Jatin Bhateja (jbhateja) to Committer in JDK Project.
> 
> Jatin Bhateja is a member of Java team at Intel. So far, he contributed
> 12 significant changes [1] to the JDK project. Most notably, one of the
> contributions is a major refactoring of AD files in order to reduce the
> number of AD instructions needed for auto-vectorization support in C2 on
> x86.
> 
> Also, Jatin is a Committer in Project Panama and contributes to Vector
> API there.
> 
> Votes are due by January, 1, 2020.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Vladimir Ivanov
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=author%28jbhateja%29&revcount=20
> 
> ??? http://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/projects/#reviewer-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


From felixxfyang at tencent.com  Thu Dec 19 14:58:19 2019
From: felixxfyang at tencent.com (=?utf-8?B?ZmVsaXh4Znlhbmco5p2o5pmT5bOwKQ==?=)
Date: Thu, 19 Dec 2019 14:58:19 +0000
Subject: New JDK Committer: Jatin Bhateja(Internet mail)
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <EF098EB1-EC44-4661-8E67-4607D72B65A8@tencent.com>

Vote: Yes

Best regards,
Felix Yang

?? 2019/12/19 ??2:30??jdk-dev ?? Vladimir Ivanov?<jdk-dev-bounces at openjdk.java.net ?? vladimir.x.ivanov at oracle.com> ??:

    I hereby nominate Jatin Bhateja (jbhateja) to Committer in JDK Project.
    
    Jatin Bhateja is a member of Java team at Intel. So far, he contributed 
    12 significant changes [1] to the JDK project. Most notably, one of the 
    contributions is a major refactoring of AD files in order to reduce the 
    number of AD instructions needed for auto-vectorization support in C2 on 
    x86.
    
    Also, Jatin is a Committer in Project Panama and contributes to Vector 
    API there.
    
    Votes are due by January, 1, 2020.
    
    Only current JDK Committers [2] 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 [3].
    
    Best regards,
    Vladimir Ivanov
    
    [1] 
    http://hg.openjdk.java.net/jdk/jdk/search/?rev=author%28jbhateja%29&revcount=20
         http://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a
    [2] http://openjdk.java.net/census
    [3] http://openjdk.java.net/projects/#reviewer-vote
    
    


From bsrbnd at gmail.com  Thu Dec 19 15:32:47 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Thu, 19 Dec 2019 16:32:47 +0100
Subject: CFV: New JDK Committer: Jatin Bhateja
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <CAEgw74BxDsLuWg=WvXNJsEB7JFa4yuSdo56xVcax77wQq-E_qg@mail.gmail.com>

Vote: yes

Regards,
Bernard

On Wed, 18 Dec 2019 at 19:29, Vladimir Ivanov
<vladimir.x.ivanov at oracle.com> wrote:
>
> I hereby nominate Jatin Bhateja (jbhateja) to Committer in JDK Project.
> [...]

From greenrecyclebin at gmail.com  Thu Dec 19 07:35:57 2019
From: greenrecyclebin at gmail.com (Daniel Le Duc Khoi Nguyen)
Date: Thu, 19 Dec 2019 15:35:57 +0800
Subject: [PATCH] JDK-8233680: JavacFileManager.close() doesn't clear some
 cache instance variables
Message-ID: <CANtZXCq3Ly-nC7kcYm77Ys-4L0=-fPpZ9HgmXxd1TBqxJHGGfg@mail.gmail.com>

Hi everyone,

I've already included all relevant information at
https://bugs.openjdk.java.net/browse/JDK-8233680. I'm just going to
attach the patch (with tests) below.

Since this is my first patch, please help guide me through the
process. Thank you.

-- 
Regards,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDK-8233680.patch
Type: text/x-patch
Size: 9220 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jdk-dev/attachments/20191219/a4a941f4/JDK-8233680-0001.patch>

From igor.veresov at oracle.com  Thu Dec 19 21:18:37 2019
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 19 Dec 2019 13:18:37 -0800
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <39112AAB-D412-49F0-A6D9-0D92CAB975AE@oracle.com>

Vote: yes

igor



> On Dec 10, 2019, at 12:40 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From david.holmes at oracle.com  Thu Dec 19 22:36:15 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Dec 2019 08:36:15 +1000
Subject: [PATCH] JDK-8233680: JavacFileManager.close() doesn't clear some
 cache instance variables
In-Reply-To: <CANtZXCq3Ly-nC7kcYm77Ys-4L0=-fPpZ9HgmXxd1TBqxJHGGfg@mail.gmail.com>
References: <CANtZXCq3Ly-nC7kcYm77Ys-4L0=-fPpZ9HgmXxd1TBqxJHGGfg@mail.gmail.com>
Message-ID: <94996861-4674-3949-d8b2-224c7c6f0335@oracle.com>

Hi Daniel,

Please post to compiler-dev at openjdk.java.net

Thanks,
David

On 19/12/2019 5:35 pm, Daniel Le Duc Khoi Nguyen wrote:
> Hi everyone,
> 
> I've already included all relevant information at
> https://bugs.openjdk.java.net/browse/JDK-8233680. I'm just going to
> attach the patch (with tests) below.
> 
> Since this is my first patch, please help guide me through the
> process. Thank you.
> 

From fujie at loongson.cn  Fri Dec 20 01:02:43 2019
From: fujie at loongson.cn (Jie Fu)
Date: Fri, 20 Dec 2019 09:02:43 +0800
Subject: CFV: New JDK Committer: Jatin Bhateja
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <fe91b0d2-eb08-007d-9c24-b47f52414754@loongson.cn>

Vote: yes

Best regards,
Jie

On 2019/12/19 ??2:28, Vladimir Ivanov wrote:
> I hereby nominate Jatin Bhateja (jbhateja) to Committer in JDK Project.
>
> Jatin Bhateja is a member of Java team at Intel. So far, he 
> contributed 12 significant changes [1] to the JDK project. Most 
> notably, one of the contributions is a major refactoring of AD files 
> in order to reduce the number of AD instructions needed for 
> auto-vectorization support in C2 on x86.
>
> Also, Jatin is a Committer in Project Panama and contributes to Vector 
> API there.
>
> Votes are due by January, 1, 2020.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
> Vladimir Ivanov
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=author%28jbhateja%29&revcount=20
> ??? http://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/projects/#reviewer-vote


From jonathan.gibbons at oracle.com  Thu Dec 19 22:51:32 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 19 Dec 2019 14:51:32 -0800
Subject: [PATCH] JDK-8233680: JavacFileManager.close() doesn't clear some
 cache instance variables
In-Reply-To: <CANtZXCq3Ly-nC7kcYm77Ys-4L0=-fPpZ9HgmXxd1TBqxJHGGfg@mail.gmail.com>
References: <CANtZXCq3Ly-nC7kcYm77Ys-4L0=-fPpZ9HgmXxd1TBqxJHGGfg@mail.gmail.com>
Message-ID: <af40a1e6-6592-3fd6-d4ae-3116f9204c34@oracle.com>

dropping: jdk-dev at openjdk.java.net,
follow-ups to: compiler-dev at openjdk.java.net

Daniel,

While I appreciate that you have written a test, these days our policy 
is to not use shell script for writing compiler tests, unless it is 
absolutely necessary, which it almost never is.

It is also curious that your test depends on the use of javadoc, which 
is unusual for a compiler test.

Is it possible to write the test in Java, and to not depend on javadoc?

-- Jon


On 12/18/2019 11:35 PM, Daniel Le Duc Khoi Nguyen wrote:
> Hi everyone,
>
> I've already included all relevant information at
> https://bugs.openjdk.java.net/browse/JDK-8233680. I'm just going to
> attach the patch (with tests) below.
>
> Since this is my first patch, please help guide me through the
> process. Thank you.
>


From vladimir.kozlov at oracle.com  Fri Dec 20 03:15:41 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Dec 2019 19:15:41 -0800
Subject: Result: New JDK Committer: Sandhya Viswanathan
Message-ID: <3f351a3c-86cc-fe9e-6498-2134a943133b@oracle.com>

Voting for Sandhya Viswanathan [1] is now closed.

Yes: 24
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Regards,
Vladimir Kozlov

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-December/003700.html

From goetz.lindenmaier at sap.com  Fri Dec 20 10:27:31 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 20 Dec 2019 10:27:31 +0000
Subject: closed bug: 8235961: SyncResolverImpl does not throw SQLException as
 expected
Message-ID: <AM6PR02MB53472AC8BC9C9360DA1B1890EC2D0@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi,

"8235961: SyncResolverImpl does not throw SQLException as expected"
was pushed with a closed bug. Is it possible to open this up?

https://hg.openjdk.java.net/jdk/jdk/rev/ce6662089667
https://bugs.openjdk.java.net/browse/JDK-8235961

Best regards,
  Goetz.




From patric.hedlin at oracle.com  Fri Dec 20 13:56:24 2019
From: patric.hedlin at oracle.com (Patric Hedlin)
Date: Fri, 20 Dec 2019 14:56:24 +0100
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <21ffc309-4c9f-791a-f7ce-bbf97cbdad19@oracle.com>

Vote: yes

/Patric

On 10/12/2019 09:40, Tobias Hartmann wrote:
> Hi,
>
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
>
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
>
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
>
> Votes are due by 08:30 UTC, December 24th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
> Tobias
>
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From dean.long at oracle.com  Sat Dec 21 02:18:12 2019
From: dean.long at oracle.com (Dean Long)
Date: Fri, 20 Dec 2019 18:18:12 -0800
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <80e68145-94fb-a90d-a576-cf38dd3ea980@oracle.com>

Vote: yes

dl

On 12/10/19 12:40 AM, Tobias Hartmann wrote:
> Hi,
>
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
>
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
>
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
>
> Votes are due by 08:30 UTC, December 24th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
> Tobias
>
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From volker.simonis at gmail.com  Sat Dec 21 14:02:37 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Sat, 21 Dec 2019 15:02:37 +0100
Subject: CFV: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <CA+3eh12jEsrPvPB4sie8RBsLMRN+1p52r0OEahLKnEER_2h-mg@mail.gmail.com>

Vote: yes


Tobias Hartmann <tobias.hartmann at oracle.com> schrieb am Di., 10. Dez. 2019,
09:43:

> Hi,
>
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
>
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he
> only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project
> [1], from which 11 are
> significant and affect complex code in the JIT compilers.
>
> Back in 2017, Christian already worked on the JDK as part of his masters
> thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent
> progress including
> developing aggressive optimizations to avoid heap buffering. His work
> served as a guidance for
> today's C1 implementation in project Valhalla.
>
> Votes are due by 08:30 UTC, December 24th, 2019.
>
> Only current JDK Committers [2] 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 [3].
>
> Best regards,
> Tobias
>
> [1]
>
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
>

From sandhya.viswanathan at intel.com  Sun Dec 22 20:12:41 2019
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Sun, 22 Dec 2019 20:12:41 +0000
Subject: CFV: New JDK Committer: Jatin Bhateja
In-Reply-To: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
References: <a215201d-0032-a618-f273-372cc54b5643@oracle.com>
Message-ID: <BYAPR11MB29837BC1F4608FFC5CCABCBEEF2F0@BYAPR11MB2983.namprd11.prod.outlook.com>

Vote: yes

Best Regards,
Sandhya

-----Original Message-----
From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Vladimir Ivanov
Sent: Wednesday, December 18, 2019 10:29 AM
To: jdk-dev at openjdk.java.net
Subject: CFV: New JDK Committer: Jatin Bhateja

I hereby nominate Jatin Bhateja (jbhateja) to Committer in JDK Project.

Jatin Bhateja is a member of Java team at Intel. So far, he contributed
12 significant changes [1] to the JDK project. Most notably, one of the contributions is a major refactoring of AD files in order to reduce the number of AD instructions needed for auto-vectorization support in C2 on x86.

Also, Jatin is a Committer in Project Panama and contributes to Vector API there.

Votes are due by January, 1, 2020.

Only current JDK Committers [2] 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 [3].

Best regards,
Vladimir Ivanov

[1]
http://hg.openjdk.java.net/jdk/jdk/search/?rev=author%28jbhateja%29&revcount=20
     http://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a
[2] http://openjdk.java.net/census
[3] http://openjdk.java.net/projects/#reviewer-vote

From tobias.hartmann at oracle.com  Tue Dec 24 10:40:41 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 24 Dec 2019 11:40:41 +0100
Subject: Result: New JDK Committer: Christian Hagedorn
In-Reply-To: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
References: <afe470e8-6084-7517-82b5-02861438d520@oracle.com>
Message-ID: <2f4e521e-33bb-404f-fb8e-e2b6290ed8b6@oracle.com>

Voting for Christian Hagedorn [1] is now closed.

Yes: 29
Veto: 0
Abstain: 0

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

Thanks,
Tobias

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-December/003733.html

On 10.12.19 09:40, Tobias Hartmann wrote:
> Hi,
> 
> I hereby nominate Christian Hagedorn (chagedorn) to JDK Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle. Although he only joined in mid July
> this year, Christian already contributed 19 changes to the JDK project [1], from which 11 are
> significant and affect complex code in the JIT compilers.
> 
> Back in 2017, Christian already worked on the JDK as part of his masters thesis project on
> implementing C1 JIT compiler support for Inline Types. He made excellent progress including
> developing aggressive optimizations to avoid heap buffering. His work served as a guidance for
> today's C1 implementation in project Valhalla.
> 
> Votes are due by 08:30 UTC, December 24th, 2019.
> 
> Only current JDK Committers [2] 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 [3].
> 
> Best regards,
> Tobias
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 

From andrew_m_leonard at uk.ibm.com  Mon Dec 30 14:28:24 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Mon, 30 Dec 2019 14:28:24 +0000
Subject: TimeZone Updater Tool/Project, where would we put it?
Message-ID: <OF153697AA.C23E881D-ON002584E0.004EABAC-802584E0.004F811A@notes.na.collabserv.com>

Thanks for your input Ben,
I share your concern about the timescale of IANA updates being published 
and them getting into JDK updates, your point in the example of Brazil, I 
didn't realize it took a year to get the update into the JDK.

Does someone from Oracle/RedHat know what the "policy" is for when an 
OpenJDK IANA tzdata update is done? Once IANA publish a new level, how 
long until it gets into the JDK? I would like to think it is the next 
available quarterly update..., I realize there's rampdown etc, but which 
quarterly "checkpoint" date could the latest IANA tzdata be integrated 
safely by? and do we, or should we ensure this happens?

Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 

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


From andrew_m_leonard at uk.ibm.com  Mon Dec 30 14:51:12 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Mon, 30 Dec 2019 14:51:12 +0000
Subject: TimeZone Updater Tool/Project, where would we put it?
Message-ID: <OF1F01342F.E833FE36-ON002584E0.004FB2F7-802584E0.00519779@notes.na.collabserv.com>

I also share the concern expressed by Alan, Sean,.. about the practice of 
"patching" tzdb.dat directly, rather than through a supported JDK update 
process. The issue of if something goes wrong, and also if the JDK/JRE is 
already managed by an installer will it interfere with that process.. All 
the IBM tool does is essentially find and update the tzdb.dat file. I'd 
like to first explore the policy for integrating the latest IANA tzdata, 
and then maybe depending on that discussion explore ways in which vendors 
like AdoptOpenJDK can provide in a minimal risk way an interim tzdb.dat, 
which 3rd parties like NewRelic for example can build into their 
images...which is one of the most popular use cases nowadays. 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 

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


From Sagar.Ghagare at mastek.com  Mon Dec 30 16:57:01 2019
From: Sagar.Ghagare at mastek.com (Sagar P Ghagare)
Date: Mon, 30 Dec 2019 16:57:01 +0000
Subject: Underlying exception : java.lang.UnsupportedOperationException:
 Cannot define class using reflection
Message-ID: <TY2PR06MB300888C1EED8681B3567877487270@TY2PR06MB3008.apcprd06.prod.outlook.com>

Hi,

Facing issues while moving java aws lambda handler from java 8 to 11.

Getting below error:

Works fine with Java8
Mockito 2.13.0
PowerMockito 1.7.4

[cid:d205b491-92df-473c-8685-044149f5192e]

Thanks & Regards,
Sagar Ghagare
Senior Software Engineer
NHS Digital(NHS Login) At Mastek UK Ltd