February 2021 - core-libs-dev

Re: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v2]
by Coleen Phillimore 05 Feb '21

05 Feb '21

On Fri, 5 Feb 2021 01:45:58 GMT, David Holmes <dholmes(a)openjdk.org> wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment and read NEVER field from System > > src/hotspot/share/classfile/dictionary.cpp line 145: > >> 143: #ifdef ASSERT >> 144: if (protection_domain == instance_klass()->protection_domain()) { >> 145: MutexLocker ml(ProtectionDomainSet_lock, Mutex::_no_safepoint_check_flag); > > By splitting the lock scope into two blocks you have lost the atomicity of the entire action in a debug build, and now you check a potentially different pd_set(). If the dictionary entry's class matches the protection domain, then it should never be added to the pd_set list. So it doesn't need to be locked to check that. It doesn't need atomicity. > src/hotspot/share/classfile/javaClasses.cpp line 4406: > >> 4404: } >> 4405: >> 4406: // This field means that a security manager is never installed so we can completely > > This field tells you whether a SM can be installed, and if not then you can completely ... updated with "we" > src/hotspot/share/classfile/systemDictionary.cpp line 503: > >> 501: } else { >> 502: log_debug(protectiondomain)("granted"); >> 503: } > > Did you intend leaving this in? Yes, why not? It's very useful in logging. > test/hotspot/jtreg/runtime/logging/ProtectionDomainVerificationTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights reserved. > > 2021 :) I had a bug in my fix-copyrights script. > test/hotspot/jtreg/runtime/logging/ProtectionDomainVerificationTest.java line 47: > >> 45: .shouldContain("[protectiondomain] Checking package access") >> 46: .shouldContain("[protectiondomain] pd set count = #") >> 47: .shouldHaveExitValue(0); > > Minor nit: checking the exit value first can be more informative in case of a crash. The patterns I see have that last. (?) ------------- PR: https://git.openjdk.java.net/jdk/pull/2410

2 2

Re: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v2]
by Coleen Phillimore 05 Feb '21

05 Feb '21

> This change does not call up to Java for checkPackageAccess if the security manager is NULL, but still saves the protection domain in the pd_set for that dictionary entry. If the option -Djava.security.manager=disallow is set, that means that there will never be a security manager and the JVM code can avoid saving the protection domains completely. > See the two functions java_lang_System::has_security_manager() and java_lang_System::allow_security_manager() for details. > Also deleted ProtectionDomainVerification because there's no use for this option. > > Tested with tier1 hotspot, jdk and langtools. > and tier2-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add comment and read NEVER field from System ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2410/files - new: https://git.openjdk.java.net/jdk/pull/2410/files/19ddd066..296d0adb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2410&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2410&range=00-01 Stats: 25 lines in 3 files changed: 17 ins; 7 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2410/head:pull/2410 PR: https://git.openjdk.java.net/jdk/pull/2410

1 0

Integrated: 8261109: [macOS] Remove disabled warning for JNF in make/autoconf/flags-cflags.m4
by Phil Race 04 Feb '21

04 Feb '21

On Thu, 4 Feb 2021 02:32:31 GMT, Phil Race <prr(a)openjdk.org> wrote: > remove un-needed disabling now JNF has gone .. This pull request has now been integrated. Changeset: 3bb6a3d2 Author: Phil Race <prr(a)openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/3bb6a3d2 Stats: 8 lines in 2 files changed: 0 ins; 8 del; 0 mod 8261109: [macOS] Remove disabled warning for JNF in make/autoconf/flags-cflags.m4 Reviewed-by: serb, ihse, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/2396

1 0

Re: RFR: 8261109: [macOS] Remove disabled warning for JNF in make/autoconf/flags-cflags.m4 [v2]
by Phil Race 04 Feb '21

04 Feb '21

> remove un-needed disabling now JNF has gone .. Phil Race has updated the pull request incrementally with one additional commit since the last revision: Remove condition that should have been fixed as part of 8257858 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2396/files - new: https://git.openjdk.java.net/jdk/pull/2396/files/34dcbfb1..93fd193f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2396&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2396&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2396/head:pull/2396 PR: https://git.openjdk.java.net/jdk/pull/2396

2 1

Re: RFR: 8261109: [macOS] Remove disabled warning for JNF in make/autoconf/flags-cflags.m4 [v2]
by Phil Race 04 Feb '21

04 Feb '21

