March 2020 - core-libs-dev

Re: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")
by Hohensee, Paul 24 Mar '20

24 Mar '20

Thanks for the explanation of the process. Paul On 3/23/20, 11:28 PM, "Langer, Christoph" <christoph.langer(a)sap.com> 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 <core-libs-dev-bounces(a)openjdk.java.net> On Behalf > Of Hohensee, Paul > Sent: Montag, 23. März 2020 19:29 > To: Doerr, Martin <martin.doerr(a)sap.com>; core-libs- > dev(a)openjdk.java.net; jdk-updates-dev(a)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" <jdk- > updates-dev-bounces(a)openjdk.java.net on behalf of > martin.doerr(a)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 > >

1 0

RFR: JDK-8241463 Move build tools to respective modules
by Magnus Ihse Bursie 24 Mar '20

24 Mar '20

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 module that needs them. For instance, compilefontconfig should move to java.desktop, etc. There are multiple reasons for this: * Currently we build *all* build tools at once, which mean that we cannot compile java.base until e.g. the compilefontconfig tool is compiled, even though it is not needed. * If a build tool, e.g. compilefontconfig is modified, all build tools are recompiled, which triggers a rebuild of more or less the entire JDK. This makes development of the build tools unnecessary tedious. * When the build tools are modified, the group owning the corresponding module is the proper review instance, not the build team. But since they reside under "make", the review mails often include build-dev, but this is mostly noise for us. With this move, the ownership is made clear. In this patch, I have not modified how and when the build tools are compiled, but this shuffle is the prerequisite for continuing with that in a follow-up patch. I have also moved the build tools to the org.openjdk.buildtools.* package name space (inspired by Skara), instead of the strangely named build.tools.* name space. A few build tools are not moved in this patch. Two of them, charsetmapping and cldrconverter, are shared between two modules. (I think they should move to modules nevertheless, but they need some more thought to make sure I do this right.) The rest are tools that are needed for the build in general, like linking or javadoc support. I'll move this to a better location too, but in a separate patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/we… /Magnus

5 5

