Re: jdk11u build failure on Windows

[Hohensee, Paul]

Directing to jdk-updates-dev...

Paul

-Original Message-
From: core-libs-dev  on behalf of Vyom 
Tiwari 
Date: Monday, January 10, 2022 at 10:51 PM
To: net-dev , core-libs-dev 

Cc: "kusriniva...@vmware.com" 
Subject: jdk11u build failure on Windows

Hi,
I am facing the build issue with  OpenJDK11(jdk11u). I am trying to build
jdk11u on Windows and I am  getting the below error.


./src/java.base/windows/native/libnet/net_util_md.c(792): error C2065:
'TCP_INITIAL_RTO_NO_SYN_RETRANSMISSIONS': undeclared identifier
make[3]: *** [Lib-java.base.gmk:44:
/cygdrive/d/source/mirrors_github_jdk11u/build/windows-x86_64-normal-server-release/support/native/java.base/libnet/net_util_md.obj]
Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [make/Main.gmk:215: java.base-libs] Error 2

ERROR: Build failed for target 'images' in configuration
'windows-x86_64-normal-server-release' (exit code 2)
Stopping sjavac server
###

I found that the back-port of  JDK-8250521
  is causing this failure.

My  environment details are as follows.
OS: Windows Server 2016 Standard, Visual Studio professional 2017 version
15.2(26430.14)

When I updated my Visual Studio to 15.9.42(which contains Windows 10
SDK(10.0.17134.0)) the problem went away.

My question is do we have a minimum supported Visual Studio(15.9.42) to
build jdk11u(11.0.14) ?. If this is not the case then I would like to fix
this build failure.

Thanks,
Vyom

Re: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]

[Hohensee, Paul]

My apologies. I relied on the other reviewers. I'll do an independent review in 
the future.

Thanks,
Paul

On 10/14/20, 11:02 AM, "core-libs-dev on behalf of Roger Riggs" 
 
wrote:

On Wed, 14 Oct 2020 15:01:42 GMT, Roger Riggs  wrote:

>> Due to the requirement for multiple reviewers, I had been waiting to add 
my review of the Core-Libs files until the
>> HotSpot reviewers had approved!  I see only one reviewer credited in the 
commit.
>
> This integration without testing with a current merge from the master and 
has caused two build failures.
>
> JDK-8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar
>
> JDK-8254775: Microbenchmark StringIndexOfChar doesn't compile
>
> There is a raw unicode character in the JMH test that causes a 
compilation error.
> == Output from failing command(s) repeated here ===
> [2020-10-14T14:39:09,608Z] * For target 
support_test_micro_classes__the.BUILD_JDK_MICROBENCHMARK_batch:
> [2020-10-14T14:39:09,611Z]
> 
/opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
> error: unmappable character (0xE2) for encoding ascii 
[2020-10-14T14:39:09,611Z]
> sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]  
  ^ [2020-10-14T14:39:09,611Z]
> 
/opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
> error: unmappable character (0x98) for encoding ascii 
[2020-10-14T14:39:09,611Z]
> sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]  
   ^ [2020-10-14T14:39:09,611Z]
