Re: [15] RFR: 8241311: Move some charset mapping tests from closed to open

Thank you Naoto for the quick update. Just more findings ...(sorry for not sending earlier) CoderTest.java Looks like this test has already been migrated (with enhancement) to the 'open' [1] in JDK-8186801 [2] [3]. I'm not sure whether the data files that used by TestCharsetMapping.java can

Re: [15] RFR: 8241311: Move some charset mapping tests from closed to open

Hi Amy, Good point. Updated. https://cr.openjdk.java.net/~naoto/8241311/webrev.06/ Naoto On 3/23/20 7:43 PM, Amy Lu wrote: Hi, Naoto CoderTest.java TestConv.java Should they also include @modules jdk.charsets ? Thanks, Amy On 3/21/20 12:21 AM, naoto.s...@oracle.com wrote: Hello, Please

Re: [15] RFR: 8241311: Move some charset mapping tests from closed to open

Hi, Naoto CoderTest.java TestConv.java Should they also include @modules jdk.charsets ? Thanks, Amy On 3/21/20 12:21 AM, naoto.s...@oracle.com wrote: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8241311 The proposed changeset is located at:

[PING] RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap

Hello! A gentle reminder to review the specialized implementation of TreeMap methods. The latest webrev is here: http://cr.openjdk.java.net/~tvaleev/webrev/8176894/r4/ Issue: https://bugs.openjdk.java.net/browse/JDK-8176894 CSR is already approved (thanks to Joe Darcy and Stuart Marks):

Re: [15] RFR: 8241311: Move some charset mapping tests from closed to open

Hi Takiguchi-san, On 3/23/20 5:48 AM, Ichiroh Takiguchi wrote: Hello Naoto. I'm not reviewer, but I have a concern about following code on test/jdk/sun/nio/cs/mapping/TestConv.java ==  98 } catch (Exception ex) {  99 System.out.println("Exception thrown while

Re: RFR: JDK-8241463 Move build tools to respective modules

Hi Magnus, I looked at i18n related changes: make/CopyInterimTZDB.gmk make/ToolsJdk.gmk make/gendata/Gendata-java.base.gmk make/gendata/GendataBreakIterator.gmk make/gendata/GendataTZDB.gmk make/gensrc/GensrcCharacterData.gmk make/gensrc/GensrcEmojiData.gmk They look ok to me. The *.java

Re: RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays

On 23/03/2020 19:22, Aleksey Shipilev wrote: : +import java.io.InputStream; import java.io.IOException; import java.lang.ProcessBuilder.Redirect; @@ -314,5 +315,8 @@ String relativeDbgFileName = relativeFileName + "." + debugExt; -

Re: RFR: JDK-8241463 Move build tools to respective modules

On 23/03/2020 19:03, Magnus Ihse Bursie wrote: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so anymore.

Re: RFR: JDK-8241463 Move build tools to respective modules