[11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")
by Doerr, Martin 24 Mar '20

24 Mar '20

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

4 12

RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")
by Hohensee, Paul 24 Mar '20

24 Mar '20

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" <jdk-updates-dev-bounces(a)openjdk.java.net on behalf of martin.doerr(a)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

3 2

8241415: tools/jpackage/share/RuntimePackageTest.java fails because of systemPrefs files
by Baesken, Matthias 23 Mar '20

23 Mar '20

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 : TRACE: Missing 3 files: TRACE: .systemPrefs TRACE: .systemPrefs/.system.lock TRACE: .systemPrefs/.systemRootModFile TRACE: Done ERROR: Failed: Check there are no missing files in installed image Looking into the jdk under test, we notice the mentioned files were created inside the jdk under test (by previous jtreg tests, this is indicated by the time stamps of those files). my estimation is that some other tests using FileSystemPreferences might created those files. The RuntimePackageTest.java test however does not expect those files in the jdk image under test. Any comments ? Should we check for these files at just delete them at the beginning of tools/jpackage/share/RuntimePackageTest.java (or skip the test in case the files exist) ? Otherwise we might tolerate those 3 files . Any suggestions ? Thanks, Matthias

2 3

RFR [15] 8241014: Miscellaneous typos in documentation comments
by Pavel Rappo 20 Mar '20

20 Mar '20

Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ This is a documentation cleanup. There are no code changes involved, and the changes in documentation are mostly trivial. The following packages are affected: java.lang, java.nio.file, java.nio.file.attribute, java.security, java.time.chrono, java.time.temporal, java.util, java.util.regex, java.util.stream, javax.crypto, javax.security.cert, javax.tools That said, there are two changes that I'd prefer to be carefully reviewed by the experts in the corresponding areas. The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and supported for the sake of backward compatibility. Sadly, we have a number of those in OpenJDK. Even though I performed reasonable checks, the proposed fix should better be verified by the security folk. The second one is for the doc comment for the java.util.stream.Stream.collect method. @apiNote The following will accumulate strings into an ArrayList: List<String> asList = stringStream.collect(Collectors.toList()); Given that the spec for Collectors.toList() clearly says that ...There are no guarantees on the type, mutability, serializability, or thread-safety of the List returned;... I'd assume that @apiNote should be fixed as proposed. -Pavel P.S. Apologies for spamming multiple mailing lists.

5 8

Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading
by Mandy Chung 20 Mar '20

20 Mar '20

Webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.00/ This is a follow-up task for Panama to allow explicit unloading of native library after JDK-8228336. `NativeLibraries` associated with a class loader has the capability to auto unload native libraries when the class loader is reclaimed. This adds a new `NativeLibraries::unload` method that provides the ability to unload a native library on request. This only allows `NativeLibraries` of no relationship with a class loader where auto unloading is disabled. Thanks Mandy

3 13

RFR: JDK-8241310 Fix warnings in jdk buildtools
by Magnus Ihse Bursie 20 Mar '20

20 Mar '20

The buildtools (java tools needed to be run during the build) have long been plagued by warnings, includuing deprecations and unchecked warnings, which cannot be silenced during the build. This patch fixes all buildtool warnings. Most of the warnings are fixed properly, but a few have had their warnings suppressed locally. For two tools, cldrconverter and tzdb, I gave up to get them fully fixed, and instead suppressed warnings in some places. Common for both these tools were that they used collections of some kind, with a mixed bag of data types (e.g. a Map from String to either String, HashMap, ArrayList and String[]). I'm frankly not sure how this could ever have worked :-) but I assume that the data files being parsed has a structure that "guarantees" that this works. Two files in generatecharacter were missing a proper copyright header. I noticed this when I were about to update the copyright year, and when I checked the other files I noted another one without header. While I did not need to change this file, I thought it was suitable to fix the missing header for both files. I have verified that the code generated by the build is identical with and without this patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8241310 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241310-fix-warnings-in-buildtools/web… /Magnus

3 5

[15] RFR: 8241130: com.sun.jndi.ldap.EventSupport.removeDeadNotifier: java.lang.NullPointerException
by Chris Yin 20 Mar '20

20 Mar '20

Hello Please review following changes to fix corner issue in com.sun.jndi.ldap.EventSupport, thanks Bug: https://bugs.openjdk.java.net/browse/JDK-8241130 Webrev: http://cr.openjdk.java.net/~xyin/8241130/webrev.00/ This is a follow up item which related to 8202117. When testing the second revision fix for 8202117 (http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065270.html <http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065270.html>), intermittent failure with java.lang.NullPointerException been observed(Thanks Daniel for additional testing), that exposed another issue in com.sun.jndi.ldap.EventSupport. “com.sun.jndi.ldap.NamingEventNotifier" is a background thread which been created when addNamingListener with ldap context, per code logic, it will call EventSupport.removeDeadNotifier when encounter NamingException (maybe wrapped a SocketException) in some case, if user closed source ldap context first (EventSupport.cleanup been triggered), the call to EventSupport.removeDeadNotifier will throw NullPointerException since var “notifiers” already been set to null in previous EventSupport.cleanup. Maybe in real world, it’s hard to get all criteria been satisfied to reproduce, but it’s still a potential multithreading issue and caught by test with repeat run. Combined this change and 8202117 second revision change, run test com/sun/jndi/ldap/RemoveNamingListenerTest.java on 4 platforms for total 2000 times, no failure been observed, also tier1, tier2, tier3 tests passed. Thanks, Chris

2 4

RFR JEP 338: Vector API (Incubator), JDK-8223347 Integration of Vector API (Incubator): Vector API
by Paul Sandoz 19 Mar '20

19 Mar '20

Hi, This email is intended to kick start the review of JEP 338: Vector API (Incubator). For ease of review we intend to split this up into separate parts for review of the Java API, Java implementation, Java unit tests, Java jmh tests, shared hotspot code, and platform specific hotspot code. Emails will be sent for review hopefully all during this month (given global events though our productivity may be impacted as I might also anticipate for those reviewing). First up for review is the Vector API itself. JavaDoc and specdiff may be found here: http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/ <http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/> http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/docs/api/jdk.i… <http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/docs/api/jdk.i…> http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/docs/api/jdk.i… <http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/docs/api/jdk.i…> The CSR issue (https://bugs.openjdk.java.net/browse/JDK-8223348 <https://bugs.openjdk.java.net/browse/JDK-8223348>) has also been moved to proposed. For a holistic sense during this split review one can go directly to the Panama dev repository and checkout the (confusingly named) vector-unstable branch (it was just conveniently there separate from the vectorIntrinsics branch where ongoing work will happen). https://hg.openjdk.java.net/panama/dev/shortlog/vector-unstable <https://hg.openjdk.java.net/panama/dev/shortlog/vector-unstable> Paul.

1 0