December 2021 - core-libs-dev

Re: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v20]
by Andrew Leonard 10 Dec '21

10 Dec '21

On Tue, 7 Dec 2021 19:25:05 GMT, Lance Andersen <lancea(a)openjdk.org> wrote: >> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision: >> >> 8276766: Enable jar and jmod to produce deterministic timestamped content >> >> Signed-off-by: Andrew Leonard <anleonar(a)redhat.com> > > Looks like the CSR has been approved. I have a mach5 run that should hopefully finish sooner rather than later and if that remains happy, I will approve the PR @LanceAndersen thank you for the review comments, i've just done a new commit with them all done.. assuming all the tests run ok, i'll integrate ------------- PR: https://git.openjdk.java.net/jdk/pull/6481

1 0

RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr
by Chris Plummer 10 Dec '21

10 Dec '21

The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump. ------------- Commit messages: - Retry heap dump if main thread stack trace is not present. Changes: https://git.openjdk.java.net/jdk/pull/6795/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6795&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269556 Stats: 26 lines in 1 file changed: 19 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6795/head:pull/6795 PR: https://git.openjdk.java.net/jdk/pull/6795

2 1

Re: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v2]
by Alan Bateman 10 Dec '21

10 Dec '21

On Thu, 9 Dec 2021 07:58:33 GMT, Christian Stein <cstein(a)openjdk.org> wrote: >> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file. >> >> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object. >> >> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451). >> >> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079 > > Christian Stein has updated the pull request incrementally with two additional commits since the last revision: > > - Clean up reproducer test case > - Keep helper in ZipFileSystem simple src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java line 211: > 209: > 210: private String getRealPath(byte[] resolvedPath) { > 211: byte[] path = zfs.lookupPath(resolvedPath); Can getRealPath be changed to be no-arg method that calls getResolvedPath and then does the lookup. I think that would be a clearer than assuming the argument is a resolved path. ------------- PR: https://git.openjdk.java.net/jdk/pull/6768

2 1

[jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
by Jonathan Gibbons 10 Dec '21

10 Dec '21

Please review this semi-automatic update for the nroff man pages for JDK 18. The changes update the version number, copyright year, and incorporate the changes from the latest upstream files. ------------- Commit messages: - JDK-8273179: Update nroff pages in JDK 18 before RC Changes: https://git.openjdk.java.net/jdk18/pull/5/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=5&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273179 Stats: 858 lines in 28 files changed: 448 ins; 146 del; 264 mod Patch: https://git.openjdk.java.net/jdk18/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/5/head:pull/5 PR: https://git.openjdk.java.net/jdk18/pull/5

3 6

Request for backport the OpenJDK fix in XSLTC.java to JDK11 & JDK17
by Cheng Jin 10 Dec '21

10 Dec '21

Hi there, As for the bug with the class name in XSLTC.java I previously raised at https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/083135.… , I notice it has been resolved at https://bugs.openjdk.java.net/browse/JDK-8276657 as follows: https://github.com/openjdk/jdk/blob/a093cdddaf5ab88eb84a147e523db5c3e1be54b… public boolean compile(InputSource input, String name) { try { // Reset globals in case we're called by compile(ArrayList v); reset(); // The systemId may not be set, so we'll have to check the URL String systemId = null; if (input != null) { systemId = input.getSystemId(); } // Set the translet class name if not already set if (_className == null) { if (name != null) { setClassName(name); } else if (systemId != null && !systemId.isEmpty()) { <------ String clsName = Util.baseName(systemId); if (clsName != null && !clsName.isEmpty()) { setClassName(clsName); } } With this fix at https://git.openjdk.java.net/jdk/pull/6620, would you please backport it to JDK11 & JDK17 given the code there is at the same place? Thanks in advance. Thanks and Best Regards Cheng Jin

1 0

RFR: 8278185: Custom JRE cannot find non-ASCII named module inside
by Toshio Nakamura 09 Dec '21

09 Dec '21

Could you review this fix? Problem: Custom JRE generated by jlink cannot find non-ASCII named modules included inside the JRE. Cause and fix: If module or package name was composed by ASCII then non-ASCII characters, ImageStringsReader:stringFromByteBufferMatches() miscalculated the length of matched string. The first part of ASCII characters was missing. This patch corrected the value. Testing: tier1 and tier2 on Linux have no regression. I wasn't able to create an automate test for this issue. I appreciate any advice. ------------- Commit messages: - 8278185: Custom JRE cannot find non-ASCII named module inside Changes: https://git.openjdk.java.net/jdk/pull/6693/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6693&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278185 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6693.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6693/head:pull/6693 PR: https://git.openjdk.java.net/jdk/pull/6693

4 8

Re: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v20]
by Andrew Leonard 09 Dec '21

09 Dec '21

On Tue, 7 Dec 2021 19:25:05 GMT, Lance Andersen <lancea(a)openjdk.org> wrote: >> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision: >> >> 8276766: Enable jar and jmod to produce deterministic timestamped content >> >> Signed-off-by: Andrew Leonard <anleonar(a)redhat.com> > > Looks like the CSR has been approved. I have a mach5 run that should hopefully finish sooner rather than later and if that remains happy, I will approve the PR @LanceAndersen hi Lance, i've moved the new jar reproducible changes into a new test class in TestNG ReproducibleJar.java and added the Unix 2038 XFS special case Ready for your review please, if you're able to test on that mach5 machine again please? ------------- PR: https://git.openjdk.java.net/jdk/pull/6481

1 0

Re: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v20]
by Andrew Leonard 09 Dec '21