> 
/opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
> error: unmappable character (0xBA) for encoding ascii 
[2020-10-14T14:39:09,611Z]
> sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]  
^ [2020-10-14T14:39:09,611Z]
> 
/opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
> error: unclosed character literal [2020-10-14T14:39:09,611Z] 
sb.append(isUtf16?'???':'b');
> [2020-10-14T14:39:09,611Z]   ^ 
[2020-10-14T14:39:09,611Z]
> 
/opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
> error: unclosed character literal [2020-10-14T14:39:09,611Z] 
sb.append(isUtf16?'???':'b');```

And also a failed Graal test because of the new intrinsic.

And JDK-8254785: compiler/graalunit/HotspotTest.java failed with "missing 
Graal intrinsics for:
java/lang/StringLatin1.indexOfChar([BIII)I"

@phohensee don't be so quick to type `/sponsor`; there are three separate 
build and test failures.

-

PR: https://git.openjdk.java.net/jdk/pull/71

Re: RFR(XS): 8244094: Fix Amazon copyright in various test files

[Hohensee, Paul]

Looks good, and trivial.

Thanks,
Paul

On 4/30/20, 8:23 AM, "core-libs-dev on behalf of Volker Simonis" 
 wrote:

Hi,

can I please get a review for the following trivial change which fixes
the Amazon copyright in several test files:

http://cr.openjdk.java.net/~simonis/webrevs/2020/8244094/
https://bugs.openjdk.java.net/browse/JDK-8244094

Notice that the new version intentionally contains no copyright year any
more.

Thank you and best regards,
Volker





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Re: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")

[Hohensee, Paul]

Thanks for the explanation of the process.

Paul

On 3/23/20, 11:28 PM, "Langer, Christoph"  wrote:

Hi Paul,

as Martin said, the original bug could not be opened by Oracle. I, however 
changed the bug created by Martin to a Backport item. Doing it that way would 
allow a "standard" backport of such type of issues while the original item that 
was pushed to head can remain invisible. We proceeded like that with other bugs 
already and it proved to work nicely.

Best regards
Christoph

> -Original Message-
> From: core-libs-dev  On Behalf
> Of Hohensee, Paul
> Sent: Montag, 23. März 2020 19:29
> To: Doerr, Martin ; core-libs-
> d...@openjdk.java.net; jdk-updates-...@openjdk.java.net
> Subject: RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
> java.security.AccessControlException: access denied
> ("java.net.NetPermission" "setSocketImpl")
>
> The changeset references JDK-8223326, which is private. If possible, ask
> Oracle to make it public so we can do a normal backport rather than file 
an
> 11u-specific issue. The backport itself looks fine.
>
> Thanks,
> Paul
>
> On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin"  updates-dev-boun...@openjdk.java.net on behalf of
> martin.do...@sap.com> wrote:
>
>
> Hi,
>
> I'd like to backport JDK-8223326 from jdk/jdk.
>
> 11u backport issue:
> https://bugs.openjdk.java.net/browse/JDK-8241460
>
> Original change:
> https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc
>
> 11u backport webrev:
>
> http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/
>
> I had to integrate the change manually due to context changes. 
However,
> the new code fits to the 11u versions.
>
> Please review.
>
> Best regards,
> Martin
>
>

RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")

[Hohensee, Paul]

The changeset references JDK-8223326, which is private. If possible, ask Oracle 
to make it public so we can do a normal backport rather than file an 
11u-specific issue. The backport itself looks fine.

Thanks,
Paul

On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin" 
 
wrote:


Hi,

I'd like to backport JDK-8223326 from jdk/jdk.

11u backport issue:
https://bugs.openjdk.java.net/browse/JDK-8241460

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc

11u backport webrev:
http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/

I had to integrate the change manually due to context changes. However, the 
new code fits to the 11u versions.

Please review.

Best regards,
Martin

Re: RFR (backport CSR): 8239395: Accounting currency format support

[Hohensee, Paul]

In that case, I'll withdraw it, unless a maintenance review comes along.

Thanks,
Paul

On 2/19/20, 9:01 AM, "Joe Darcy"  wrote:

As a practical matter, no. Since a Java SE specification is modified by 
this changeset, a maintenance review (MR) would be needed for Java SE 11 
for this change to go into 11u.

HTH,

-Joe

On 2/19/2020 8:09 AM, Hohensee, Paul wrote:
> So, not backportable?
>
> Paul
>
> On 2/19/20, 5:23 AM, "naoto.s...@oracle.com"  
wrote:
>
>  Hi Joe, Paul,
>  
>  Yes, I was thinking the same. It is a spec change in 14.
>  
>  Naoto
>  
>  On 2/18/20 9:45 PM, Joe Darcy wrote:
>  > Hi Paul,
>  >
>  > This looks like a spec change to a Java SE API so would be out of 
bounds
>  > for 11u without a maintenance update of Java SE 11.
>  >
>  > Naoto, do you agree with that analysis?
>  >
>  > Thanks,
>  >
>  > -Joe
>  >
>  > On 2/18/2020 5:44 PM, Hohensee, Paul wrote:
>  >> Please review the CSR 
https://bugs.openjdk.java.net/browse/JDK-8239395
>  >> for a backport of JDK-8215181 to jdk11u. It’s identical to the
>  >> original CSR.
>  >>
>  >> Original JBS issue: 
https://bugs.openjdk.java.net/browse/JDK-8215181
>  >> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770
>  >> Backport JBS issue: 
https://bugs.openjdk.java.net/browse/JDK-8239394
>  >> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395
>  >>
>  >> Thanks,
>  >> Paul
>  >>
>  
>

Re: RFR (backport CSR): 8239395: Accounting currency format support

[Hohensee, Paul]

So, not backportable?

Paul

On 2/19/20, 5:23 AM, "naoto.s...@oracle.com"  wrote:

Hi Joe, Paul,

Yes, I was thinking the same. It is a spec change in 14.

Naoto

On 2/18/20 9:45 PM, Joe Darcy wrote:
> Hi Paul,
> 
> This looks like a spec change to a Java SE API so would be out of bounds 
> for 11u without a maintenance update of Java SE 11.
> 
> Naoto, do you agree with that analysis?
> 
> Thanks,
> 
> -Joe
    > 
> On 2/18/2020 5:44 PM, Hohensee, Paul wrote:
>> Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 
>> for a backport of JDK-8215181 to jdk11u. It’s identical to the 
>> original CSR.
>>
>> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181
>> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770
>> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394
>> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395
>>
>> Thanks,
>> Paul
>>

RFR (backport CSR): 8239395: Accounting currency format support

[Hohensee, Paul]

Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 for a 
backport of JDK-8215181 to jdk11u. It’s identical to the original CSR.

Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181
Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770
Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394
Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395

Thanks,
Paul

Re: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString

[Hohensee, Paul]

This revision looks fine to me.

Thanks,
Paul

On 12/16/19, 7:52 PM, "core-libs-dev on behalf of Verghese, Clive" 
 wrote:

Hi Volker,

Thank you for the feedback. 

I have update the revision to reflect your comments. 
http://cr.openjdk.java.net/~phh/8235699/webrev.01/

Regards,
Clive Verghese

On 12/13/19, 8:09 AM, "Volker Simonis"  wrote:

Hi Clive,

nice catch :)

I think it would be better though to only iterate up to MAX_FIELD and
print "field[MAX_FIELD + i]", otherwise you may miss to print valid
fields. The reason is that with your current solution "isSet()" will
now be called not only for "stamp" fields, but also for "real" fields.
But for "real" fields, zero is a valid value which you might want to
print. You might however still consider printing the "stamps" (i.e.
the lower half) as well, e.g.:

sj.add(i + "=" + field[i] + ":" + field[MAX_FIELD + i]);

Thank you and best regards,
Volker

On Fri, Dec 13, 2019 at 1:05 AM Verghese, Clive  
wrote:
>
> Additional information regarding the field array.
>
> It is meant to hold two arrays, the lower half holds the stamp. And 
the upper half holds the fields.
> The original implementation was intending to display the second half 
of the array. Though the outer loop
> iterated through the whole array. Therefore causing an 
ArrayIndexOutOfBoundsException. I have updated
> this to display the whole array.
>
> Regards,
> Clive Verghese
>
> From: "Verghese, Clive" 
> Date: Thursday, December 12, 2019 at 2:07 PM
> To: "core-libs-dev@openjdk.java.net" 
> Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in 
CalendarBuilder.toString
>
> Hi,
>
> Requesting review for
> JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699
> Webrev :  https://cr.openjdk.java.net/~phh/8235699/webrev.00/
>
> CalendarBuilder.toString method has a bug which causes an 
ArrayIndexOutOfBoundsException exception.
> The class is an internal jdk class that is restricted to java.text 
package. The bug is observed when the debugger
> reaches this class and uses the toString function to print the class.
>
> Steps to reproduce this is attached in the JBS issue.
>
> Regards,
> Clive Verghese
>
>

Re: [8u] RFR: JDK-8227715: GPLv2 files missing Classpath Exception

[Hohensee, Paul]

Lgtm. I'll sponsor it and tag the JBS issue with jdk8u-fix-request.

Thanks,
Paul

On 12/9/19, 4:55 AM, "jdk-updates-dev on behalf of Severin Gehwolf" 
 
wrote:

Hi Adam,

This looks like an RFR for OpenJDK 8u. Adding the appropriate mailing
list (jdk8u-dev not jdk-updates-dev; bcc'ed the latter) and fixing the
subject line.

Thanks,
Severin

On Thu, 2019-10-03 at 15:53 +0100, Adam Farley8 wrote:
> Hey all,
> 
> Four GPLv2 files in 8u seem to be missing the classpath exception from 
the 
> copyright section.
> 
> Requesting reviews and a sponsor.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227715
> 
> Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/
> 
> Best Regards
> 
> Adam Farley 
> IBM Runtimes
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 

Re: Turkish Time Zone name string and translation

[Hohensee, Paul]

This looks good to me, assuming the i18n people are ok with using "Turkey Time" 
instead of some other designation.

Thanks,
Paul

On 11/25/19, 10:44 AM, "core-libs-dev on behalf of Yang, Letu" 
 wrote:

Fixed in https://cr.openjdk.java.net/~xliu/8234288/webrev.04/ Thanks!

From: Martin Buchholz 
Date: Monday, November 25, 2019 at 10:27 AM
To: "Yang, Letu" 
Cc: "core-libs-dev@openjdk.java.net" , 
"i18n-...@openjdk.java.net" , 
"naoto.s...@oracle.com" , Leo Jiang 
, "Liu, Xin" 
Subject: Re:  Turkish Time Zone name string and translation


\ No newline at end of file
Please fix.

Re: [11u] RFR (S): 8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

[Hohensee, Paul]

I agree, looks fine.

Paul

On 6/2/19, 11:46 PM, "jdk-updates-dev on behalf of Langer, Christoph" 
 wrote:

Hi,

please help reviewing a backport to OpenJDK 11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8139965
11u-webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139965.11u/

The patch did apply, however, it contained changes to testcase 
test/jdk/com/sun/jndi/ldap/LdapDnsProviderTest.java. The testcase is not part 
of JDK11u and its backport is also impossible as it belongs to an enhancement 
with associated CSR for JDK12 (JDK-8160768 [0]). The test update hasn't been 
part of the original review thread [1], so I think it is ok to go with the 
change as suggested in the webrev.

Thanks
Christoph

[0] https://bugs.openjdk.java.net/browse/JDK-8160768
[1] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055115.html

Re: [8u] 8205432: Replace the placeholder Japanese era name

[Hohensee, Paul]

Thanks, Andrew. :)

On 4/9/19, 10:27 AM, "Andrew John Hughes"  wrote:

On 09/04/2019 18:18, Hohensee, Paul wrote:
> I meant the current webrev
> 
> https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/
> 
> is fine. Just backport what's in tip and fix whatever's wrong later as 
another backport or backports.
> 
> Paul

Thanks. I've pushed based on the review of yourself & aph:

https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/ee55428fe158

I can't credit Deepak anyway, as he's not a reviewer, but his
suggestions have been incorporated in this latest webrev.
-- 
Andrew :)

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

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

Re: [8u] 8205432: Replace the placeholder Japanese era name

[Hohensee, Paul]

I meant the current webrev

https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/

is fine. Just backport what's in tip and fix whatever's wrong later as another 
backport or backports.

Paul

On 4/9/19, 8:56 AM, "core-libs-dev on behalf of Hohensee, Paul" 
 wrote:

+1.

Paul

On 4/8/19, 8:28 PM, "core-libs-dev on behalf of Andrew John Hughes" 
 
wrote:

On 08/04/2019 09:25, Deepak Kejriwal wrote:
> Hi Andrew,
> 
> Thanks for working on this. Please find below few minor comments:-
> 
> 1>. For "src/share/classes/java/util/JapaneseImperialCalendar.java" 
and "src/share/classes/sun/util/calendar/Era.java" please changes the date time 
format to be consistent with existing defined eras:-
>   * 4   Heisei  1989-01-08 midnight local time
> - * 5   NewEra  2019-05-01 midnight local time
> + * 5   Reiwa   2019-05-01T00:00:00 local time
> 
> Please change "2019-05-01T00:00:00 local time" to "2019-05-01 
midnight local time"
> 

The change in style is a cleanup that is part of JDK-8048123 [0]. I
think we're better bringing over those cleanups than making Reiwa use
the bad format, so I've incorporated those parts of [1] into the revised
webrev.

> 2>.  For 
"test/java/time/test/java/time/chrono/TestJapaneseChronology.java" please align 
"JapaneseEra.of(3)" with existing defined eras in "Object[][] eraNameData()".
> 

I've fixed this too, but note that this comes from the original patch in
11 and up. So it actually needs fixing there too.

Revised webrev:
https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/

> 
> Regards,
> Deepak
> 

[0] 
https://mail.openjdk.java.net/pipermail/i18n-dev/2014-July/001438.html
[1] https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/91ea77c474b9
-- 
Andrew :)

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

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

Re: [8u] 8205432: Replace the placeholder Japanese era name

[Hohensee, Paul]

+1.

Paul

On 4/8/19, 8:28 PM, "core-libs-dev on behalf of Andrew John Hughes" 
 
wrote:

On 08/04/2019 09:25, Deepak Kejriwal wrote:
> Hi Andrew,
> 
> Thanks for working on this. Please find below few minor comments:-
> 
> 1>. For "src/share/classes/java/util/JapaneseImperialCalendar.java" and 
"src/share/classes/sun/util/calendar/Era.java" please changes the date time 
format to be consistent with existing defined eras:-
>   * 4   Heisei  1989-01-08 midnight local time
> - * 5   NewEra  2019-05-01 midnight local time
> + * 5   Reiwa   2019-05-01T00:00:00 local time
> 
> Please change "2019-05-01T00:00:00 local time" to "2019-05-01 midnight 
local time"
> 

The change in style is a cleanup that is part of JDK-8048123 [0]. I
think we're better bringing over those cleanups than making Reiwa use
the bad format, so I've incorporated those parts of [1] into the revised
webrev.

> 2>.  For 
"test/java/time/test/java/time/chrono/TestJapaneseChronology.java" please align 
"JapaneseEra.of(3)" with existing defined eras in "Object[][] eraNameData()".
> 

I've fixed this too, but note that this comes from the original patch in
11 and up. So it actually needs fixing there too.

Revised webrev:
https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/

> 
> Regards,
> Deepak
> 

[0] https://mail.openjdk.java.net/pipermail/i18n-dev/2014-July/001438.html
[1] https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/91ea77c474b9
-- 
Andrew :)

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

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

Re: [8u-dev] Request for Approval: Backport of JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710

[Hohensee, Paul]

I added the 'jdk8u-fix-request' tag to these issues.

Paul

On 2/28/19, 3:13 AM, "core-libs-dev on behalf of Deepak Kejriwal" 
 wrote:

Hi All,

 

Please approve the backport of following bugs to 8u-dev.

 

JDK-8202088 : Japanese new era implementation

JDK-8207152 : Placeholder for Japanese new era should be two characters

JDK-8211398 : Square character support for the Japanese new era

JDK-8180469 : Wrong short form text for supplemental Japanese era

JDK-8206120 : Add test cases for lenient Japanese era parsing

JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to 
handle new code points

JDK-8217710 : Add 5 currency code points to Java SE 8uX

 

JDK Review Thread: 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058595.html

 

All the related testing is done and is a pass.

 

Regards,

Deepak

 

Re: JMathConstant submission for upcoming JDK

[Hohensee, Paul]

Redirecting to core-libs-dev. I filed 
https://bugs.openjdk.java.net/browse/JDK-8213045.

Paul

On 10/26/18, 10:50 AM, "jdk-dev on behalf of Hohensee, Paul" 
 wrote:

This would go to core-libs-dev, and would be a spec change since it adds a 
class. The concept could be expanded to BigInteger, Long, Integer, etc. Instead 
of adding a class, one could add these constants directly to BigDecimal (and 
the others), but that would also be a spec change since it adds public members.

You should file a JBS bug. If you don't have access to JBS, I'd be happy to 
file it for you.

Thanks,

Paul

On 10/26/18, 9:41 AM, "jdk-dev on behalf of rob...@liguorisoftware.com" 
 
wrote:

Hi Chris,

I wrote this simple utility class you may want to use in an upcoming 
version of the JDK.  Btw, I'm the author of the Java Pocket Guide. :)

Or is there a better place I can submit simple code like this for the 
JDK?

Thanks, Robert

import java.math.BigDecimal;

public class JMathConstant {

 private JMathConstant() {
 }

 // ZERO, 1/2 AND ONE
 public static final BigDecimal ZERO   = new 
BigDecimal("0.0");
 public static final BigDecimal LANDAUS= new 
BigDecimal("0.5");
 public static final BigDecimal ONE= new 
BigDecimal("1.0");
 public static final BigDecimal LEGENDRE   = new 
BigDecimal("1.0");

 // SILVER AND GOLD
 public static final BigDecimal ARCHIMEDES_RATIO   = new 

BigDecimal("3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019
 27876611
1959092164201989");
 public static final BigDecimal UNKNOWN_NAME   = new 

BigDecimal("2.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019
 27876611
1959092164201989");
 public static final BigDecimal SILVER_RATIO   = new 
BigDecimal("2.4142135623730950488");
 public static final BigDecimal PYTHAGORAS = new 
BigDecimal("1.4142135623730950488");
 public static final BigDecimal GOLDEN_RATIO   = new 

BigDecimal("1.61803398874989484820458683436563811772030917980576286213544862270526046281890");
 public static final BigDecimal INVERSE_GOLDEN_RATIO   = new 

BigDecimal("0.61803398874989484820458683436563811772030917980576286213544862270526046281890");

 // ADDITIONAL RATIO CONSTANTS
 public static final BigDecimal FEIGENBAUMS_RATIO_1 = new 
BigDecimal("4.66920160910299067185320382046620161");
 public static final BigDecimal FEIGENBAUMS_RATIO_2 = new 
BigDecimal("2.50290787509589282228390287321821578");

 /

Re: SSL session cache default maximum number of entries

[Hohensee, Paul]

I've filed https://bugs.openjdk.java.net/browse/JDK-8210985.

Thanks for looking into this.

Paul

On 9/17/18, 8:37 AM, "Sean Mullan"  wrote:

On 9/12/18 2:25 PM, Hohensee, Paul wrote:
> Thanks very much for investigating. We're aware that the cache size can 
be set by the user, but many of our users haven't done so because it hasn't 
been necessary, and boom.

Would you mind filing a bug and we will look into it?

Thanks,
Sean

> 
> Paul
> 
> On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" 
 
wrote:
> 
>  Hi Paul,
>  
>  Thank you for bringing this issue to our attention. While we agree 
that
>  this does indeed seem like an issue that should be addressed, it is
>  quite late in the JDK 11 schedule, and it does not appear to be a new
>  issue introduced in JDK 11. We will be investigating this offline and
>  will get back to you as soon as we can with more details. Offhand, I
>  think that we would be able to change the default in an update 
release.
>  
>  Also, you are probably already be aware of this, but you can use the
>  SSLSessionContext.setSessionCacheSize() API as well as the
>  "javax.net.ssl.sessionCacheSize" system property to customize the 
cache
>  size.
>  
>  --Sean
>  
>  On 9/11/18 12:02 PM, Sean Mullan wrote:
>  > cross-posting to security-dev since this is related to SSL/TLS.
>  >
>  > On 9/11/18 11:41 AM, Hohensee, Paul wrote:
>  >> The default value for the maximum number of entries in the SSL 
session
>  >> cache (which is a SoftReference cache) is infinite, and the entry
>  >> timeout is 24 hours. With larger heaps, we’re running into 
situations
>  >> where the cache ends up with several million entries when the 24 
hours
>  >> are up. They’re then all invalidated at the same time, resulting 
in
>  >> multi-minute pauses (effectively service failures). We’ve 
experimented
>  >> with using 10k as the default maximum number of entries with good
>  >> results (i.e., no latency increases due to sessions falling out 
of the
>  >> cache). It’s late and a long shot for JDK11: we’d love to see it
>  >> changed there because 11 is an LTS release and this is, at least
>  >> nominally, a behavior change which might not be acceptable in 11u.
>  >> What do people think?
>  >>
>  >> Thanks,
>  >>
>  >> Paul
>  >>
>  
> 

Re: SSL session cache default maximum number of entries

[Hohensee, Paul]

Thanks very much for investigating. We're aware that the cache size can be set 
by the user, but many of our users haven't done so because it hasn't been 
necessary, and boom.

Paul

On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" 
 
wrote:

Hi Paul,

Thank you for bringing this issue to our attention. While we agree that 
this does indeed seem like an issue that should be addressed, it is 
quite late in the JDK 11 schedule, and it does not appear to be a new 
issue introduced in JDK 11. We will be investigating this offline and 
will get back to you as soon as we can with more details. Offhand, I 
think that we would be able to change the default in an update release.

Also, you are probably already be aware of this, but you can use the 
SSLSessionContext.setSessionCacheSize() API as well as the 
"javax.net.ssl.sessionCacheSize" system property to customize the cache 
size.

--Sean

On 9/11/18 12:02 PM, Sean Mullan wrote:
> cross-posting to security-dev since this is related to SSL/TLS.
> 
    > On 9/11/18 11:41 AM, Hohensee, Paul wrote:
>> The default value for the maximum number of entries in the SSL session 
>> cache (which is a SoftReference cache) is infinite, and the entry 
>> timeout is 24 hours. With larger heaps, we’re running into situations 
>> where the cache ends up with several million entries when the 24 hours 
>> are up. They’re then all invalidated at the same time, resulting in 
>> multi-minute pauses (effectively service failures). We’ve experimented 
>> with using 10k as the default maximum number of entries with good 
>> results (i.e., no latency increases due to sessions falling out of the 
>> cache). It’s late and a long shot for JDK11: we’d love to see it 
>> changed there because 11 is an LTS release and this is, at least 
>> nominally, a behavior change which might not be acceptable in 11u. 
>> What do people think?
>>
>> Thanks,
>>
>> Paul
>>

SSL session cache default maximum number of entries

[Hohensee, Paul]

The default value for the maximum number of entries in the SSL session cache 
(which is a SoftReference cache) is infinite, and the entry timeout is 24 
hours. With larger heaps, we’re running into situations where the cache ends up 
with several million entries when the 24 hours are up. They’re then all 
invalidated at the same time, resulting in multi-minute pauses (effectively 
service failures). We’ve experimented with using 10k as the default maximum 
number of entries with good results (i.e., no latency increases due to sessions 
falling out of the cache). It’s late and a long shot for JDK11: we’d love to 
see it changed there because 11 is an LTS release and this is, at least 
nominally, a behavior change which might not be acceptable in 11u. What do 
people think?

Thanks,

Paul

Re: 8189789: tomcat gzip-compressed response bodies appear to be broken in update 151

[Hohensee, Paul]

I’d file an RFE to refactor the Deflater.c code.

Following the zlib code is the right thing to do in order to stay consistent, 
even if it’s a bit rough.

So, ship it.

On 11/22/17, 9:43 AM, "Seán Coffey" <sean.cof...@oracle.com> wrote:


On 22/11/2017 15:46, Hohensee, Paul wrote:
> If the fix is from the zlib project, then ignore the following, since 
it’s their code.
>
> In Deflater.c: the existing significant code duplication between the arms 
of the if-else gives one pause. E.g., in the new file, compare lines 148/183 
and 155/190. Might be bugs lurking at 183 and 190.
There might be some room for optimizing alright. The different length 
variables are measuring the available input and output length values. 
Different action is taken if we encounter exceptions when setting up 
memory for related operations. Maybe we can bring more consistent length 
checks to both blocks. I'd have to check why we check for native 
exception handling in one block and not the other.
>
> In deflate.c: the old code had “s->last_flush = Z_NO_FLUSH”, the new has 
“-2”. Should “-2” be symbolic instead?
Sherman is following the code from the main zlib repo for that change [1]

regards,
Sean.

[1] https://github.com/madler/zlib/issues/275
>
> Thanks,
>
> Paul
>
> On 11/22/17, 2:00 AM, "core-libs-dev on behalf of Seán Coffey" 
<core-libs-dev-boun...@openjdk.java.net on behalf of sean.cof...@oracle.com> 
wrote:
>
>  Looking to fix a recent regression that appeared in 8u151. Thanks 
goes
>  to Sherman for the src patch. Paul Hohensee has also helped by 
provided
>  some test code. I've been able to modify an existing test to mimic 
the
>  behaviour seen with FlushableGZIPOutputStream which is found in 
Tomcat 7.x.
>  
>  Sherman is working on a patch for JDK 10. For unix OSes, JDK 10 
operates
>  with the zlib version found on the OS.
>  
>  bug : https://bugs.openjdk.java.net/browse/JDK-8189789
>  webrev : 
http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/
>  
>  regards,
>  Sean.
>  
>  
>

Re: 8189789: tomcat gzip-compressed response bodies appear to be broken in update 151

[Hohensee, Paul]

If the fix is from the zlib project, then ignore the following, since it’s 
their code.

In Deflater.c: the existing significant code duplication between the arms of 
the if-else gives one pause. E.g., in the new file, compare lines 148/183 and 
155/190. Might be bugs lurking at 183 and 190.

In deflate.c: the old code had “s->last_flush = Z_NO_FLUSH”, the new has “-2”. 
Should “-2” be symbolic instead?

Thanks,

Paul

On 11/22/17, 2:00 AM, "core-libs-dev on behalf of Seán Coffey" 
 
wrote:

Looking to fix a recent regression that appeared in 8u151. Thanks goes 
to Sherman for the src patch. Paul Hohensee has also helped by provided 
some test code. I've been able to modify an existing test to mimic the 
behaviour seen with FlushableGZIPOutputStream which is found in Tomcat 7.x.

Sherman is working on a patch for JDK 10. For unix OSes, JDK 10 operates 
with the zlib version found on the OS.

bug : https://bugs.openjdk.java.net/browse/JDK-8189789
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/

regards,
Sean.

Re: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file

[Hohensee, Paul]

A double negative (!Files.notExists) somewhat unusual coding and will perplex 
people reading it. They might even switch it back to Files.exists as a style 
cleanup, so I recommend adding a comment explaining why you’re using it.

Thanks,

Paul

On 7/25/17, 5:08 PM, "core-libs-dev on behalf of Andrey Nazarov" 
 wrote:

Thanks, Brian

—Andrei
> On 25 Jul 2017, at 16:41, Brian Burkhalter  
wrote:
> 
> Hi Andrei,
> 
> I think this looks good.
> 
> Thanks,
> 
> Brian
> 
> On Jul 25, 2017, at 3:59 PM, Andrey Nazarov  
wrote:
> 
>> Can anyone look?
>> 
>> —Thanks,
>> Andrei
>>> On 19 Jul 2017, at 18:21, Andrey Nazarov  
wrote:
>>> 
>>> Hi,
>>> 
>>> Could you review fix in test library which should help to resolve 
intermittent issues on Windows machines during directories clean up. 
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184961 

>>> Review: 
http://cr.openjdk.java.net/~anazarov/JDK-8184961/webrev.00/webrev/
>>> 
>>> 
>>> —Andrei
> 

Re: java.util.Pair

[Hohensee, Paul]

Thanks for the immediate response.

Having read the thread, I understand the argument against including Pair in the 
JDK and personally agree with the sw engineering argument. But, it got into 
javafx.util somehow and is now effectively part of the JDK anyway, so that ship 
has sailed. Thus, it seemed reasonable me to just copy it from there into 
java.util, though there would be a maintenance headache if it were desired to 
keep them sync’ed.

I suppose also that there’s a pov that having it in javafx.util indirectly 
encourages JavaFX adoption. (

Anyhow, thanks for the explanation.

Paul

On 7/13/17, 10:22 AM, "joe darcy" <joe.da...@oracle.com> wrote:

Hi Paul,

See the discussion in thread:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html

In short, no current plans to add java.util.Pair.

-Joe


On 7/13/2017 10:07 AM, Hohensee, Paul wrote:
> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.
>
> At Amazon, many projects depend on JavaFX to get only a single class, 
namely javafx.util.Pair. That means that we must distribute OpenJFX along with 
our internal OpenJDK distribution, or split javafx.util.Pair out into a 
separate package, both of which we’d like to avoid in the future. So, are there 
any plans to add java.util.Pair to JDK10?
>
> Thanks,
>
> Paul
>

Re: java.util.Pair

[Hohensee, Paul]

That’s a possibility. We could recommend that as an alternative.

Thanks,

Paul

On 7/13/17, 10:29 AM, "Maurizio Cimadamore" <maurizio.cimadam...@oracle.com> 
wrote:

Maybe automatic refactoring to Map.Entry ? With the new static method 
added in 9, creating one is also very fluent (but I know that Entry 
doesn't convey same meaning as Pair in method signatures/fields)

http://download.java.net/java/jdk9/docs/api/java/util/Map.html#entry-K-V-

Cheers
Maurizio


On 13/07/17 18:22, joe darcy wrote:
> Hi Paul,
>
> See the discussion in thread:
>
> 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html 
>
> 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html 
>
>
> In short, no current plans to add java.util.Pair.
>
    > -Joe
    >
>
> On 7/13/2017 10:07 AM, Hohensee, Paul wrote:
>> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.
>>
>> At Amazon, many projects depend on JavaFX to get only a single class, 
>> namely javafx.util.Pair. That means that we must distribute OpenJFX 
>> along with our internal OpenJDK distribution, or split 
>> javafx.util.Pair out into a separate package, both of which we’d like 
>> to avoid in the future. So, are there any plans to add java.util.Pair 
>> to JDK10?
>>
>> Thanks,
>>
>> Paul
>>
>

java.util.Pair

[Hohensee, Paul]

See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.

At Amazon, many projects depend on JavaFX to get only a single class, namely 
javafx.util.Pair. That means that we must distribute OpenJFX along with our 
internal OpenJDK distribution, or split javafx.util.Pair out into a separate 
package, both of which we’d like to avoid in the future. So, are there any 
plans to add java.util.Pair to JDK10?

Thanks,

Paul