September 2021 - core-libs-dev

RFR: 8274392: Suppress more warnings on non-serializable non-transient instance fields in java.sql.rowset
by Joe Darcy 27 Sep '21

27 Sep '21

Follow-up change to JDK-8231442, augmentations to javac's Xlint:serial checking are out for review (#5709) and java.sql.rowset would need some changes to pass under the expanded checks. The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. ------------- Commit messages: - 8274392: Suppress more warnings on non-serializable non-transient instance fields in java.sql.rowset Changes: https://git.openjdk.java.net/jdk/pull/5719/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5719&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274392 Stats: 13 lines in 7 files changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5719.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5719/head:pull/5719 PR: https://git.openjdk.java.net/jdk/pull/5719

3 4

RFR: JDK-8274311: Make build.tools.jigsaw.GenGraphs more configurable
by Mandy Chung 27 Sep '21

27 Sep '21

GenGraphs tool generates the module graph. It currently supports the configuration via javadoc-graphs.properties. However, `make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only documents two properties. It should be updated to cover all configurable properties. There are a couple other properties not configurable such as nodesep and node margin. This extends the configuration to allow to set additional properties. This also fixes `requiresMandatedColor` in javadoc-graphs.properties to light gray to match the default configuration in the implementation, i.e. the color of the edge to java.base. It seems a bug that was unnoticed until Alex and Iris spotted it. ------------- Commit messages: - JDK-8274311: Make build.tools.jigsaw.GenGraphs more configurable Changes: https://git.openjdk.java.net/jdk/pull/5690/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5690&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274311 Stats: 167 lines in 3 files changed: 100 ins; 33 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/5690.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5690/head:pull/5690 PR: https://git.openjdk.java.net/jdk/pull/5690

3 3

RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
by Joe Darcy 27 Sep '21

27 Sep '21

This is an initial PR for expanded lint warnings done under two bugs: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type to get feedback on the general approach and test strategy before further polishing the implementation. The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. Please also review the corresponding CSRs: https://bugs.openjdk.java.net/browse/JDK-8274335 https://bugs.openjdk.java.net/browse/JDK-8274336 Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. ------------- Commit messages: - Appease jcheck - Implement checks chegar recommended for interfaces. - Update comment. - Add tests for instance field checks. - Clean build with instance field checks in place. - Merge branch 'master' into JDK-8202056 - Put Externalizable checks last. - Add checks for constructor access in Serializable classes. - Add no-arg ctor check for Externalizable classes. - Improve Externalization warnings. - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5756385c...d498ff5f Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8202056 Stats: 1519 lines in 79 files changed: 1511 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709

2 1

RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing
by wxiang 27 Sep '21

27 Sep '21

Using jarIndex for Hibench, there is an unexpected behavior with the exception "Exception in thread "main" org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme "hdfs"". After investigating it, it is related to the usage of ServiceLoader with JarIndex. The below stack shows the issue with JDK11: getResource:1016, URLClassPath$JarLoader (jdk.internal.loader) getResource:937, URLClassPath$JarLoader (jdk.internal.loader) findResource:912, URLClassPath$JarLoader (jdk.internal.loader) next:341, URLClassPath$1 (jdk.internal.loader) hasMoreElements:351, URLClassPath$1 (jdk.internal.loader) hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader) hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader) next:3032, CompoundEnumeration (java.lang) hasMoreElements:3041, CompoundEnumeration (java.lang) nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util) hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util) hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util) hasNext:1300, ServiceLoader$2 (java.util) hasNext:1385, ServiceLoader$3 (java.util) The below API tries to get all the resources with the same name. public Enumeration<URL> findResources(final String name, final boolean check) ``` After using JarIndex, URLClassPath.findResources only returns 1 URL. It is the same as the description in JDK-6957241. The issue still exists in JDK18. Root cause: public Enumeration<URL> findResources(final String name, final boolean check) { return new Enumeration<>() { private int index = 0; private URL url = null; private boolean next() { if (url != null) { return true; } else { Loader loader; while ((loader = getLoader(index++)) != null) { url = loader.findResource(name, check); if (url != null) { return true; } } return false; } } ... }; } With the JarIndex, there is only one loader which is corresponding to the jar with the index due to the implementation in JarLoader.getResource(final String name, boolean check, Set<String> visited). Loaders corresponding to other jar packages will not appear in this while. So it only returns 1 instance. To solve the issue, I change the implementation "private boolean next()". If the loader has index, traverse the index and get all the resource from the loader. ------------- Commit messages: - solve Whitespace error - 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing Changes: https://git.openjdk.java.net/jdk/pull/5316/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5316&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6957241 Stats: 769 lines in 8 files changed: 763 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5316/head:pull/5316 PR: https://git.openjdk.java.net/jdk/pull/5316