09 Dec '21

On Wed, 8 Dec 2021 16:51:05 GMT, Alan Bateman <alanb(a)openjdk.org> wrote: >> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision: >> >> 8276766: Enable jar and jmod to produce deterministic timestamped content >> >> Signed-off-by: Andrew Leonard <anleonar(a)redhat.com> > > src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 2339: > >> 2337: } else { >> 2338: e.setTime(origTime); >> 2339: } > > I think the 8 usages would be a bit clearer if renamed setZipEntryTime. Minor nit in the 2-arg setDate is that it's using 2-space indent instead of 4. thanks, fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/6481

1 0

RFR: JDK-8273146: Start of release updates for JDK 19
by Joe Darcy 09 Dec '21

09 Dec '21

The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates: JDK-8277512: Add SourceVersion.RELEASE_19 https://bugs.openjdk.java.net/browse/JDK-8277512 JDK-8277514: Add source 19 and target 19 to javac https://bugs.openjdk.java.net/browse/JDK-8277514 Clean local tier 1 test runs for langtools, jdk, and hotspot. ------------- Commit messages: - Add --release 18 information. Good tier1 test results. - JDK-8273146: Start of release updates for JDK 19 Changes: https://git.openjdk.java.net/jdk/pull/6493/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273146 Stats: 3242 lines in 67 files changed: 3202 ins; 0 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/6493.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493 PR: https://git.openjdk.java.net/jdk/pull/6493

7 19

RFR: 8277863: Deprecate sun.misc.Unsafe methods that return offsets
by Alan Bateman 07 Dec '21

07 Dec '21

Deprecate the sun.misc.Unsafe methods that return field offsets. These method are an impediment to possible future changes. Layout may not be fixed in the future, the VM should be allowed to re-layout dynamically based on patterns of usage. We also have the issue of libraries using these methods to get offsets (sometimes of classes with the same layout as JDK classes) so they can directly access the fields of privileged classes. It's untenable for libraries to rely on this going forward. The java.lang.invoke.VarHandle API (added in Java 9) provides a strongly typed reference to a variable that is a safe and a much better alternative to many cases that use these methods. Deprecating these method provides a gentle nudge in that directory. Once the Panama memory APIs are permanent then we can look at terminally deprecating and removing these methods, along with the accessors. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/6700/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6700&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277863 Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6700.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6700/head:pull/6700 PR: https://git.openjdk.java.net/jdk/pull/6700

3 8