October 2021 - core-libs-dev

RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos
by Alexey Bakhtin 01 Aug '22

01 Aug '22

Hi, Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.ht… This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is "tls-server-end-point" CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 Thank you Alexey ------------- Commit messages: - 8245527: LDAP Channel Binding support for Java GSS/Kerberos Changes: https://git.openjdk.java.net/jdk/pull/278/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=278&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245527 Stats: 536 lines in 10 files changed: 524 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/278/head:pull/278 PR: https://git.openjdk.java.net/jdk/pull/278

5 13

RFR: 4511638: Double.toString(double) sometimes produces incorrect results
by Raffaello Giulietti 07 Jun '22

07 Jun '22

Hello, here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. Greetings Raffaello ------------- Commit messages: - 4511638: Double.toString(double) sometimes produces incorrect results Changes: https://git.openjdk.java.net/jdk/pull/3402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4511638 Stats: 4237 lines in 15 files changed: 4116 ins; 54 del; 67 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402

21 100

RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS
by Henry Jen 31 May '22

31 May '22

…d on macOS This patch simply round up the specified stack size to multiple of the system page size. Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. ```code:java public class StackLeak { public int depth = 0; public void stackLeak() { depth++; stackLeak(); } public static void main(String[] args) { var test = new StackLeak(); try { test.stackLeak(); } catch (Throwable e) { System.out.println(test.depth); } } } ------------- Commit messages: - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS Changes: https://git.openjdk.java.net/jdk/pull/4256/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236569 Stats: 23 lines in 2 files changed: 21 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4256/head:pull/4256 PR: https://git.openjdk.java.net/jdk/pull/4256

7 25

Re: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64.
by gregcawthorne 30 Mar '22

30 Mar '22

On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne <github.com+73799211+gregcawthorne(a)openjdk.org> wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. greg.cawthorne(a)arm.com Should work ------------- PR: https://git.openjdk.java.net/jdk/pull/3510

2 1

RFR: 8257733: Move module-specific data from make to respective module
by Magnus Ihse Bursie 21 Mar '22

21 Mar '22

A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. ------------- Commit messages: - Update references in test - Step 2: Update references - First stage, move actual data files Changes: https://git.openjdk.java.net/jdk/pull/1611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257733 Stats: 78 lines in 1575 files changed: 3 ins; 1 del; 74 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611

13 79

RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
by Lance Andersen 09 Mar '22

09 Mar '22

Hi, Please review the fix for JDK-8256018 which addresses the issue that the update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly. The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the jck:api/java_util/zip,jck:api/java_util/jar continue to run clean. Best Lance ------------- Commit messages: - Adler32/CRC32/CRC32C missing reachabilityFence Changes: https://git.openjdk.java.net/jdk/pull/1149/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1149&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256018 Stats: 23 lines in 3 files changed: 16 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1149.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1149/head:pull/1149 PR: https://git.openjdk.java.net/jdk/pull/1149

4 6

JDK-17: Wndows jpackage destination directory not writable
by Sverre Moe 07 Mar '22

07 Mar '22

With JDK 17, jpackage fails to write to the destination directory on Windows. It worked fine with JDK 11 (with jpackage from JDK14) and Docker. Only happens on Windows docker. Running directly on WIndows it works with JDK 17. What has changed with jpackage that it no longer can write to the destination directory when running in Docker? Is it a regression/bug with jpackage? > Task :jpackageImage Caching disabled for task ':jpackageImage' because: Build cache is disabled Task ':jpackageImage' is not up-to-date because: Task has failed previously. input subdir: my-javafx-application Starting process 'command 'C:\Program Files\Java\jdk-17/bin/jpackage.exe''. Working directory: C:\Temp\my-javafx-application Command: C:\Program Files\Java\jdk-17/bin/jpackage.exe --type app-image --input C:\Temp\my-javafx-application\build\install\my-javafx-application\lib --main-jar my-javafx-application-1.8.0-SNAPSHOT.jar --main-class no.spacetec.dashboard.core.MeosDashboardLauncher --dest C:\Temp\my-javafx-application\build\native --name my-javafx-application --app-version 1.8.0 --runtime-image C:\Temp\my-javafx-application\build\runtime --resource-dir C:\Temp\my-javafx-application\build\package --java-options -Dfile.encoding=UTF-8 --java-options -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector --java-options -Dlog4j.configurationFactory=no.spacetec.dashboard.core.LoggingConfigurationFactory --verbose --description MEOS Dashboard Monitor and Control System GUI --vendor Kongsberg Space Ground Systems --icon C:\Temp\my-javafx-application\build/package/my-javafx-application.png Successfully started process 'command 'C:\Program Files\Java\jdk-17/bin/jpackage.exe'' [03:15:28.286] jdk.jpackage.internal.PackagerException: Destination directory C:\Temp\my-javafx-application\build\native is not writable at jdk.jpackage/jdk.jpackage.internal.IOUtils.writableOutputDir(IOUtils.java:266) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.createRoot(AppImageBundler.java:134) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.createAppBundle(AppImageBundler.java:163) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.execute(AppImageBundler.java:91) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:676) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)

3 5

RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException
by Joe Darcy 17 Feb '22

17 Feb '22

Make explicit illegal argument cases of Class.arrayType. Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 ------------- Commit messages: - Add test file. - Merge branch 'master' into 8268250 - 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException Changes: https://git.openjdk.java.net/jdk/pull/4382/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4382&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268250 Stats: 55 lines in 2 files changed: 55 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4382.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4382/head:pull/4382 PR: https://git.openjdk.java.net/jdk/pull/4382

5 13

RFR: 8274811: Remove superfluous use of boxing in java.base
by Andrey Turbanov 19 Jan '22

19 Jan '22

Usages of primitive types should be preferred and makes code easier to read. Similar cleanups: 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset ------------- Commit messages: - [PATCH] Remove superfluous use of boxing in java.base - [PATCH] Remove superfluous use of boxing in java.* modules - [PATCH] Remove superfluous use of boxing in java.* modules Changes: https://git.openjdk.java.net/jdk/pull/5481/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5481&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274811 Stats: 11 lines in 4 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5481.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5481/head:pull/5481 PR: https://git.openjdk.java.net/jdk/pull/5481

7 8

RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging
by Sergey Bylokhov 07 Jan '22

07 Jan '22

The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. This is the request to delete the usage of AppContext in the LogManager and related tests. Tested by tier1/tier2/tier3 and jdk_desktop tests. ------------- Commit messages: - Some tests deleted - Update the RootLevelInConfigFile test - Initial version of JDK-8273101 Changes: https://git.openjdk.java.net/jdk/pull/5326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5326&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273101 Stats: 1423 lines in 10 files changed: 0 ins; 1418 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5326/head:pull/5326 PR: https://git.openjdk.java.net/jdk/pull/5326

6 18