6 13

RFR: 8273401: Remove JarIndex support in URLClassPath
by wxiang 27 Sep '21

27 Sep '21

There is a bug for URLClassPath.findResources with JarIndex. With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, and don’t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. The PR includes: 1. remove the JarIndex support in URLClassPath 2. move JarIndex into jdk.jartool module. ------------- Commit messages: - 8273401: Remove JarIndex support in URLClassPath Changes: https://git.openjdk.java.net/jdk/pull/5383/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5383&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273401 Stats: 1117 lines in 21 files changed: 7 ins; 1098 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5383.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5383/head:pull/5383 PR: https://git.openjdk.java.net/jdk/pull/5383

5 18

RFR: 8274293: Build failure with Xcode 13.0 due to vfork is deprecated
by xpbob 26 Sep '21

26 Sep '21

remove vfork() on Darwin ------------- Commit messages: - 8274293: Build failure with Xcode 13.0 due to vfork is deprecated Changes: https://git.openjdk.java.net/jdk/pull/5686/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5686&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274293 Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5686.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5686/head:pull/5686 PR: https://git.openjdk.java.net/jdk/pull/5686

4 7

RFR: 8273401: Disable JarIndex support in URLClassPath
by wxiang 26 Sep '21

26 Sep '21

There is a bug for URLClassPath.findResources with JarIndex. Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. A system property can be used to re-enable JarIndex support in URLClassPath. The PR includes: Disable JarIndex support in URLClassPath by default. Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. ------------- Commit messages: - 8273401: Disable JarIndex support in URLClassPath Changes: https://git.openjdk.java.net/jdk/pull/5524/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5524&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273401 Stats: 13 lines in 3 files changed: 8 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5524/head:pull/5524 PR: https://git.openjdk.java.net/jdk/pull/5524

5 23

RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0
by Roger Riggs 24 Sep '21

24 Sep '21

On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property and the version number provided by `sw_vers -productVersion`. When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 though the current version numbering is 11.nnn. The workaround is to derive the os.version number from the ProductBuildVersion. When the toolchain is updated to XCode 12.nnn it can be removed. The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. ------------- Commit messages: - 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 Changes: https://git.openjdk.java.net/jdk/pull/2530/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2530&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253702 Stats: 30 lines in 1 file changed: 21 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2530/head:pull/2530 PR: https://git.openjdk.java.net/jdk/pull/2530

5 20

RFR: 8274234: Remove unnecessary boxing via primitive wrapper valueOf(String) methods in java.sql.rowset
by Andrey Turbanov 24 Sep '21

24 Sep '21

Usages of methods Integer.valueOf, Byte.valueOf, Short.valueOf, Float.valueOf, Double.valueOf, Long.valueOf often can be simplified by using their pair methods parseInt/parseLong/parseShort/parseByte/parseFloat. ------------- Commit messages: - [PATCH] Remove unnecessary boxing via primitive wrapper valueOf(String) methods in java.sql.rowset Changes: https://git.openjdk.java.net/jdk/pull/5662/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5662&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274234 Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5662.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5662/head:pull/5662 PR: https://git.openjdk.java.net/jdk/pull/5662

3 3

RFR: JDK-8274087: Windows DLL path not set correctly.
by Andy Herrick 24 Sep '21

24 Sep '21

JDK-8274087: Windows DLL path not set correctly. ------------- Commit messages: - JDK-8274087: Windows DLL path not set correctly. Changes: https://git.openjdk.java.net/jdk/pull/5663/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5663&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274087 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5663/head:pull/5663 PR: https://git.openjdk.java.net/jdk/pull/5663

3 3