March 2021 - core-libs-dev

Looking for a starter task. Maybe JDK-8253396 ?
by Suren Nihalani 23 Mar '21

23 Mar '21

Hi, I am new openjdk (I've been using java for 7 years but I am new to contributing to openjdk!). I was looking for interesting starter tasks to help out with. JDK-8253396 looked like an easy to implement candidate. I am open to other suggestions too (feel free to little r as well)! The contribution guide suggested I socialize my change before I code it up. Seems like the implementation would be straightforward and similar to Predicate.java. Are folks okay with this change? Thanks for looking into this!

2 1

RFR: 8264032: Improve thread safety of Runtime.version()
by Andrey Turbanov 23 Mar '21

23 Mar '21

Avoid double-read non volatile static field ------------- Commit messages: - [PATCH] Thread-safe initialization of Runtime.version Changes: https://git.openjdk.java.net/jdk/pull/2691/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2691&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264032 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2691.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2691/head:pull/2691 PR: https://git.openjdk.java.net/jdk/pull/2691

4 7

RFR: 8261673: Move javadoc for the lookup mechanism to module-info
by Joe Wang 23 Mar '21

23 Mar '21

Consolidate and move javadoc for the lookup mechanism to the module summary. ------------- Commit messages: - 8261673: Move javadoc for the lookup mechanism to module-info Changes: https://git.openjdk.java.net/jdk/pull/3020/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3020&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261673 Stats: 602 lines in 9 files changed: 197 ins; 361 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/3020.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3020/head:pull/3020 PR: https://git.openjdk.java.net/jdk/pull/3020

4 8

RFR: JDK-8263154: [macos] DMG builds have finder errors
by Andy Herrick 22 Mar '21

22 Mar '21

JDK-8263154: [macos] DMG builds have finder errors ------------- Commit messages: - JDK-8263154: [macos] DMG builds have finder errors Changes: https://git.openjdk.java.net/jdk/pull/2987/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2987&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263154 Stats: 11 lines in 2 files changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2987.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2987/head:pull/2987 PR: https://git.openjdk.java.net/jdk/pull/2987

3 5

RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM
by Henry Jen 22 Mar '21

22 Mar '21

This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS. As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu. The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set. ------------- Commit messages: - 8261785: Calling "main" method in anonymous nested class crashes the JVM Changes: https://git.openjdk.java.net/jdk/pull/2999/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2999&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261785 Stats: 111 lines in 3 files changed: 110 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2999.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2999/head:pull/2999 PR: https://git.openjdk.java.net/jdk/pull/2999

4 16

RFR: 8263729: [test] Extend time to wait before destroying child in ProcssBuilder Basic test
by Roger Riggs 22 Mar '21

22 Mar '21

Intermittent failures on Windows in a test of destroying the child warrant extending the time the parent waits after starting the child before destroying the child. ------------- Commit messages: - 8263729: [test] Extend time to wait before destroying child in ProcessBuilder Basic test Changes: https://git.openjdk.java.net/jdk/pull/3049/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3049&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263729 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3049.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3049/head:pull/3049 PR: https://git.openjdk.java.net/jdk/pull/3049

4 30

RFR: 8263855: Use the blessed modifier order in java.management/naming
by Alex Blewitt 22 Mar '21

22 Mar '21

As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules. ------------- Commit messages: - Use the blessed modifier order in java.management/naming Changes: https://git.openjdk.java.net/jdk/pull/3078/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3078&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263855 Stats: 158 lines in 39 files changed: 0 ins; 0 del; 158 mod Patch: https://git.openjdk.java.net/jdk/pull/3078.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3078/head:pull/3078 PR: https://git.openjdk.java.net/jdk/pull/3078

4 12

java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)?
by Jaikiran Pai 22 Mar '21

22 Mar '21

Please consider this trivial code: import java.io.*; import java.nio.file.*; public class FileTest { public static void main(final String[] args) throws Exception { System.getProperties().list(System.out); final File f = new File("NUL:"); try (final InputStream fis = Files.newInputStream(f.toPath())) { int numBytes = 0; while (fis.read() != -1) { System.out.println("Files.newInputStream - Read a byte from " + f); numBytes++; } System.out.println("Files.newInputStream - Done reading " + numBytes + " bytes from " + f); } } } The code tries to read from NUL: on a Windows setup. This code runs into the following exception on Windows when the java.io.File#toPath() gets invoked: Exception in thread "main" java.nio.file.InvalidPathException: Illegal char <:> at index 3: NUL: at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) at java.base/java.io.File.toPath(File.java:2316) at FileTest.main(FileTest.java:18) So it looks like java.io.File.toPath() on Windows isn't able to recognize the null device construct? Just to make sure this issue resides only this specific API implementation, I switched the above code to use new FileInputStream(f) as follows and that works as expected - reads 0 bytes and completes successfully. So the NUL: construct is indeed understood by the other APIs. public class FileTest { public static void main(final String[] args) throws Exception { System.getProperties().list(System.out); final File f = new File("NUL:"); try (final FileInputStream fis = new FileInputStream(f)) { int numBytes = 0; while (fis.read() != -1) { System.out.println("FileInputStream() - Read a byte from " + f); numBytes++; } System.out.println("FileInputStream() - Done reading " + numBytes + " bytes from " + f); } } } Output: FileInputStream() - Done reading 0 bytes from NUL: Test results are from latest Java 16 release on a Windows setup. -Jaikiran

3 10

Problem signing Windows JPackage installers
by Zlatin Balevsky 21 Mar '21

21 Mar '21

Hi, The installers that JPackage 16 generates seem to just extract an .msi which performs the actual installation. There are two problems with that: 1. The .msi is extracted to a temporary location and has a temporary name. So the windows prompt that shows up and asks the user whether they are sure they want to perform the installation does not show the name of the installer/application. 2. Furthermore, even if the .exe installer is signed with a code signing certificate, since the window prompts on the extracted .msi, the prompt is still colored yellow instead of blue (which is what it should be when the installer is signed) In my use case it is essential that the prompt appears blue, so I'm forced to use a hybrid approach of generating the app image with JPackage and then using a different installer framework (like NSIS) to generate the final distributable. Of course this is far from ideal. Just thought I'd let you know and best regards, Zlatin Balevsky

1 0

Class.getRecordComponents security checks
by Attila Szegedi 20 Mar '21

20 Mar '21

Hey folks, Why are security checks for Class.getRecordComponents as strict as those for e.g. getDeclaredMethods? I would’ve expected they’d be as strict as those for e.g. getMethods. Specifically, the difference is the: > “the caller's class loader is not the same as the class loader of this class and invocation of s.checkPermission method with RuntimePermission("accessDeclaredMembers") denies access to the declared methods within this class” step. Aren’t record accessors supposed to be public? Attila.

2 2