October 2021 - core-libs-dev

RFR: JDK-8275186: Suppress warnings on non-serializable array component types in xml
by Joe Darcy 13 Oct '21

13 Oct '21

After a refinement to the checks under development in https://github.com/openjdk/jdk/pull/5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. >From "Java Object Serialization Specification: 2 - Object Output Classes": "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." ------------- Commit messages: - JDK-8275186: Suppress warnings on non-serializable array component types in xml Changes: https://git.openjdk.java.net/jdk/pull/5924/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5924&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275186 Stats: 8 lines in 6 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5924.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5924/head:pull/5924 PR: https://git.openjdk.java.net/jdk/pull/5924

2 4

RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries
by Maurizio Cimadamore 12 Oct '21

12 Oct '21

This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. ------------- Commit messages: - Improve javadoc - Initial push Changes: https://git.openjdk.java.net/jdk/pull/4316/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268129 Stats: 1278 lines in 44 files changed: 569 ins; 617 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316

6 23

RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable
by Сергей Цыпанов 12 Oct '21

12 Oct '21

In some JDK classes there's still the following hashCode() implementation: long objNum; public int hashCode() { return (int) objNum; } This outdated expression should be replaced with Long.hashCode(long) as it - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. See https://stackoverflow.com/a/4045083 This is related to https://github.com/openjdk/jdk/pull/4309 ------------- Commit messages: - 8268764: Use Long.hashCode() instead of int-cast where applicable Changes: https://git.openjdk.java.net/jdk/pull/4491/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268764 Stats: 15 lines in 9 files changed: 6 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4491.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491 PR: https://git.openjdk.java.net/jdk/pull/4491

5 12

Questions for JDK-4947890
by Ichiroh Takiguchi 12 Oct '21

12 Oct '21

I have some questions for JDK-4947890。 One of app’s JVM was upgraded from JDK11 to JDK17. Then the working behavior was changed on Windows 10 Multilingual User Interface (MUI). (Base was Japanese Windows 10, display language setting was English (United States)) In my investigation, the working behavior was changed by JDK12+b23. JDK-4947890 Minimize JNI upcalls in system-properties initialization [1] Following change was applied on src/java.base/share/native/libjava/System.c, From (not for MacOS platform) [2] Put sprops->sun_jnu_encoding into file.encoding system property To [3] Put sprops->encoding into file.encoding system property I checked JDK-4947890’s CSR JDK-8213895 [4] Modify JVM interface functions for property initialization But it seems that above CSR does not mention such a significant specification change. I checked JDK17u, same code was still used [5]. Questions: I’d like to confirm * This change was intentional or not ? * We can revert tp JDK11’s spec ? Thanks, Ichiroh Takiguchi [1] https://bugs.openjdk.java.net/browse/JDK-4947890 [2] http://hg.openjdk.java.net/jdk/jdk/rev/0bdbf854472f#l12.466 [3] http://hg.openjdk.java.net/jdk/jdk/rev/0bdbf854472f#l12.276 [4] https://bugs.openjdk.java.net/browse/JDK-8213895 [5] https://github.com/openjdk/jdk17u/blob/master/src/java.base/share/native/li…

2 1

RFR: 8271737: Only normalize the cached user.dir property once
by Evgeny Astigeevich 12 Oct '21

12 Oct '21

The change completes the fix of [JDK-8198997](https://bugs.openjdk.java.net/browse/JDK-8198997) which has added normalisation in a constructor but not removed it from the get method. ------------- Commit messages: - 8271737: Only normalize the cached user.dir property once Changes: https://git.openjdk.java.net/jdk/pull/5850/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5850&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271737 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5850.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5850/head:pull/5850 PR: https://git.openjdk.java.net/jdk/pull/5850

3 2

RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
by Andrey Turbanov 12 Oct '21

12 Oct '21

8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE ------------- Commit messages: - [PATCH] Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE Changes: https://git.openjdk.java.net/jdk/pull/5878/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5878&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275002 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5878.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5878/head:pull/5878 PR: https://git.openjdk.java.net/jdk/pull/5878

6 12

RFR: 8177814: jdk/editpad is not in jdk TEST.groups
by Aleksey Shipilev 12 Oct '21

12 Oct '21

@prrace notices this here: https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think it is the already open issue that this patch is fixing. While the original patch added the test in `jdk_other`, Phil suggests it to be added to `jdk_desktop`. Additional testing: - [x] `jdk_editpad` is passing ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5648/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5648&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8177814 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5648.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5648/head:pull/5648 PR: https://git.openjdk.java.net/jdk/pull/5648

2 5

Re: Optimizing InputStream.skip(long)
by - 11 Oct '21

11 Oct '21

Thanks for the suggestion. Forwarding to the core libs list. On Sun, Oct 10, 2021 at 6:52 PM David Holmes <david.holmes(a)oracle.com> wrote: > > Hi, > > This belongs on core-libs-dev(a)openjdk.java.net > > Thanks, > David > > On 11/10/2021 9:39 am, - wrote: > > On GitHub, xenoamess sent a pull request [1] that optimizes skipBuffer > > array used by InputStream.skip by caching one for each InputStream > > instance (static ones are unsafe per bug 7000600) like the > > java.io.Reader class does (the reader one is behind a lock, while this > > one is possibly concurrent). > > > > Pros: Input streams that inherit the default skip logic can reduce > > buffer array creation by reusing the compatible old array when the > > skip method is called multiple times. > > > > Cons: This adds a field to InputStream; the array cannot be GC'd until > > the InputStream is GC'd. (But it has a length limit and the impact is > > less) > > > > Additional Info: Most JDK InputStream implementations already > > overrides this method to offer a more efficient implementation as > > suggested in the Javadocs. Reader.skip(long) calls Reader.read(char[], > > int, int), and this change doesn't affect the Reader class. > > > > I wonder if this idea is worthy of a JDK issue so this patch may > > eventually be accepted. Feel free to post any feedback, too! > > > > [1]: https://git.openjdk.java.net/jdk/pull/5872 > >

1 0

Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places?
by Xeno Amess 09 Oct '21

09 Oct '21

I suggest putting them in Arrays btw.

2 3

Unexepcted OutOfMemoryError from Arrays.deepToString
by Andrey Turbanov 09 Oct '21

09 Oct '21

Hello. I came across unexpected behaviour of Arrays.deepToString method. It throws OOM even on non-huge arrays. For example this code: int size = Integer.MAX_VALUE / 19; Integer[] integers = new Integer[size]; Arrays.fill(integers, 0); System.out.println(Arrays.deepToString(integers)); Fails with following stack trace: Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit at java.base/java.lang.AbstractStringBuilder.<init>(AbstractStringBuilder.java:86) at java.base/java.lang.StringBuilder.<init>(StringBuilder.java:112) at java.base/java.util.Arrays.deepToString(Arrays.java:5160) I believe it should be able to handle such arrays and not throw OOM Andrey Turbanov

2 3