On Thu, 4 Feb 2021 11:42:48 GMT, Magnus Ihse Bursie <ihse(a)openjdk.org> wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove condition that should have been fixed as part of 8257858 > > Marked as reviewed by ihse (Reviewer). Magnus pointed out a condition that I think should have been removed in the fix for 8257858 : Remove JNF dependency from libosxsecurity/KeystoreImpl.m since its a build related change too, and I've verified that after removing it we still build, I am rolling it in here, if that's OK with folks ------------- PR: https://git.openjdk.java.net/jdk/pull/2396

1 0

RFR: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math
by Raffaello Giulietti 04 Feb '21

04 Feb '21

Hello Joe, in the javadoc of acos() I think you should replace the mathematically incorrect * <li>If the argument is {@linkplain Double#isInfinite infinite}, with something like * <li>If the argument is zero, Also, in some places pi/2 is described as <i>pi</i>/2, rounded, which is more open to interpretation, depending on what is meant by "rounded" (which mode? Granted, default is "to closest"), whereas in other places it is described as the value closest to <i>pi</i>/2 which is preferable, as it is unambiguous. Greetings Raffaello > On Thu, 4 Feb 2021 02:08:12 GMT, Joe Darcy <darcy at openjdk.org> wrote: > >> Recent revisions of the IEEE 754 floating-point standard have added guidance on how typical math library methods (sin, cos, tan, etc.) should behave in terms of their general quality of implementation as well as on special values. >> >> Other than the pow methods, for the recommended operations listed by IEEE 754 that the Java math library already includes, the special cases that are specified by Java are the same as those specified by IEEE 754, except for the pow method. IEEE 754 calls out some special cases not explicitly listed in the Java specs. This changeset adds those special cases to the spec and adds tests of the the special cases if not already present. >> >> If method "Foo" already had a regression test, new cases were added it it. Otherwise, a new test was added to cover the special cases of several methods. >> >> There is no intention at the moment to change the behavior of pow to align with IEEE 754. > > PS After the wording for the Math class is finalized, I'll add analogous wording to the StrictMath class and run a CSR. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2395 >

2 1

RFR: JDK-8259927: Windows jpackage installer issues
by Andy Herrick 04 Feb '21

04 Feb '21

Remove lines in WixSourceBuilder that adds directive to rm-rf the parent dir(s) of the install-dir. These directories get removed anyway if they are empty without these lines, and should be left alone if not empty after removing the install dir itself. ------------- Commit messages: - JDK-8259927: Windows jpackage installer issues Changes: https://git.openjdk.java.net/jdk/pull/2382/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2382&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259927 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2382.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2382/head:pull/2382 PR: https://git.openjdk.java.net/jdk/pull/2382

4 5

RFR: 8260356: (tz) Upgrade time-zone data to tzdata2021a
by Kiran Sidhartha Ravikumar 04 Feb '21

04 Feb '21

Hi Guys, Please review integrating tzdata2021a to JDK. JBS: https://bugs.openjdk.java.net/browse/JDK-8260356 The fix has passed the regression and JCK tests. More information can be viewed at - https://mm.icann.org/pipermail/tz-announce/2021-January/000065.html Thanks, Kiran ------------- Commit messages: - 8260356: (tz) Upgrade time-zone data to tzdata2021a Changes: https://git.openjdk.java.net/jdk/pull/2359/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2359&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260356 Stats: 12 lines in 3 files changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2359.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2359/head:pull/2359 PR: https://git.openjdk.java.net/jdk/pull/2359

2 2

RFR: JDK-8260335: [macos] Running app using relative path causes problems
by Andy Herrick 04 Feb '21

04 Feb '21

Fixing FileUtils.dirname() to skip over "/.". ------------- Commit messages: - JDK-8260335: [macos] Running app using relative path causes problems on MacOS Changes: https://git.openjdk.java.net/jdk/pull/2260/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2260&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260335 Stats: 10 lines in 1 file changed: 8 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2260/head:pull/2260 PR: https://git.openjdk.java.net/jdk/pull/2260

4 6

RFR: 8261149: Initial nroff manpage update for JDK 17
by Magnus Ihse Bursie 04 Feb '21

04 Feb '21

We need to regenerate the exported nroff man pages to include the proper version string. This will also bring in some recent textual updates to the man pages. ------------- Commit messages: - 8261149: Initial nroff manpage update for JDK 17 Changes: https://git.openjdk.java.net/jdk/pull/2402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2402&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261149 Stats: 49 lines in 28 files changed: 0 ins; 21 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/2402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2402/head:pull/2402 PR: https://git.openjdk.java.net/jdk/pull/2402

3 3