Hi Magnus, Modularizing the build tools is a good move.    This patch suggests to place the build tools under     src/$MODULE/share/tools/$PACKAGE/*.java I think the modular source location of the build tools needs more discussion, including jigsaw-dev for this discussion. The JDK source

Re: RFR: JDK-8241463 Move build tools to respective modules

Looks good. /Erik On 2020-03-23 12:03, Magnus Ihse Bursie wrote: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so

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

On 23/03/2020 19:39, Chris Hegarty wrote: On 23 Mar 2020, at 19:18, Alan Bateman > wrote: ... Socket(SocketImpl) is only specified to do a permission check when the impl is non-null. The socket adaptor in JDK 12 and older releases doesn't have a dummy

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

On 23/03/2020 18:07, Doerr, Martin wrote: Hi, I'd like to backport JDK-8223326 from jdk/jdk. One other thing on this. It looks like the spec changes that were part of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by mistake. Is that part of the issue that you are trying to

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

> On 23 Mar 2020, at 19:18, Alan Bateman wrote: > >> ... >> > Socket(SocketImpl) is only specified to do a permission check when the impl > is non-null. The socket adaptor in JDK 12 and older releases doesn't have a > dummy impl so the change should not be needed. If there is a security >

RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays

RFE: https://bugs.openjdk.java.net/browse/JDK-8241462 In some of my testing pipelines that deal with huge .so-s due to specific build configuration, tests that use the StripNativeDebugSymbols plugin fail with OOME. It can be fixed by using the method that copies the InputStream straight to

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

On 23/03/2020 18:07, 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:

RFR: JDK-8241463 Move build tools to respective modules

The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so anymore. Instead, the build tools source code should move the the

Re: RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode

Looks good. /Erik On 2020-03-23 10:56, Andrew Dinn wrote: Could I please have a review for this trivial fix to the module make file which ensures that javadoc is generated for new module jdk.nio.mapmode created as part of the implementation of JEP 352. The original patch added the module to

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

Hi Paul, thanks for the review. We had already asked, but this one can't get opened up. I would have preferred a normal backport, too. Best regards, Martin > -Original Message- > From: Hohensee, Paul > Sent: Montag, 23. März 2020 19:29 > To: Doerr, Martin ; core-libs- >

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" wrote:

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

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

RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode

Could I please have a review for this trivial fix to the module make file which ensures that javadoc is generated for new module jdk.nio.mapmode created as part of the implementation of JEP 352. The original patch added the module to the BOOT_MODULES list but was not to the DOCS_MODULES list.

Re: RFR: 8241055: Regex Grapheme Matcher Performance Depends too much on Total Input Sequence Size

I am planning to work on it. Naoto On 3/21/20 7:58 AM, Philipp Kunz wrote: Hi, Any opinions on the attached patch or someone tempted to sponsor it? Regards, Philipp

Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

Hi Philipp, Right, Locale.ROOT is more appropriate here by definition, though the implementation is the same. Naoto On 3/21/20 5:19 AM, Philipp Kunz wrote: Hi Naoto and everyone, There are almost as many occurrences of Locale.ROOT as Locale.US which made me wonder which one is more

Re: 8241415: tools/jpackage/share/RuntimePackageTest.java fails because of systemPrefs files

On 23/03/2020 13:20, Baesken, Matthias wrote: : Hopefully we can identify the "bad guys" in the test set without too much effort  ! It would be to put the JDK on read-only file system and see if any tests fail. As to the "bad guys", the tests in test/jdk/java/util/prefs would be good place

RFR (XS/T) 8241445: Fix copyrights after JDK-8240629 change

This change in JDK-8240629 was not correct and slipped the review? https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2#l2.5 Also, other file has not updated the copyright line. Fix: diff -r 35ff74547c64 src/java.base/share/native/libjli/args.c --- a/src/java.base/share/native/libjli/args.c

RE: 8241415: tools/jpackage/share/RuntimePackageTest.java fails because of systemPrefs files

Hi Alan, >Tests should never modify the "JDK under test". That was my assumption too. >It should be possible to >test a JDK that is on a read-only file system for example. There are a >small number of tests that need  edit configuration files and they are >supposed to replicate the JDK to

Re: [15] RFR: 8241311: Move some charset mapping tests from closed to open

Hello Naoto. I'm not reviewer, but I have a concern about following code on test/jdk/sun/nio/cs/mapping/TestConv.java == 98 } catch (Exception ex) { 99 System.out.println("Exception thrown while testing " + encoding); 100 ex.printStackTrace();

Re: 8241415: tools/jpackage/share/RuntimePackageTest.java fails because of systemPrefs files

On 23/03/2020 07:44, Baesken, Matthias wrote: Hello, we noticed the following issue in tools/jpackage/share/RuntimePackageTest.java . See also https://bugs.openjdk.java.net/browse/JDK-8241415 . When running a whole jdk jtreg test suite we see failures of the the

8241415: tools/jpackage/share/RuntimePackageTest.java fails because of systemPrefs files

Hello, we noticed the following issue in tools/jpackage/share/RuntimePackageTest.java . See also https://bugs.openjdk.java.net/browse/JDK-8241415 . When running a whole jdk jtreg test suite we see failures of the the tools/jpackage/share/RuntimePackageTest.java test. Failures are like this :