Re: RFR: 5023614: UUID needs methods to get most/leastSigBits and write to DataOutput
On Mon, 14 Dec 2020 20:18:01 GMT, Roger Riggs wrote: >> Made byte constructor public and changed the length assertion to an >> `IllegalArgumentException`, added a `getBytes` method that allows users to >> retrieve the raw bytes of the UUID, and created a new private constructor >> with an optimized construction for byte arrays that can set the version as >> desired and the variant to RFC 4122. Also changed the existing static >> factory methods to use the new constructor and removed the duplicate code >> from them where the variant and version is being set. >> >> Report >> [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks >> for more than what I provided and with different names. However, I believe >> that there is no value in providing methods to deal with `DataInput` and >> `DataOutput` because they would only encapsulate single method calls that >> the caller can directly write as well (e.g. `output.write(uuid.getBytes())` >> vs `uuid.write(output)`). Hence, I consider this change to satisfy the >> feature request. > > Requested feedback on the API addition/modifications: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072530.html Active - PR: https://git.openjdk.java.net/jdk/pull/1465
RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in si…
The jarsigner tool currently provides warning associated with the signer’s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer’s cert chain to warn if CA certs use weak algorithms. - Commit messages: - 8259401: Add checking to jarsigner to warn weak algorithms used in signer’s cert chain Changes: https://git.openjdk.java.net/jdk/pull/2042/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2042=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259401 Stats: 125 lines in 2 files changed: 124 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2042.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2042/head:pull/2042 PR: https://git.openjdk.java.net/jdk/pull/2042
Integrated: Merge jdk16
On Mon, 11 Jan 2021 22:04:16 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: b378f54d Author:Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/b378f54d Stats: 139 lines in 12 files changed: 116 ins; 2 del; 21 mod Merge - PR: https://git.openjdk.java.net/jdk/pull/2040
Re: RFR: Merge jdk16 [v2]
> Forwardport JDK 16 -> JDK 17 Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Merge - Changes: - all: https://git.openjdk.java.net/jdk/pull/2040/files - new: https://git.openjdk.java.net/jdk/pull/2040/files/e55da33b..69dad8ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2040=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2040=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2040.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2040/head:pull/2040 PR: https://git.openjdk.java.net/jdk/pull/2040
Integrated: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov wrote: > 8258422: Cleanup unnecessary null comparison before instanceof check in > java.base This pull request has now been integrated. Changeset: 022bc9f0 Author:Andrey Turbanov Committer: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/022bc9f0 Stats: 82 lines in 22 files changed: 1 ins; 13 del; 68 mod 8258422: Cleanup unnecessary null comparison before instanceof check in java.base Reviewed-by: chegar, aefimov - PR: https://git.openjdk.java.net/jdk/pull/20
Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
On Mon, 11 Jan 2021 17:12:24 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, >> This PR is ready for integration - `JDK-8258657` has been resolved. >> You can proceed with issuing `integrate` bot command. Then I will `sponsor` >> it. >> But before that, I would like to ask if you would like to take on board the >> changes to `HttpClientImpl`? Alternatively, I can follow it up separately >> and reapply the backed-out change under different bugID. > > @AlekseiEfimov `HttpClientImpl` is not in `java.base` module. So I think it's > better to not touch it under this PR. To double check that docs build will be stable after integration the following actions have been performed: - The pull request branch was locally synced-up with the latest changes from `master` (`JDK-8258657` is part of them) - Verified that local `docs-reference-api-javadoc` build completes successfully - PR: https://git.openjdk.java.net/jdk/pull/20
Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
On Mon, 11 Jan 2021 23:29:53 GMT, Aleksei Efimov wrote: >> @AlekseiEfimov `HttpClientImpl` is not in `java.base` module. So I think >> it's better to not touch it under this PR. > > To double check that docs build will be stable after integration the > following actions have been performed: > - The pull request branch was locally synced-up with the latest changes from > `master` (`JDK-8258657` is part of them) > - Verified that local `docs-reference-api-javadoc` build completes > successfully sponsor - PR: https://git.openjdk.java.net/jdk/pull/20
Re: [jdk16] RFR: 8259298: broken link in Stream::toList spec
On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks wrote: > Just fixing a broken link. Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk16/pull/106
Re: [jdk16] RFR: 8259298: broken link in Stream::toList spec
On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks wrote: > Just fixing a broken link. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk16/pull/106
Re: [jdk16] RFR: 8259298: broken link in Stream::toList spec
On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks wrote: > Just fixing a broken link. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk16/pull/106
Re: [jdk16] RFR: 8259298: broken link in Stream::toList spec
On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks wrote: > Just fixing a broken link. Marked as reviewed by bchristi (Reviewer). - PR: https://git.openjdk.java.net/jdk16/pull/106
[jdk16] RFR: 8259298: broken link in Stream::toList spec
Just fixing a broken link. - Commit messages: - 8259298: broken link in Stream::toList spec Changes: https://git.openjdk.java.net/jdk16/pull/106/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16=106=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259298 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/106.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/106/head:pull/106 PR: https://git.openjdk.java.net/jdk16/pull/106
RFR: Merge jdk16
Forwardport JDK 16 -> JDK 17 - Commit messages: - Merge - 8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing - 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl - 8259043: More Zero architectures need linkage with libatomic - 8259429: Update reference to README.md - 8259014: (so) ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress) will have unknown user and group owner (win) The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk=2040=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk=2040=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2040/files Stats: 140 lines in 12 files changed: 117 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2040.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2040/head:pull/2040 PR: https://git.openjdk.java.net/jdk/pull/2040
Integrated: 8259528: Broken Link for [java.text.Normalizer.Form]
On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato wrote: > Please review this simple doc fix. This pull request has now been integrated. Changeset: cd73939b Author:Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/cd73939b Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8259528: Broken Link for [java.text.Normalizer.Form] Reviewed-by: lancea, joehw, iris - PR: https://git.openjdk.java.net/jdk/pull/2028
Re: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes [v2]
On Fri, 8 Jan 2021 21:30:14 GMT, Martin Balao wrote: >> As described in JDK-8259319 [1], this fix proposal is to set proper access >> permissions so the SunPKCS11 provider can create instances of SunJCE classes >> when a Security Manager is installed and the fallback scheme is used. >> >> No regressions found in jdk/sun/security/pkcs11 tests category. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 > > Martin Balao has updated the pull request incrementally with two additional > commits since the last revision: > > - Limit P11Util::getProvider privileged access to the required > 'accessClassInPackage' RuntimePermission only. > - New line character inserted at the end of IllegalPackageAccess.java test > file Marked as reviewed by mullan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1961
Re: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato wrote: > Please review this simple doc fix. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2028
Re: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
On Mon, 11 Jan 2021 17:35:58 GMT, Joe Wang wrote:
>> Please review this simple doc fix.
>
> src/java.base/share/classes/java/text/Normalizer.java line 48:
>
>> 46: * The {@code normalize} method supports the standard normalization forms
>> 47: * described in
>> 48: * https://www.unicode.org/reports/tr15/;>
>
> This links to the latest version. Will the Normalizer always keep up with
> version changes? Or is it a specific version with which it complies (e.g. the
> latest version 13, previous 12), or is the version change irrelevant to this
> class?
Normalizer (namely the table) is updated as part of the Unicode upgrade, so it
should point to the latest. I believe the current one pointing to a specific
revision is simply an editorial error.
-
PR: https://git.openjdk.java.net/jdk/pull/2028
Re: TreeMap in JDK15 deviates from spec
This is a regression, because Java 11 shows "default" twice for the
TreeMap, whereas Java 15 shows "null" twice.
On 11/01/2021 19:05, Phil Smith wrote:
Hello, I submitted bug report 9068554 recently, but I consider this a
pretty big issue and I'd like for this not to get lost in triage.
With JDK-8176894, a specialized implementation for computeIfAbsent was
added to TreeMap, however it doesn't handle null values correctly.
Spec states a mapping to null is equivalent to no mapping being
present, however code will `return t.value;` without checking that
value. The interface default, for reference, looks like `if ((v =
get(key)) == null)`.
A simple repro follows
TreeMap treemap = new TreeMap();
treemap.put("a", null);
System.out.println(treemap.computeIfAbsent("a", key -> "default"));
System.out.println(treemap.get("a"));
HashMap hashmap = new HashMap();
hashmap.put("a", null);
System.out.println(hashmap.computeIfAbsent("a", key -> "default"));
System.out.println(hashmap.get("a"));
Phil
Re: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato wrote: > Please review this simple doc fix. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2028
Re: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato wrote:
> Please review this simple doc fix.
Oops, forgot to submit the review ;-)
src/java.base/share/classes/java/text/Normalizer.java line 48:
> 46: * The {@code normalize} method supports the standard normalization forms
> 47: * described in
> 48: * https://www.unicode.org/reports/tr15/;>
This links to the latest version. Will the Normalizer always keep up with
version changes? Or is it a specific version with which it complies (e.g. the
latest version 13, previous 12), or is the version change irrelevant to this
class?
-
PR: https://git.openjdk.java.net/jdk/pull/2028
Re: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes [v2]
On Fri, 8 Jan 2021 21:30:14 GMT, Martin Balao wrote: >> As described in JDK-8259319 [1], this fix proposal is to set proper access >> permissions so the SunPKCS11 provider can create instances of SunJCE classes >> when a Security Manager is installed and the fallback scheme is used. >> >> No regressions found in jdk/sun/security/pkcs11 tests category. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 > > Martin Balao has updated the pull request incrementally with two additional > commits since the last revision: > > - Limit P11Util::getProvider privileged access to the required > 'accessClassInPackage' RuntimePermission only. > - New line character inserted at the end of IllegalPackageAccess.java test > file Changes look good. - Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1961
TreeMap in JDK15 deviates from spec
Hello, I submitted bug report 9068554 recently, but I consider this a
pretty big issue and I'd like for this not to get lost in triage.
With JDK-8176894, a specialized implementation for computeIfAbsent was
added to TreeMap, however it doesn't handle null values correctly.
Spec states a mapping to null is equivalent to no mapping being
present, however code will `return t.value;` without checking that
value. The interface default, for reference, looks like `if ((v =
get(key)) == null)`.
A simple repro follows
TreeMap treemap = new TreeMap();
treemap.put("a", null);
System.out.println(treemap.computeIfAbsent("a", key -> "default"));
System.out.println(treemap.get("a"));
HashMap hashmap = new HashMap();
hashmap.put("a", null);
System.out.println(hashmap.computeIfAbsent("a", key -> "default"));
System.out.println(hashmap.get("a"));
Phil
Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
On Mon, 11 Jan 2021 16:57:00 GMT, Aleksei Efimov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in >> java.base > > Hi @turbanoff, > This PR is ready for integration - `JDK-8258657` has been resolved. > You can proceed with issuing `integrate` bot command. Then I will `sponsor` > it. > But before that, I would like to ask if you would like to take on board the > changes to `HttpClientImpl`? Alternatively, I can follow it up separately and > reapply the backed-out change under different bugID. @AlekseiEfimov `HttpClientImpl` is not in `java.base` module. So I think it's better to not touch it under this PR. - PR: https://git.openjdk.java.net/jdk/pull/20
Re: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato wrote: > Please review this simple doc fix. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2028
RFR: 8259528: Broken Link for [java.text.Normalizer.Form]
Please review this simple doc fix. - Commit messages: - 8259528: Broken Link for [java.text.Normalizer.Form] Changes: https://git.openjdk.java.net/jdk/pull/2028/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2028=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259528 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2028.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2028/head:pull/2028 PR: https://git.openjdk.java.net/jdk/pull/2028
Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov wrote: > 8258422: Cleanup unnecessary null comparison before instanceof check in > java.base Hi @turbanoff, This PR is ready for integration - `JDK-8258657` has been resolved. You can proceed with issuing `integrate` bot command. Then I will `sponsor` it. But before that, I would like to ask if you would like to take on board the changes to `HttpClientImpl`? Alternatively, I can follow it up separately and reapply the backed-out change under different bugID. - PR: https://git.openjdk.java.net/jdk/pull/20
[jdk16] Integrated: 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl
On Wed, 6 Jan 2021 16:10:12 GMT, Maurizio Cimadamore wrote: > This patch tweaks `MemorySegment::mapFile` so that it will throw > `IllegalArgumentException` whenever the path to be mapped is associated with > a custom file system provider. > > The check in the implementation is heavily borrowed by what > `UnixDomainSocketAddress::of(Path)` does (thanks Alan for the tip!). Not only > we have to check if file system is the default one, but also if the default > FS belongs to java.base (since that can be overridden). > > The test simply check that paths coming from the (internal) JRT file system > are not supported by the factory. This pull request has now been integrated. Changeset: d60a937e Author:Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk16/commit/d60a937e Stats: 20 lines in 3 files changed: 14 ins; 1 del; 5 mod 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl Reviewed-by: chegar, alanb, uschindler - PR: https://git.openjdk.java.net/jdk16/pull/90
Withdrawn: 8228988: AnnotationParser throws NullPointerException on incompatible member type
On Sun, 18 Oct 2020 22:21:37 GMT, Rafael Winterhalter wrote: > If an annotation member type is changed in an incompatible manner, the > `AnnotationParser` currently throws a `NullPointerException` if: > > - An enumeration-typed member is changed to be an annotation type or a > `Class` type. > - An annotation type is changed to be a non-annotation type. > > This patch creates `AnnotationTypeMismatchExceptionProxy` to give users a > better error message and to delay the exception to the time where the > annotation member is attempted to be accessed. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/725
Re: RFR: JDK-8259395 Patching automatic module with additional packages re-creates module without "requires java.base" [v3]
On Mon, 11 Jan 2021 14:13:47 GMT, Alan Bateman wrote: > > > This issue requires a Reviewer from someone working in this area. Please do > not sponsor or integrate until that review has been done. Ok, increased the number of required reviewers to 2. Hope that was the right move, as I don't see any other way to undo /integrate. - PR: https://git.openjdk.java.net/jdk/pull/2000
Re: RFR: JDK-8259395 Patching automatic module with additional packages re-creates module without "requires java.base" [v3]
On Mon, 11 Jan 2021 14:11:15 GMT, Johannes Kuhn wrote: >> Marked as reviewed by attila (Reviewer). > > Thanks @szegedi for reviewing this. This issue requires a Reviewer from someone working in this area. Please do not sponsor or integrate until that review has been done. - PR: https://git.openjdk.java.net/jdk/pull/2000
Re: RFR: JDK-8259395 Patching automatic module with additional packages re-creates module without "requires java.base" [v3]
On Mon, 11 Jan 2021 14:06:12 GMT, Attila Szegedi wrote: >> Johannes Kuhn has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add a missing pesky newline. > > Marked as reviewed by attila (Reviewer). Thanks @szegedi for reviewing this. - PR: https://git.openjdk.java.net/jdk/pull/2000
Re: RFR: JDK-8259395 Patching automatic module with additional packages re-creates module without "requires java.base" [v3]
On Mon, 11 Jan 2021 05:12:11 GMT, Johannes Kuhn wrote: >> Simple fix - one line change: >> https://openjdk.github.io/cr/?repo=jdk=2000=00#sdiff-0. >> >> Most of the changes come from an additional test that fails without this fix: >> >> Error: Unable to load main class somelib.test.TestMain in module somelib >> java.lang.IllegalAccessError: superclass access check failed: class >> somelib.test.TestMain (in module somelib) cannot access class >> java.lang.Object (in module java.base) because module java.base does not >> export java.lang to module somelib >> >> As described in JDK-8259395. >> You can view the output of the test without patch here: >> https://github.com/DasBrain/jdk/runs/1668078245 >> >> Thanks to @AlanBateman for pointing out the right fix. > > Johannes Kuhn has updated the pull request incrementally with one additional > commit since the last revision: > > Add a missing pesky newline. Marked as reviewed by attila (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2000
Integrated: JDK-8250768: javac should be adapted to changes in JEP 12
On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote: > This is an update to javac and javadoc, to introduce support for Preview > APIs, and generally improve javac and javadoc behavior to more closely adhere > to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only > preview language features, and APIs associated with preview language > features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", > which should be true for reflective Preview APIs, false otherwise. This > replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described > in the JEP 12. E.g. the module that declares the preview API is free to use > it without warnings > * improving error/warning messages. Please see [1] for a list of > cases/examples. > * class files are only marked as preview if they are using a preview > feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package > (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in > the source files. javadoc will auto-generate a note for @PreviewFeature > elements, see e.g. [2] and [3] (non-reflective and reflective API, > respectively). A summary of preview elements is also provided [4]. Existing > uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses > of Preview elements, and for declaring elements using preview language > features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 This pull request has now been integrated. Changeset: 23548821 Author:Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/23548821 Stats: 3802 lines in 133 files changed: 2724 ins; 695 del; 383 mod 8250768: javac should be adapted to changes in JEP 12 Reviewed-by: mcimadamore, erikj, jjg, ihse - PR: https://git.openjdk.java.net/jdk/pull/703
Re: RFR: 8257733: Move module-specific data from make to respective module [v4]
On Mon, 4 Jan 2021 21:20:53 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due >> to a merge or a rebase. The incremental webrev excludes the unrelated >> changes brought in by the merge/rebase. The pull request contains eight >> additional commits since the last revision: >> >> - Update comment refering to "make" dir >> - Move new symbols to jdk.compiler >> - Merge branch 'master' into shuffle-data >> - Move macosxicons from share to macosx >> - Move to share/data, and move jdwp.spec to java.se >> - Update references in test >> - Step 2: Update references >> - First stage, move actual data files > > Marked as reviewed by prr (Reviewer). This PR is not stale; it's just still waiting for input from @AlanBateman. - PR: https://git.openjdk.java.net/jdk/pull/1611
Withdrawn: 8253280: Use class name as class loading lock
On Thu, 10 Sep 2020 05:25:43 GMT, Robert LU
wrote:
> When many thread try to load same class, the thread will stuck on
> `ClassLoader.loadClass`.
> At current jdk, the stacktrace by example program is:
> "Thread-1" prio=5 Id=12 BLOCKED on java.lang.Object@2e817b38 owned by
> "Thread-0" Id=11
> at
> java.base@15/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:616)
> - blocked on java.lang.Object@2e817b38
> at
> java.base@15/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:604)
> at
> java.base@15/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:168)
> at java.base@15/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> at app//Main.test(Main.java:19)
> at app//Main$$Lambda$2/0x000800b8c468.run(Unknown Source)
> at java.base@15/java.lang.Thread.run(Thread.java:832)
> There is no way to get which class stuck the thread.
>
> **After this patch, the stacktrace will be**:
> "Thread-1" prio=5 Id=13 BLOCKED on java.lang.String@724af044 owned by
> "Thread-0" Id=12
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:646)
> - blocked on java.lang.String@724af044 val="java.lang.String"
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:634)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
> at app//Main2.test(Main2.java:19)
> at app//Main2$$Lambda$37/0x0001000c2a20.run(Unknown Source)
> at java.base/java.lang.Thread.run(Thread.java:831)
> That is, user will know which class stuck the thread, in this example, the
> class is `java.lang.String`. It's helpful for troubleshooting.
>
> The example program:
> Before patch:
>
> Main.java
>
> // Main.java
> import java.io.PrintStream;
> import java.lang.management.*;
>
> public final class Main {
> private synchronized static void test1() {
> while (true) {
> try {
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
>
> private static void test() {
> while (true) {
> try {
> Main.class.getClassLoader().loadClass("java.lang.String");
> } catch (ClassNotFoundException e) {
> }
> }
> }
>
> public static void main(String[] args) throws InterruptedException,
> NoSuchFieldException, IllegalAccessException {
> new Thread(Main::test).start();
> new Thread(Main::test).start();
> new Thread(Main::test).start();
> new Thread(Main::test).start();
> new Thread(Main::test).start();
>
> while (true) {
> Thread.sleep(1000);
> ThreadMXBean bean = ManagementFactory.getThreadMXBean();
> ThreadInfo[] infos = bean.dumpAllThreads(true, true);
> for (ThreadInfo info : infos) {
> System.out.println(printThreadInfo(info));
> }
> }
> }
>
> private static String printThreadInfo(ThreadInfo threadInfo) {
> StringBuilder sb = new StringBuilder(""" + threadInfo.getThreadName()
> + """ +
> (threadInfo.isDaemon() ? " daemon" : "") +
> " prio=" + threadInfo.getPriority() +
> " Id=" + threadInfo.getThreadId() + " " +
> threadInfo.getThreadState());
> if (threadInfo.getLockName() != null) {
> sb.append(" on " + threadInfo.getLockName());
> }
> if (threadInfo.getLockOwnerName() != null) {
> sb.append(" owned by "" + threadInfo.getLockOwnerName() +
> "" Id=" + threadInfo.getLockOwnerId());
> }
> if (threadInfo.isSuspended()) {
> sb.append(" (suspended)");
> }
> if (threadInfo.isInNative()) {
> sb.append(" (in native)");
> }
> sb.append('\n');
> int i = 0;
> StackTraceElement[] stackTrace = threadInfo.getStackTrace();
> for (; i < stackTrace.length; i++) {
> StackTraceElement ste = stackTrace[i];
> sb.append("\tat " + ste.toString());
> sb.append('\n');
> if (i == 0 && threadInfo.getLockInfo() != null) {
> Thread.State ts = threadInfo.getThreadState();
> switch (ts) {
> case BLOCKED:
> sb.append("\t- blocked on " +
> printLockInfo(threadInfo.getLockInfo()));
> sb.append('\n');
> break;
> case WAITING:
> sb.append("\t- waiting on " +
> printLockInfo(threadInfo.getLockInfo()));
>
