From akashche at redhat.com Sun Mar 1 12:03:00 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Sun, 1 Mar 2020 12:03:00 +0000 Subject: [11u] RFR: 8232854: URLClassLoader.close() doesn't close cached JAR file on Windows when load() fails Message-ID: <361f077a-6d89-6de4-c613-2fed37a4c269@redhat.com> Hi, Please review the fix to JDK-8232854 for 11u: Jira issue: https://bugs.openjdk.java.net/browse/JDK-8232854 Webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8232854/webrev.00/ Patch is implemented based on a test code included with the Jira issue. It fixes the case, when URLClassLoader is created with URL, that stars with "jar:file:" and ends with non-root path inside JAR like "foo.jar!/somedir/". Codepath in this case includes URLClassPath.Loader class, that requires special handling when resources are loaded from a JAR file. Issue with closing JAR file (on classloader close) on this codepath was previously fixed in JDK-6896088: Jira issue: https://bugs.openjdk.java.net/browse/JDK-6896088 Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/3af394bb6f59 This fix is complementary to 6896088, it is filling the "jarfile" field in URLClassPath.Loader class (to be able to close the JAR file later) in case, when requested resource failed to be loaded from this JAR. Note, that getJarFile() on URLConnection to original resource cannot be used in this case, because this method checks that requested resource is valid. URLConnection to the root URL in this JAR is used instead. There probably exist more elegant solutions to this problem. This patch is fix-only and should not affect any existing logic in URLClassPath. Test included with this fix is similar to java/net/URLClassLoader/B6896088.java test. It uses specific JAR structure (with a classfile inside "somedir" directory that is not a part of class package) and checks JAR file closing after both successful and failed load attempts. Test fails on Windows without this patch, on Linux it always passes. -- -Alex From Alan.Bateman at oracle.com Sun Mar 1 14:26:46 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 1 Mar 2020 14:26:46 +0000 Subject: [11u] RFR: 8232854: URLClassLoader.close() doesn't close cached JAR file on Windows when load() fails In-Reply-To: <361f077a-6d89-6de4-c613-2fed37a4c269@redhat.com> References: <361f077a-6d89-6de4-c613-2fed37a4c269@redhat.com> Message-ID: On 01/03/2020 12:03, Alex Kashchenko wrote: > Hi, > > Please review the fix to JDK-8232854 for 11u: > > Jira issue: https://bugs.openjdk.java.net/browse/JDK-8232854 This issue has not been fixed in the main line (jdk/jdk) yet. It may be that the eventual fix will be in the URL protocol handler. Several options will need to be explored and I suspect it will take time to agree the right solution for this issue. I realize this doesn't help with a point fix for 11u. Maybe you have cycles to work the options to fix the underlying issue in the main line? -Alan. From claes.redestad at oracle.com Sun Mar 1 18:19:43 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 1 Mar 2020 19:19:43 +0100 Subject: RFR: 8196334: Optimize UUID#fromString In-Reply-To: <412177f3-9496-a331-1e98-cffbb3fba562@oracle.com> References: <4e866637-0ad8-1999-d70a-3635d7ec0f0f@oracle.com> <8f515c5c-c3a5-fda5-2753-e10fedc2a6c4@oracle.com> <412177f3-9496-a331-1e98-cffbb3fba562@oracle.com> Message-ID: <5bc56926-32eb-28a9-1e54-3b8946051f7c@oracle.com> On 2020-02-29 00:58, Ivan Gerasimov wrote: > Sounds reasonable. > > I think the current proposal is clearly a progress, so it looks good. Ok! After discussing it a bit offline, Andriy and I would like to simplify the dash-checking code a bit to make it more clear, as there seems to be no obvious performance drawback of simplifying to (ch1 == '-' && ...). New webrev: http://cr.openjdk.java.net/~redestad/8196334/open.01/ Thanks! /Claes From Alan.Bateman at oracle.com Sun Mar 1 19:41:28 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 1 Mar 2020 19:41:28 +0000 Subject: RFR: 8196334: Optimize UUID#fromString In-Reply-To: <5bc56926-32eb-28a9-1e54-3b8946051f7c@oracle.com> References: <4e866637-0ad8-1999-d70a-3635d7ec0f0f@oracle.com> <8f515c5c-c3a5-fda5-2753-e10fedc2a6c4@oracle.com> <412177f3-9496-a331-1e98-cffbb3fba562@oracle.com> <5bc56926-32eb-28a9-1e54-3b8946051f7c@oracle.com> Message-ID: On 01/03/2020 18:19, Claes Redestad wrote: > : > > After discussing it a bit offline, Andriy and I would like to simplify > the dash-checking code a bit to make it more clear, as there seems to be > no obvious performance drawback of simplifying to (ch1 == '-' && ...). > > New webrev: http://cr.openjdk.java.net/~redestad/8196334/open.01/ > This looks good and keeping the old code for the size != 36 case gets around the compatibility issues discussed here with previous attempts to improve it. A few minor nits: The effective TODO to optimize Character.digit in the declaration of NIBBLES seems like something for JIRA, not a comment here. I assume the fully qualified class name for java.util.Arrays is because this patch was initially developed outside of java.util? Can parse4Nibbles be moved to after the declaration of NIBBLES to avoid it being in the middle of the two fromString methods? -Alan. From christoph.langer at sap.com Sun Mar 1 20:16:43 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 1 Mar 2020 20:16:43 +0000 Subject: RFR: removing dead code from jar tool In-Reply-To: <994D1E5F-06CA-4489-A662-F4470FD87F24@oracle.com> References: <62B599B2-5F5C-454E-823A-64AAF93D2817@oracle.com> <994D1E5F-06CA-4489-A662-F4470FD87F24@oracle.com> Message-ID: Hi Adam, Lance, as you've already figured out, attachments sent out to the mailing list will be removed. So it's important to generate webrevs and link to it or, for smaller patches, inline it. ?? Also, the RFR subject is missing a bug ID. From the URL to the webrev I take the bug ID is JDK-8230117. Going to JBS it seems that the bug is confidential. Could you please either open up the bug before pushing or alternatively, create a new, public bug to push this against? Thanks Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Lance Andersen > Sent: Freitag, 28. Februar 2020 18:04 > To: Sean Mullan > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR: removing dead code from jar tool > > sigh it is being removed it appears by the mail server > > I placed a copy here: http://cr.openjdk.java.net/~lancea/JDK-8230117.patch > > > > On Feb 28, 2020, at 12:00 PM, Lance Andersen > wrote: > > > > Here it is again > > > >> On Feb 28, 2020, at 11:07 AM, Sean Mullan > wrote: > >> > >> I think you forgot to attach the patch. > >> > >> --Sean > >> > >> On 2/28/20 2:28 AM, Adam Sotona wrote: > >>> Hi, > >>> I would like to ask for review of the attached patch removing dead code > from jar tool > >>> Class files sun.tools.jar.Manifest and sun.tools.jar.SignatureFile appear > to be dead code and should be removed. > >>> Build with the patch passes all Tier1, Tier2 and Tier3 tests. > >>> Thank you, > >>> Adam > > > > > > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > > Oracle Java Engineering > > 1 Network Drive > > Burlington, MA 01803 > > Lance.Andersen at oracle.com > > > > > > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > From christoph.langer at sap.com Sun Mar 1 20:21:51 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 1 Mar 2020 20:21:51 +0000 Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly In-Reply-To: References: Message-ID: Hi Volker, this looks good to me. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Volker Simonis > Sent: Freitag, 28. Februar 2020 19:48 > To: Java Core Libs > Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly > > Hi, > > can I please have a review for this small test fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235/ > https://bugs.openjdk.java.net/browse/JDK-8240235 > > JarUtils.updateJar() and JarUtils.updateJarFile() update jar files by > reading JarEntry-s from a source jar file and writing these exact > JarEntry-s to the destination jar file followed be the inflated and > re-deflated data belonging to this entry. > > This approach is not correct, because JarEntry contains both, the > compressed and uncompressed size of the corresponding entry. But the > original Defalter which initially compressed that entry can be either > different from the current one or it might have used a different > compression level compared to the current Deflater which re-deflates > the entry data. > > When the newly created entry is closed, the new compressed size will > be checked against the original compressed size if that was recorded > in the JarEntry and an exception will be thrown, when they differ: > > java.util.zip.ZipException: invalid entry compressed size (expected > 237 but got 238 bytes) > at > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:26 > 7) > at > java.base/java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java > :192) > at > java.base/java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java > :108) > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:294) > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:252) > at HasUnsignedEntryTest.start(HasUnsignedEntryTest.java:77) > at HasUnsignedEntryTest.main(HasUnsignedEntryTest.java:44) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet > hodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega > tingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp > er.java:127) > at java.base/java.lang.Thread.run(Thread.java:832) > Suppressed: java.util.zip.ZipException: invalid entry > compressed size (expected 237 but got 238 bytes) > at > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:26 > 7) > at > java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) > at > java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.ja > va:237) > at > java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:280) > > The fix is trivial. Instead of copying the JarEntry-s verbatim to the > output stream, simply write newly created JarEntry-s to the output > stream which only contain the entry name. This is also the way how > this is handled by the jar tool, when it updates jar files. > > Thank you and best regards, > Volker From claes.redestad at oracle.com Sun Mar 1 21:05:17 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 1 Mar 2020 22:05:17 +0100 Subject: RFR: 8196334: Optimize UUID#fromString In-Reply-To: References: <4e866637-0ad8-1999-d70a-3635d7ec0f0f@oracle.com> <8f515c5c-c3a5-fda5-2753-e10fedc2a6c4@oracle.com> <412177f3-9496-a331-1e98-cffbb3fba562@oracle.com> <5bc56926-32eb-28a9-1e54-3b8946051f7c@oracle.com> Message-ID: <3784805a-c75d-5f2f-10b1-7eb8e2aa7411@oracle.com> On 2020-03-01 20:41, Alan Bateman wrote: > On 01/03/2020 18:19, Claes Redestad wrote: >> : >> >> After discussing it a bit offline, Andriy and I would like to simplify >> the dash-checking code a bit to make it more clear, as there seems to be >> no obvious performance drawback of simplifying to (ch1 == '-' && ...). >> >> New webrev: http://cr.openjdk.java.net/~redestad/8196334/open.01/ >> > This looks good and keeping the old code for the size != 36 case gets > around the compatibility issues discussed here with previous attempts to > improve it. > > A few minor nits: The effective TODO to optimize Character.digit in the > declaration of NIBBLES seems like something for JIRA, not a comment > here. I assume the fully qualified class name for java.util.Arrays is > because this patch was initially developed outside of java.util? Can > parse4Nibbles be moved to after the declaration of NIBBLES to avoid it > being in the middle of the two fromString methods? Filed https://bugs.openjdk.java.net/browse/JDK-8240266 to investigate if we can improve the branch elimination in Character.digit and removed the comment. Also moved parse4Nibbles up before fromString and fixed the redundant FQDN for Array: http://cr.openjdk.java.net/~redestad/8196334/open.02/ Thanks! /Claes From lance.andersen at oracle.com Sun Mar 1 21:14:08 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Sun, 1 Mar 2020 16:14:08 -0500 Subject: RFR: removing dead code from jar tool In-Reply-To: References: <62B599B2-5F5C-454E-823A-64AAF93D2817@oracle.com> <994D1E5F-06CA-4489-A662-F4470FD87F24@oracle.com> Message-ID: Hi Christoph, Let me sort this out and once I do I will push the change for Adam. Best lance > On Mar 1, 2020, at 3:16 PM, Langer, Christoph wrote: > > Hi Adam, Lance, > > as you've already figured out, attachments sent out to the mailing list will be removed. So it's important to generate webrevs and link to it or, for smaller patches, inline it. ?? > > Also, the RFR subject is missing a bug ID. From the URL to the webrev I take the bug ID is JDK-8230117. Going to JBS it seems that the bug is confidential. Could you please either open up the bug before pushing or alternatively, create a new, public bug to push this against? > > Thanks > Christoph > > > >> -----Original Message----- >> From: core-libs-dev On Behalf >> Of Lance Andersen >> Sent: Freitag, 28. Februar 2020 18:04 >> To: Sean Mullan >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: RFR: removing dead code from jar tool >> >> sigh it is being removed it appears by the mail server >> >> I placed a copy here: http://cr.openjdk.java.net/~lancea/JDK-8230117.patch >> >> >>> On Feb 28, 2020, at 12:00 PM, Lance Andersen >> wrote: >>> >>> Here it is again >>> >>>> On Feb 28, 2020, at 11:07 AM, Sean Mullan >> wrote: >>>> >>>> I think you forgot to attach the patch. >>>> >>>> --Sean >>>> >>>> On 2/28/20 2:28 AM, Adam Sotona wrote: >>>>> Hi, >>>>> I would like to ask for review of the attached patch removing dead code >> from jar tool >>>>> Class files sun.tools.jar.Manifest and sun.tools.jar.SignatureFile appear >> to be dead code and should be removed. >>>>> Build with the patch passes all Tier1, Tier2 and Tier3 tests. >>>>> Thank you, >>>>> Adam >>> >>> >>> >> >>> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >> >> >> >> >> Lance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From david.holmes at oracle.com Mon Mar 2 06:14:41 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 2 Mar 2020 16:14:41 +1000 Subject: RFR(S): 8232081: Try to link all classes during dynamic CDS dump In-Reply-To: <8ac4612b-fae3-bb16-f2ab-fa323c33ca51@oracle.com> References: <9b40145a-db72-6313-3b98-5e5aea754e25@oracle.com> <1167ff6d-3997-6390-d020-d0946fad0af8@oracle.com> <3f373a33-c7ed-0237-1dd5-f8ac8e8794ee@oracle.com> <8ac4612b-fae3-bb16-f2ab-fa323c33ca51@oracle.com> Message-ID: <00090c43-1e0d-2b1c-d2a5-1b5f1b29199d@oracle.com> Hi Calvin, On 28/02/2020 4:12 pm, Calvin Cheung wrote: > Hi David, > > On 2/27/20 5:40 PM, David Holmes wrote: >> Hi Calvin, Ioi, >> >> Looking good - comments below. >> >> A meta-question: normal application classes are rarely loaded but not >> linked so I'm a little surprised this is an issue. What is the main >> source of such classes - generated classes like lambda forms? Also why >> do we need to link them when loading from the archive if they were >> never linked when the application actually executed ?? > > I saw that Ioi already answered the above. > > I'll try to answer your questions inline below.. Responses inline below ... >> >> On 28/02/2020 10:48 am, Calvin Cheung wrote: >>> Hi David, Ioi, >>> >>> Thanks for your review and suggestions. >>> >>> On 2/26/20 9:46 PM, Ioi Lam wrote: >>>> >>>> >>>> On 2/26/20 7:50 PM, David Holmes wrote: >>>>> Hi Calvin, >>>>> >>>>> Adding core-libs-dev as you are messing with their code :) >>>>> >>>>> On 27/02/2020 1:19 pm, Calvin Cheung wrote: >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8232081 >>>>>> webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/ >>>>>> >>>>>> The proposed changeset for this RFE adds a JVM_LinkClassesForCDS() >>>>>> function to be called from java/lang/Shutdown to notify the JVM to >>>>>> link the classes loaded by the builtin class loaders. The >>>>> >>>>> This would be much less disruptive if this was handled purely on >>>>> the VM side once we have started shutdown. No need to make any >>>>> changes to the Java side then, nor jvm.cpp. >>>>> >>>> >>>> Hi David, >>>> >>>> To link the classes, we need to be able to run Java code -- when >>>> linking a class X loaded by the app loader, X will be verified. >>>> During verification of X, we may need to load additional classes >>>> from the app loader, which executes Java code during its class >>>> loading operations. >>>> >>>> We also need to handle all the exit conditions. As far as I can >>>> tell, an app can exit the JVM in two ways: >>>> >>>> (1) Explicitly calling System.exit(). This will call >>>> java.lang.Shutdown.exit() which does this: >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l163 >>>> >>>> >>>> ??????????? beforeHalt(); // native >>>> ??????????? runHooks(); >>>> ??????????? halt(status); >>>> >>>> (2) When all non-daemon threads have died (e.g., falling out of the >>>> bottom of HelloWorld.main()). There's no explicit call to >>>> System.exit(), but the JVM will proactively call >>>> java.lang.Shutdown.shutdown() inside >>>> JavaThread::invoke_shutdown_hooks() >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/hotspot/share/runtime/thread.cpp#l4331 >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l184 >>>> >>>> >>>> If we want to avoid modifying the Java code, I think we can >>>> intercept JVM_BeforeHalt() and JavaThread::invoke_shutdown_hooks(). >>>> This way we should be able to handle all the classes (except those >>>> that are loaded inside Shutdown.runHooks). >>> >>> I've implemented the above. No changes to the Java side. >>> >>> updated webrev: >>> >>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.01/ >> >> This looks much better to me. I wasn't sure if you were that concerned >> about catching the classes loaded by the Shutdown hooks, but it is >> good you are not as it seems problematic to me to trigger class >> loading etc after the shutdown hooks have executed - you may hit >> unexpected conditions. So this approach is good. >> >> A few minor comments: >> >> src/hotspot/share/memory/metaspaceShared.cpp >> src/hotspot/share/memory/metaspaceShared.hpp >> >> Why the change from TRAPS to "Thread* THREAD"? > I forgot why I changed it but I've changed it back and it still works. Ok. >> >> --- >> >> src/hotspot/share/oops/instanceKlass.cpp >> >> I'm not clear how verify_on is used so am unsure how the additional >> error state check may affect code unrelated to dynamic dumping ?? > > Some of the appcds tests by design have some classes which fail > verification. Without the change, the following assert would fail: > > void vtableEntry::verify(klassVtable* vt, outputStream* st) { > ? Klass* vtklass = vt->klass(); > ? if (vtklass->is_instance_klass() && > ???? (InstanceKlass::cast(vtklass)->major_version() >= > klassVtable::VTABLE_TRANSITIVE_OVERRIDE_VERSION)) { > *assert*(method() != NULL, "must have set method"); > ? } Okay so you need to exclude for that case but ... > Here's the call stack during dynamic CDS dump to the above function: > > vtableEntry::verify(klassVtable *, outputStream *) : void > ??? klassVtable::verify(outputStream *, bool) : void > ??????? InstanceKlass::verify_on(outputStream *) : void > ??????????? Klass::verify() : void > ??????????????? ClassLoaderData::verify() : void > ??????????????????? ClassLoaderDataGraph::verify() : void > ??????????????????????? Universe::verify(enum VerifyOption, const char > *) : void > ??????????????????????????? Universe::verify(const char *) : void > DynamicArchiveBuilder::verify_universe(const char *) : void > ??????????????????????????????????? DynamicArchiveBuilder::doit() : > void (2 matches) > VM_PopulateDynamicDumpSharedSpace::doit() : void > VM_Operation::evaluate() : void > > The is_linked() function is implemented as: > > ??? bool is_linked() const?????????????????? { return _init_state >= > linked; } > > which includes 'initialization_error'. ... AFAICS Universe::verify is call from a number of places, all of which would reach this modified code. As that existing code has included classes that are in the error state then it seems to me that unless you can prove otherwise you need to keep the existing code as-is for the non-CDS dump case. > A previous version of the changeset (including the change in question in > instanceKlass.cpp) passed tier1 - 4 testing. Let me know if I should run > other tests to make sure the change is good. There may well not be a test that covers this. Thanks, David >> >> Also can I suggest (as you are touching this code) to delete the >> ancient comment: >> >> 3580???? // $$$ This used to be done only for m/s collections. Doing it >> 3581???? // always seemed a valid generalization.? (DLD -- 6/00) > > I'm glad that you suggested to remove the above comment. I've no clue > what it means either. > > updated webrev: > > http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.02/ > > thanks, > Calvin >> >> Thanks, >> David >> ----- >> >>> I also updated the test to test the shutdown hook and System.exit() >>> scenarios. >>> >>> All appcds tests passed on my linux host. I'll run more tests using >>> mach5. >>> >>> thanks, >>> >>> Calvin >>> >>> >>>> >>>> What do you think? >>>> >>>> - Ioi >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> MetaspaceShared::link_and_cleanup_shared_classes() has been >>>>>> modified to handle both static and dynamic CDS dump. For dynamic >>>>>> CDS dump, only classes loaded by the builtin class loaders will be >>>>>> linked. Local performance testing using javac on HelloWorld.java >>>>>> shows an improvement of >5%. >>>>>> >>>>>> Passed tier1 - 4 tests. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Calvin >>>>>> >>>> From Alan.Bateman at oracle.com Mon Mar 2 07:14:20 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 Mar 2020 07:14:20 +0000 Subject: RFR: 8196334: Optimize UUID#fromString In-Reply-To: <3784805a-c75d-5f2f-10b1-7eb8e2aa7411@oracle.com> References: <4e866637-0ad8-1999-d70a-3635d7ec0f0f@oracle.com> <8f515c5c-c3a5-fda5-2753-e10fedc2a6c4@oracle.com> <412177f3-9496-a331-1e98-cffbb3fba562@oracle.com> <5bc56926-32eb-28a9-1e54-3b8946051f7c@oracle.com> <3784805a-c75d-5f2f-10b1-7eb8e2aa7411@oracle.com> Message-ID: <6c4445da-1e3f-007d-d83c-013b703653d2@oracle.com> On 01/03/2020 21:05, Claes Redestad wrote: > : > > Filed https://bugs.openjdk.java.net/browse/JDK-8240266 to investigate > if we can improve the branch elimination in Character.digit and removed > the comment. > > Also moved parse4Nibbles up before fromString and fixed the redundant > FQDN for Array: > > http://cr.openjdk.java.net/~redestad/8196334/open.02/ Looks good. -Alan. From claes.redestad at oracle.com Mon Mar 2 07:26:32 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 Mar 2020 08:26:32 +0100 Subject: RFR: 8196334: Optimize UUID#fromString In-Reply-To: <6c4445da-1e3f-007d-d83c-013b703653d2@oracle.com> References: <4e866637-0ad8-1999-d70a-3635d7ec0f0f@oracle.com> <8f515c5c-c3a5-fda5-2753-e10fedc2a6c4@oracle.com> <412177f3-9496-a331-1e98-cffbb3fba562@oracle.com> <5bc56926-32eb-28a9-1e54-3b8946051f7c@oracle.com> <3784805a-c75d-5f2f-10b1-7eb8e2aa7411@oracle.com> <6c4445da-1e3f-007d-d83c-013b703653d2@oracle.com> Message-ID: <3c03d7bb-f0c8-ec44-b52c-75887986904d@oracle.com> On 2020-03-02 08:14, Alan Bateman wrote: >> >> http://cr.openjdk.java.net/~redestad/8196334/open.02/ > Looks good. Thanks - pushed! /Claes From aph at redhat.com Mon Mar 2 12:00:07 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 2 Mar 2020 12:00:07 +0000 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2310d10b-64ec-5680-a780-71138252a259@oracle.com> <3e097a38-2bad-0fa2-e16a-993a4a2718e5@oracle.com> Message-ID: <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> On 11/19/18 8:39 PM, Kim Barrett wrote: > I don't see any benefit to making the first C++ code change that uses > a new feature also incorporate the needed build system changes. > Indeed, how does one develop that feature usage unless one has the > build system changes already in hand? > > It seems to me that if the documentation says one can use some new > language feature but the build system hasn't been updated to actually > support doing so, then the documentation is wrong. And recall that > this JEP includes making some new features available immediately. > (That initial list might be modified as part of this JEP discussion.) What is the status of this? I thought we'd decide, but I still see $1_CXXSTD_CXXFLAG="-std=gnu++98" in flags-cflags.m4 I need std::make_unsigned in order to fix some undefined behaviour in HotSpot. I could implement it myself in share/metaprogramming but if we've agreed to allow C++14, can we please get it done now? Thx. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Mon Mar 2 15:15:39 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 2 Mar 2020 16:15:39 +0100 Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly In-Reply-To: References: Message-ID: On Fri, Feb 28, 2020 at 8:02 PM Martin Buchholz wrote: > > Welcome to the troublesome world of zip implementations! > Well, not many remember that the zip format was designed to work efficiently with floppy discs :) > It looks like by creating a new JarEntry you are discarding possible information from the old one, e.g. you might be discarding whether the input entry was compressed. If "jar u" does that, I would consider it a bug! > You're right. My fix was a little to simple, and can be improved: http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235.01 Preserving the time, comment, extra information, compression method and size/CRC if the compression method was "stored" is the best we can do. And this is actually exactly what "jar -" does (see [1]). [1] http://hg.openjdk.java.net/jdk/jdk/file/e04746cec89c/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#l934 > Arguably there is a missing API that would allow you to copy zip entries from an input to an output completely intact, without having to decompress and recompress. (might be hard to design!) > Yes, I did think about this as well. It might not be that hard at all. We could simply add readRawEntry()/wrtiteRawEntry() methods to ZipInputStream/ZipOutputStream. We'd have to tweak ZipOutputStream.closeEntry() such that it can handle such "raw" writes (e.g. it wouldn't be able to check the CRC any more) and various methods like "skip()" in ZipInputStream. I think this might be interesting not only because it would allow updating zip-files without changing untouched entries, but also because it will considerably improve the speed of updating (i.e. we would save the time for repeatedly inflating and deflating). I'm not sure though how frequent the use-case of updating a zip-file really is? But that would definitely be a larger enhancement with SE scope. Do you think it's worth it? > Probably there should be no such utility method as updateJarFile at all. Perhaps instead the jar/zip code could be refactored so that tests can reuse the same code used by "jar u". > I'll leave that as an extra improvement for others :) > On Fri, Feb 28, 2020 at 10:50 AM Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for this small test fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235/ >> https://bugs.openjdk.java.net/browse/JDK-8240235 >> >> JarUtils.updateJar() and JarUtils.updateJarFile() update jar files by >> reading JarEntry-s from a source jar file and writing these exact >> JarEntry-s to the destination jar file followed be the inflated and >> re-deflated data belonging to this entry. >> >> This approach is not correct, because JarEntry contains both, the >> compressed and uncompressed size of the corresponding entry. But the >> original Defalter which initially compressed that entry can be either >> different from the current one or it might have used a different >> compression level compared to the current Deflater which re-deflates >> the entry data. >> >> When the newly created entry is closed, the new compressed size will >> be checked against the original compressed size if that was recorded >> in the JarEntry and an exception will be thrown, when they differ: >> >> java.util.zip.ZipException: invalid entry compressed size (expected >> 237 but got 238 bytes) >> at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) >> at java.base/java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:192) >> at java.base/java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:108) >> at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:294) >> at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:252) >> at HasUnsignedEntryTest.start(HasUnsignedEntryTest.java:77) >> at HasUnsignedEntryTest.main(HasUnsignedEntryTest.java:44) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:832) >> Suppressed: java.util.zip.ZipException: invalid entry >> compressed size (expected 237 but got 238 bytes) >> at >> java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) >> at >> java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) >> at >> java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237) >> at >> java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) >> at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:280) >> >> The fix is trivial. Instead of copying the JarEntry-s verbatim to the >> output stream, simply write newly created JarEntry-s to the output >> stream which only contain the entry name. This is also the way how >> this is handled by the jar tool, when it updates jar files. >> >> Thank you and best regards, >> Volker From volker.simonis at gmail.com Mon Mar 2 15:17:22 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 2 Mar 2020 16:17:22 +0100 Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly In-Reply-To: References: Message-ID: Hi Christoph, thanks for looking at my change. I've slightly improved the implementation as suggested by Martin to preserve all the zip attributes which can be preserved. Still fine for you? http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235.01 On Sun, Mar 1, 2020 at 9:21 PM Langer, Christoph wrote: > > Hi Volker, > > this looks good to me. > > Best regards > Christoph > > > -----Original Message----- > > From: core-libs-dev On Behalf > > Of Volker Simonis > > Sent: Freitag, 28. Februar 2020 19:48 > > To: Java Core Libs > > Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly > > > > Hi, > > > > can I please have a review for this small test fix: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235/ > > https://bugs.openjdk.java.net/browse/JDK-8240235 > > > > JarUtils.updateJar() and JarUtils.updateJarFile() update jar files by > > reading JarEntry-s from a source jar file and writing these exact > > JarEntry-s to the destination jar file followed be the inflated and > > re-deflated data belonging to this entry. > > > > This approach is not correct, because JarEntry contains both, the > > compressed and uncompressed size of the corresponding entry. But the > > original Defalter which initially compressed that entry can be either > > different from the current one or it might have used a different > > compression level compared to the current Deflater which re-deflates > > the entry data. > > > > When the newly created entry is closed, the new compressed size will > > be checked against the original compressed size if that was recorded > > in the JarEntry and an exception will be thrown, when they differ: > > > > java.util.zip.ZipException: invalid entry compressed size (expected > > 237 but got 238 bytes) > > at > > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:26 > > 7) > > at > > java.base/java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java > > :192) > > at > > java.base/java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java > > :108) > > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:294) > > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:252) > > at HasUnsignedEntryTest.start(HasUnsignedEntryTest.java:77) > > at HasUnsignedEntryTest.main(HasUnsignedEntryTest.java:44) > > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) > > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet > > hodAccessorImpl.java:62) > > at > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega > > tingMethodAccessorImpl.java:43) > > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > > at > > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp > > er.java:127) > > at java.base/java.lang.Thread.run(Thread.java:832) > > Suppressed: java.util.zip.ZipException: invalid entry > > compressed size (expected 237 but got 238 bytes) > > at > > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:26 > > 7) > > at > > java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) > > at > > java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.ja > > va:237) > > at > > java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) > > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:280) > > > > The fix is trivial. Instead of copying the JarEntry-s verbatim to the > > output stream, simply write newly created JarEntry-s to the output > > stream which only contain the entry name. This is also the way how > > this is handled by the jar tool, when it updates jar files. > > > > Thank you and best regards, > > Volker From chiroito107 at gmail.com Mon Mar 2 15:39:43 2020 From: chiroito107 at gmail.com (Chihiro Ito) Date: Tue, 3 Mar 2020 00:39:43 +0900 Subject: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format Message-ID: Hi, I tried to correct this problem. Could you review this fix, please? According to the RFC 4122, UUID has a fixed format. I tried to raise an exception if a string was specified that is not suitable for this format. Also, is there anything else I should be aware of with this bug? Webrev : http://cr.openjdk.java.net/~cito/JDK-8216407/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8216407 Regards, Chihiro From martinrb at google.com Mon Mar 2 16:01:45 2020 From: martinrb at google.com (Martin Buchholz) Date: Mon, 2 Mar 2020 08:01:45 -0800 Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly In-Reply-To: References: Message-ID: On Mon, Mar 2, 2020 at 7:15 AM Volker Simonis wrote: > On Fri, Feb 28, 2020 at 8:02 PM Martin Buchholz > wrote: > > > > Welcome to the troublesome world of zip implementations! > > > > Well, not many remember that the zip format was designed to work > efficiently with floppy discs :) > > > It looks like by creating a new JarEntry you are discarding possible > information from the old one, e.g. you might be discarding whether the > input entry was compressed. If "jar u" does that, I would consider it a > bug! > > > > You're right. My fix was a little to simple, and can be improved: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235.01 > > Preserving the time, comment, extra information, compression method > and size/CRC if the compression method was "stored" is the best we can > do. And this is actually exactly what "jar -" does (see [1]). > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/e04746cec89c/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#l934 > > This fix Looks Good To Me. > > Arguably there is a missing API that would allow you to copy zip entries > from an input to an output completely intact, without having to decompress > and recompress. (might be hard to design!) > > > > Yes, I did think about this as well. It might not be that hard at all. > We could simply add readRawEntry()/wrtiteRawEntry() methods to > ZipInputStream/ZipOutputStream. We'd have to tweak > ZipOutputStream.closeEntry() such that it can handle such "raw" writes > (e.g. it wouldn't be able to check the CRC any more) and various > methods like "skip()" in ZipInputStream. I think this might be > interesting not only because it would allow updating zip-files without > changing untouched entries, but also because it will considerably > improve the speed of updating (i.e. we would save the time for > repeatedly inflating and deflating). I'm not sure though how frequent > the use-case of updating a zip-file really is? > > But that would definitely be a larger enhancement with SE scope. Do > you think it's worth it? > > The platform "should" have something like this, and I've had similar thoughts myself in the past, and my employer would benefit, since there's a lot of zip munging that happens when building large applications. But as always, we have trouble finding the time. > > Probably there should be no such utility method as updateJarFile at > all. Perhaps instead the jar/zip code could be refactored so that tests > can reuse the same code used by "jar u". > > > > I'll leave that as an extra improvement for others :) > > > On Fri, Feb 28, 2020 at 10:50 AM Volker Simonis < > volker.simonis at gmail.com> wrote: > >> > >> Hi, > >> > >> can I please have a review for this small test fix: > >> > >> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235/ > >> https://bugs.openjdk.java.net/browse/JDK-8240235 > >> > >> JarUtils.updateJar() and JarUtils.updateJarFile() update jar files by > >> reading JarEntry-s from a source jar file and writing these exact > >> JarEntry-s to the destination jar file followed be the inflated and > >> re-deflated data belonging to this entry. > >> > >> This approach is not correct, because JarEntry contains both, the > >> compressed and uncompressed size of the corresponding entry. But the > >> original Defalter which initially compressed that entry can be either > >> different from the current one or it might have used a different > >> compression level compared to the current Deflater which re-deflates > >> the entry data. > >> > >> When the newly created entry is closed, the new compressed size will > >> be checked against the original compressed size if that was recorded > >> in the JarEntry and an exception will be thrown, when they differ: > >> > >> java.util.zip.ZipException: invalid entry compressed size (expected > >> 237 but got 238 bytes) > >> at > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) > >> at > java.base/java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:192) > >> at > java.base/java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:108) > >> at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:294) > >> at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:252) > >> at HasUnsignedEntryTest.start(HasUnsignedEntryTest.java:77) > >> at HasUnsignedEntryTest.main(HasUnsignedEntryTest.java:44) > >> at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >> at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >> at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) > >> at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > >> at java.base/java.lang.Thread.run(Thread.java:832) > >> Suppressed: java.util.zip.ZipException: invalid entry > >> compressed size (expected 237 but got 238 bytes) > >> at > >> > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) > >> at > >> java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) > >> at > >> > java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237) > >> at > >> java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) > >> at > jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:280) > >> > >> The fix is trivial. Instead of copying the JarEntry-s verbatim to the > >> output stream, simply write newly created JarEntry-s to the output > >> stream which only contain the entry name. This is also the way how > >> this is handled by the jar tool, when it updates jar files. > >> > >> Thank you and best regards, > >> Volker > From lance.andersen at oracle.com Mon Mar 2 16:28:47 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 2 Mar 2020 11:28:47 -0500 Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly In-Reply-To: References: Message-ID: <192690F5-D7CF-4180-80D4-89EE7034DB1E@oracle.com> I think the revised patch looks fine > On Mar 2, 2020, at 10:15 AM, Volker Simonis wrote: > > On Fri, Feb 28, 2020 at 8:02 PM Martin Buchholz wrote: >> >> Welcome to the troublesome world of zip implementations! >> > > Well, not many remember that the zip format was designed to work > efficiently with floppy discs :) > >> It looks like by creating a new JarEntry you are discarding possible information from the old one, e.g. you might be discarding whether the input entry was compressed. If "jar u" does that, I would consider it a bug! >> > > You're right. My fix was a little to simple, and can be improved: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235.01 > > Preserving the time, comment, extra information, compression method > and size/CRC if the compression method was "stored" is the best we can > do. And this is actually exactly what "jar -" does (see [1]). > > [1] http://hg.openjdk.java.net/jdk/jdk/file/e04746cec89c/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#l934 > >> Arguably there is a missing API that would allow you to copy zip entries from an input to an output completely intact, without having to decompress and recompress. (might be hard to design!) >> > > Yes, I did think about this as well. It might not be that hard at all. > We could simply add readRawEntry()/wrtiteRawEntry() methods to > ZipInputStream/ZipOutputStream. We'd have to tweak > ZipOutputStream.closeEntry() such that it can handle such "raw" writes > (e.g. it wouldn't be able to check the CRC any more) and various > methods like "skip()" in ZipInputStream. I think this might be > interesting not only because it would allow updating zip-files without > changing untouched entries, but also because it will considerably > improve the speed of updating (i.e. we would save the time for > repeatedly inflating and deflating). I'm not sure though how frequent > the use-case of updating a zip-file really is? > > But that would definitely be a larger enhancement with SE scope. Do > you think it's worth it? > >> Probably there should be no such utility method as updateJarFile at all. Perhaps instead the jar/zip code could be refactored so that tests can reuse the same code used by "jar u". >> > > I'll leave that as an extra improvement for others :) > >> On Fri, Feb 28, 2020 at 10:50 AM Volker Simonis wrote: >>> >>> Hi, >>> >>> can I please have a review for this small test fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235/ >>> https://bugs.openjdk.java.net/browse/JDK-8240235 >>> >>> JarUtils.updateJar() and JarUtils.updateJarFile() update jar files by >>> reading JarEntry-s from a source jar file and writing these exact >>> JarEntry-s to the destination jar file followed be the inflated and >>> re-deflated data belonging to this entry. >>> >>> This approach is not correct, because JarEntry contains both, the >>> compressed and uncompressed size of the corresponding entry. But the >>> original Defalter which initially compressed that entry can be either >>> different from the current one or it might have used a different >>> compression level compared to the current Deflater which re-deflates >>> the entry data. >>> >>> When the newly created entry is closed, the new compressed size will >>> be checked against the original compressed size if that was recorded >>> in the JarEntry and an exception will be thrown, when they differ: >>> >>> java.util.zip.ZipException: invalid entry compressed size (expected >>> 237 but got 238 bytes) >>> at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) >>> at java.base/java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:192) >>> at java.base/java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:108) >>> at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:294) >>> at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:252) >>> at HasUnsignedEntryTest.start(HasUnsignedEntryTest.java:77) >>> at HasUnsignedEntryTest.main(HasUnsignedEntryTest.java:44) >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >>> at java.base/java.lang.Thread.run(Thread.java:832) >>> Suppressed: java.util.zip.ZipException: invalid entry >>> compressed size (expected 237 but got 238 bytes) >>> at >>> java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) >>> at >>> java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) >>> at >>> java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237) >>> at >>> java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) >>> at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:280) >>> >>> The fix is trivial. Instead of copying the JarEntry-s verbatim to the >>> output stream, simply write newly created JarEntry-s to the output >>> stream which only contain the entry name. This is also the way how >>> this is handled by the jar tool, when it updates jar files. >>> >>> Thank you and best regards, >>> Volker Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Roger.Riggs at oracle.com Mon Mar 2 16:44:21 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 2 Mar 2020 11:44:21 -0500 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: References: Message-ID: <0acbeef9-741a-f474-8980-4160441ba1d9@oracle.com> Hi Naoto, look ok. ZoneRules.java: 488, 644, 761, 791 I'd suggest calling isFixedOffset() instead of repeating the code: standardTransitions.length == 0 && savingsInstantTransitions.length == 0 It should be inlined in cases where the performance matters. Thanks, Roger On 2/27/20 3:41 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8239836 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ > > It turned out that 'transitionList' is not necessarily a superset of > 'standardOffsetTransitionList', as in some occasions where a standard > offset change and a savings change happen at the same time (canceling > each other), resulting in no wall time transition. This means that the > "rules" in the sample code is a valid ZoneRules instance. > > However, there is an assumption in ZoneRules where no (wall time) > transition means the fixed offset zone. With that assumption, the > example rule is considered a fixed offset zone which is not correct. > So the fix proposed here is not to throw an IAE but to recognize the > rule as a valid, non-fixed offset ZoneRules instance. > > Naoto > > From takiguc at linux.vnet.ibm.com Mon Mar 2 17:33:39 2020 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 03 Mar 2020 02:33:39 +0900 Subject: RFR 8232161: Align some one-way conversion in MS950 charset with Windows Message-ID: Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8232161 Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.01/ CSR 8233385 [1] was approved. [1] https://bugs.openjdk.java.net/browse/JDK-8233385 Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From naoto.sato at oracle.com Mon Mar 2 18:35:22 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 2 Mar 2020 10:35:22 -0800 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: <0acbeef9-741a-f474-8980-4160441ba1d9@oracle.com> References: <0acbeef9-741a-f474-8980-4160441ba1d9@oracle.com> Message-ID: <3861e14e-0753-ae51-bd12-8839cbab30b6@oracle.com> Hi Roger, thanks for the review. On 3/2/20 8:44 AM, Roger Riggs wrote: > Hi Naoto, > > look ok. > > ZoneRules.java: 488, 644, 761, 791 > I'd suggest calling isFixedOffset() instead of repeating the code: > standardTransitions.length == 0 && savingsInstantTransitions.length == 0 Modified as suggested: http://cr.openjdk.java.net/~naoto/8239836/webrev.01/ > > It should be inlined in cases where the performance matters. None of those locations is invoked during ZoneRules object instantiation. So I believe it is OK to replace them with isFixedOffset(). Naoto > > Thanks, Roger > > > On 2/27/20 3:41 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8239836 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ >> >> It turned out that 'transitionList' is not necessarily a superset of >> 'standardOffsetTransitionList', as in some occasions where a standard >> offset change and a savings change happen at the same time (canceling >> each other), resulting in no wall time transition. This means that the >> "rules" in the sample code is a valid ZoneRules instance. >> >> However, there is an assumption in ZoneRules where no (wall time) >> transition means the fixed offset zone. With that assumption, the >> example rule is considered a fixed offset zone which is not correct. >> So the fix proposed here is not to throw an IAE but to recognize the >> rule as a valid, non-fixed offset ZoneRules instance. >> >> Naoto >> >> > From Roger.Riggs at oracle.com Mon Mar 2 18:37:24 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 2 Mar 2020 13:37:24 -0500 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: <3861e14e-0753-ae51-bd12-8839cbab30b6@oracle.com> References: <0acbeef9-741a-f474-8980-4160441ba1d9@oracle.com> <3861e14e-0753-ae51-bd12-8839cbab30b6@oracle.com> Message-ID: <4b40de92-09cb-a88c-2f55-5f0b332a532f@oracle.com> Looks good. Give it a day to see if anyone else has comments. Thanks, Roger On 3/2/20 1:35 PM, naoto.sato at oracle.com wrote: > Hi Roger, thanks for the review. > > On 3/2/20 8:44 AM, Roger Riggs wrote: >> Hi Naoto, >> >> look ok. >> >> ZoneRules.java: 488, 644, 761, 791 >> I'd suggest calling isFixedOffset() instead of repeating the code: >> standardTransitions.length == 0 && savingsInstantTransitions.length == 0 > > Modified as suggested: > > http://cr.openjdk.java.net/~naoto/8239836/webrev.01/ > >> >> It should be inlined in cases where the performance matters. > > None of those locations is invoked during ZoneRules object > instantiation. So I believe it is OK to replace them with > isFixedOffset(). > > Naoto > >> >> Thanks, Roger >> >> >> On 2/27/20 3:41 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8239836 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ >>> >>> It turned out that 'transitionList' is not necessarily a superset of >>> 'standardOffsetTransitionList', as in some occasions where a >>> standard offset change and a savings change happen at the same time >>> (canceling each other), resulting in no wall time transition. This >>> means that the "rules" in the sample code is a valid ZoneRules >>> instance. >>> >>> However, there is an assumption in ZoneRules where no (wall time) >>> transition means the fixed offset zone. With that assumption, the >>> example rule is considered a fixed offset zone which is not correct. >>> So the fix proposed here is not to throw an IAE but to recognize the >>> rule as a valid, non-fixed offset ZoneRules instance. >>> >>> Naoto >>> >>> >> From vipinsharma85 at gmail.com Mon Mar 2 19:33:32 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Tue, 3 Mar 2020 01:03:32 +0530 Subject: Need bug id to remove the explicit type argument in test class Message-ID: Hi, My OCA has been processed recently and I want to start Contributing to OpenJDK. As a first fix, I would like to remove the explicit type argument in test class test/jdk/java/lang/Boolean/MakeBooleanComparable.java to fix one warning. The first line given below is the existing code and the second line is what I am changing it to. List list = new ArrayList(); List list = new ArrayList<>(); If this is not too small change to start with, could you please help me to create a bug id against this so that I can create a patch and share. Regards, Vipin From andy.herrick at oracle.com Mon Mar 2 19:38:25 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 2 Mar 2020 14:38:25 -0500 Subject: RFR: 8237967: No proper error message when --runtime-image points to non-existent path In-Reply-To: References: <7075dc10-d113-7cd0-b151-9c8cbf6ba96e@oracle.com> <31caba34-8e57-71d3-4390-bdeb7a70e712@oracle.com> <37204e53-061d-bb2a-20aa-f5419b9c1f49@oracle.com> Message-ID: I sent this in reply to Alexey, needed to send it to alias: On 2/6/2020 4:54 PM, Andy Herrick wrote: > I had fixed that and failed to push the revised webrev [4] > > [4] http://cr.openjdk.java.net/~herrick/8237967/webrev.03/ > > /Andy > > On 2/6/2020 11:46 AM, Alexey Semenyuk wrote: >> Andy, >> >> defaultSupported() is defined, but not called form the test. What is >> the point of this method? >> >> - Alexey >> >> On 2/6/2020 8:42 AM, Andy Herrick wrote: >>> revised fir at [3] to check for non-existent resource-dir as well as >>> runtime-image dir. >>> >>> [3] http://cr.openjdk.java.net/~herrick/8237967/webrev.02/ >>> >>> /Andy >>> >>> On 2/5/2020 7:46 PM, Andy Herrick wrote: >>>> OK - this makes sense - will update tomorrow. >>>> >>>> /Andy >>>> >>>> On 2/5/2020 4:24 PM, Alexander Matveev wrote: >>>>> Hi Andy, >>>>> >>>>> Fix looks good, but I think we should do same for --resource-dir. >>>>> I do not think that non-existing directory should be same as >>>>> empty. User might misspell directory name and it will not be clear >>>>> for user why we not using information from --resource-dir. >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 2/5/2020 10:23 AM, Andy Herrick wrote: >>>>>> This simple fix [1] to jpackage bug [2] simply adds a proper >>>>>> error message when --runtime-image points to a non-existent >>>>>> directory path. >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~herrick/8237967/webrev.01/index.html >>>>>> >>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8237967 >>>>>> >>>>>> /Andy >>>>>> >>>>> >> From akashche at redhat.com Mon Mar 2 20:44:19 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 2 Mar 2020 20:44:19 +0000 Subject: [11u] RFR: 8232854: URLClassLoader.close() doesn't close cached JAR file on Windows when load() fails In-Reply-To: References: <361f077a-6d89-6de4-c613-2fed37a4c269@redhat.com> Message-ID: On 03/01/2020 02:26 PM, Alan Bateman wrote: > On 01/03/2020 12:03, Alex Kashchenko wrote: >> Hi, >> >> Please review the fix to JDK-8232854 for 11u: >> >> Jira issue: https://bugs.openjdk.java.net/browse/JDK-8232854 > This issue has not been fixed in the main line (jdk/jdk) yet. It may be > that the eventual fix will be in the URL protocol handler. Several > options will need to be explored and I suspect it will take time to > agree the right solution for this issue. I realize this doesn't help > with a point fix for 11u. Maybe you have cycles to work the options to > fix the underlying issue in the main line? Yes, I can work on this issue for jdk/jdk. I found this part of code complicated and would appreciate the guidance. -- -Alex From kim.barrett at oracle.com Mon Mar 2 21:51:38 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 2 Mar 2020 16:51:38 -0500 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2310d10b-64ec-5680-a780-71138252a259@oracle.com> <3e097a38-2bad-0fa2-e16a-993a4a2718e5@oracle.com> <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> Message-ID: <7343D525-DB1F-4FB0-AF3E-0159D3C97DB6@oracle.com> > On Mar 2, 2020, at 7:00 AM, Andrew Haley wrote: > > On 11/19/18 8:39 PM, Kim Barrett wrote: >> I don't see any benefit to making the first C++ code change that uses >> a new feature also incorporate the needed build system changes. >> Indeed, how does one develop that feature usage unless one has the >> build system changes already in hand? >> >> It seems to me that if the documentation says one can use some new >> language feature but the build system hasn't been updated to actually >> support doing so, then the documentation is wrong. And recall that >> this JEP includes making some new features available immediately. >> (That initial list might be modified as part of this JEP discussion.) > > What is the status of this? I thought we'd decide, but I still see > > $1_CXXSTD_CXXFLAG="-std=gnu++98" > > in flags-cflags.m4 > > I need std::make_unsigned in order to fix some undefined behaviour in > HotSpot. I could implement it myself in share/metaprogramming but if > we've agreed to allow C++14, can we please get it done now? Thx. In light of JEP 362 "Deprecate the Solaris and SPARC Ports" https://bugs.openjdk.java.net/browse/JDK-8231554 with the intended removal of Oracle Developer Studio (aka Solaris Studio) as a supported compiler sometime soon, we don't want to spend effort getting HotSpot to production quality on that platform with C++11/14 features enabled and in use. From volker.simonis at gmail.com Mon Mar 2 22:46:57 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 2 Mar 2020 23:46:57 +0100 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2310d10b-64ec-5680-a780-71138252a259@oracle.com> <3e097a38-2bad-0fa2-e16a-993a4a2718e5@oracle.com> <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> Message-ID: Andrew Haley schrieb am Mo., 2. M?rz 2020, 13:00: > On 11/19/18 8:39 PM, Kim Barrett wrote: > > I don't see any benefit to making the first C++ code change that uses > > a new feature also incorporate the needed build system changes. > > Indeed, how does one develop that feature usage unless one has the > > build system changes already in hand? > > > > It seems to me that if the documentation says one can use some new > > language feature but the build system hasn't been updated to actually > > support doing so, then the documentation is wrong. And recall that > > this JEP includes making some new features available immediately. > > (That initial list might be modified as part of this JEP discussion.) > > What is the status of this? I thought we'd decide, but I still see > > $1_CXXSTD_CXXFLAG="-std=gnu++98" > > in flags-cflags.m4 > > I need std::make_unsigned in order to fix some undefined behaviour in > HotSpot. I could implement it myself in share/metaprogramming but if > we've agreed to allow C++14, can we please get it done now? Thx. > As lead of the 8 and 11 update projects you probably know best, if this fix will eventually be considered for backporting and choose your means wisely :) > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From alexander.zuev at oracle.com Tue Mar 3 00:58:39 2020 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 3 Mar 2020 03:58:39 +0300 Subject: RFR: 8237967: No proper error message when --runtime-image points to non-existent path In-Reply-To: References: <7075dc10-d113-7cd0-b151-9c8cbf6ba96e@oracle.com> <31caba34-8e57-71d3-4390-bdeb7a70e712@oracle.com> <37204e53-061d-bb2a-20aa-f5419b9c1f49@oracle.com> Message-ID: <152f158e-0d46-bac9-9b67-ff964af3bf26@oracle.com> Looks fine to me. /Alex On 02-Mar-20 22:38, Andy Herrick wrote: > I sent this in reply to Alexey, needed to send it to alias: > > On 2/6/2020 4:54 PM, Andy Herrick wrote: >> I had fixed that and failed to push the revised webrev [4] >> >> [4] http://cr.openjdk.java.net/~herrick/8237967/webrev.03/ >> >> /Andy >> >> On 2/6/2020 11:46 AM, Alexey Semenyuk wrote: >>> Andy, >>> >>> defaultSupported() is defined, but not called form the test. What is >>> the point of this method? >>> >>> - Alexey >>> >>> On 2/6/2020 8:42 AM, Andy Herrick wrote: >>>> revised fir at [3] to check for non-existent resource-dir as well >>>> as runtime-image dir. >>>> >>>> [3] http://cr.openjdk.java.net/~herrick/8237967/webrev.02/ >>>> >>>> /Andy >>>> >>>> On 2/5/2020 7:46 PM, Andy Herrick wrote: >>>>> OK - this makes sense - will update tomorrow. >>>>> >>>>> /Andy >>>>> >>>>> On 2/5/2020 4:24 PM, Alexander Matveev wrote: >>>>>> Hi Andy, >>>>>> >>>>>> Fix looks good, but I think we should do same for --resource-dir. >>>>>> I do not think that non-existing directory should be same as >>>>>> empty. User might misspell directory name and it will not be >>>>>> clear for user why we not using information from --resource-dir. >>>>>> >>>>>> Thanks, >>>>>> Alexander >>>>>> >>>>>> On 2/5/2020 10:23 AM, Andy Herrick wrote: >>>>>>> This simple fix [1] to jpackage bug [2] simply adds a proper >>>>>>> error message when --runtime-image points to a non-existent >>>>>>> directory path. >>>>>>> >>>>>>> [1] >>>>>>> http://cr.openjdk.java.net/~herrick/8237967/webrev.01/index.html >>>>>>> >>>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8237967 >>>>>>> >>>>>>> /Andy >>>>>>> >>>>>> >>> From naoto.sato at oracle.com Tue Mar 3 01:31:14 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 2 Mar 2020 17:31:14 -0800 Subject: RFR 8232161: Align some one-way conversion in MS950 charset with Windows In-Reply-To: References: Message-ID: <29c29ad7-a953-97a3-11eb-87ab612a323f@oracle.com> Hi Takiguchi-san, A few comments: - I'd recommend sorting the entries in MS950.nr and test data in TestMS950.java for readability. - Add some comment about the objective in the test. It'd be hard for engineers who have no previous knowledge to these bytes. Naoto On 3/2/20 9:33 AM, Ichiroh Takiguchi wrote: > Hello. > > Could you review the fix ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161 > Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.01/ > > CSR 8233385 [1] was approved. > > [1] https://bugs.openjdk.java.net/browse/JDK-8233385 > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. From christoph.langer at sap.com Tue Mar 3 07:15:22 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 3 Mar 2020 07:15:22 +0000 Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly In-Reply-To: References: Message-ID: Hi Volker, sure, looks good. Unfortunately I don't get the mails from Martin ? Cheers Christoph > -----Original Message----- > From: Volker Simonis > Sent: Montag, 2. M?rz 2020 16:17 > To: Langer, Christoph > Cc: Java Core Libs > Subject: Re: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files > incorrectly > > Hi Christoph, > > thanks for looking at my change. I've slightly improved the > implementation as suggested by Martin to preserve all the zip > attributes which can be preserved. Still fine for you? > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235.01 > > On Sun, Mar 1, 2020 at 9:21 PM Langer, Christoph > wrote: > > > > Hi Volker, > > > > this looks good to me. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: core-libs-dev On > Behalf > > > Of Volker Simonis > > > Sent: Freitag, 28. Februar 2020 19:48 > > > To: Java Core Libs > > > Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files > incorrectly > > > > > > Hi, > > > > > > can I please have a review for this small test fix: > > > > > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235/ > > > https://bugs.openjdk.java.net/browse/JDK-8240235 > > > > > > JarUtils.updateJar() and JarUtils.updateJarFile() update jar files by > > > reading JarEntry-s from a source jar file and writing these exact > > > JarEntry-s to the destination jar file followed be the inflated and > > > re-deflated data belonging to this entry. > > > > > > This approach is not correct, because JarEntry contains both, the > > > compressed and uncompressed size of the corresponding entry. But the > > > original Defalter which initially compressed that entry can be either > > > different from the current one or it might have used a different > > > compression level compared to the current Deflater which re-deflates > > > the entry data. > > > > > > When the newly created entry is closed, the new compressed size will > > > be checked against the original compressed size if that was recorded > > > in the JarEntry and an exception will be thrown, when they differ: > > > > > > java.util.zip.ZipException: invalid entry compressed size (expected > > > 237 but got 238 bytes) > > > at > > > > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:26 > > > 7) > > > at > > > > java.base/java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java > > > :192) > > > at > > > > java.base/java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java > > > :108) > > > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:294) > > > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:252) > > > at HasUnsignedEntryTest.start(HasUnsignedEntryTest.java:77) > > > at HasUnsignedEntryTest.main(HasUnsignedEntryTest.java:44) > > > at > > > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > > Method) > > > at > > > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet > > > hodAccessorImpl.java:62) > > > at > > > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega > > > tingMethodAccessorImpl.java:43) > > > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > > > at > > > > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp > > > er.java:127) > > > at java.base/java.lang.Thread.run(Thread.java:832) > > > Suppressed: java.util.zip.ZipException: invalid entry > > > compressed size (expected 237 but got 238 bytes) > > > at > > > > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:26 > > > 7) > > > at > > > > java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) > > > at > > > > java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.ja > > > va:237) > > > at > > > java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) > > > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:280) > > > > > > The fix is trivial. Instead of copying the JarEntry-s verbatim to the > > > output stream, simply write newly created JarEntry-s to the output > > > stream which only contain the entry name. This is also the way how > > > this is handled by the jar tool, when it updates jar files. > > > > > > Thank you and best regards, > > > Volker From huizhe.wang at oracle.com Tue Mar 3 07:20:11 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 2 Mar 2020 23:20:11 -0800 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: <4b40de92-09cb-a88c-2f55-5f0b332a532f@oracle.com> References: <0acbeef9-741a-f474-8980-4160441ba1d9@oracle.com> <3861e14e-0753-ae51-bd12-8839cbab30b6@oracle.com> <4b40de92-09cb-a88c-2f55-5f0b332a532f@oracle.com> Message-ID: <640e6fe3-939d-1413-5d77-df8e949812f7@oracle.com> Hi Naoto, The fix would be fine if you want to keep it as is since it does work. I noticed though that for standard zones (the ones loaded from tz database), savingsInstantTransitions and standardTransitions are consistent in that they are both empty for the standard zones, e.g. Etc/GMT, and not empty for zones with a country/city id, including countries that don't actually observe DST. This means a check for one of them is enough for standard zones, which was done in the current implementation (that is, isFixedOffset() returns savingsInstantTransitions.length == 0). For custom ZoneRules created with the "of" method, it would depend on whether they are set through the relevant parameters (in the test case, the later was set but the former was empty, that was why isFixedOffset was true). It would therefore be possible to add and use a transient boolean field to represent isFixedOffset. Just my two cents. -Joe On 3/2/20 10:37 AM, Roger Riggs wrote: > Looks good. > > Give it a day to see if anyone else has comments. > > Thanks, Roger > > On 3/2/20 1:35 PM, naoto.sato at oracle.com wrote: >> Hi Roger, thanks for the review. >> >> On 3/2/20 8:44 AM, Roger Riggs wrote: >>> Hi Naoto, >>> >>> look ok. >>> >>> ZoneRules.java: 488, 644, 761, 791 >>> I'd suggest calling isFixedOffset() instead of repeating the code: >>> standardTransitions.length == 0 && savingsInstantTransitions.length >>> == 0 >> >> Modified as suggested: >> >> http://cr.openjdk.java.net/~naoto/8239836/webrev.01/ >> >>> >>> It should be inlined in cases where the performance matters. >> >> None of those locations is invoked during ZoneRules object >> instantiation. So I believe it is OK to replace them with >> isFixedOffset(). >> >> Naoto >> >>> >>> Thanks, Roger >>> >>> >>> On 2/27/20 3:41 PM, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8239836 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ >>>> >>>> It turned out that 'transitionList' is not necessarily a superset of >>>> 'standardOffsetTransitionList', as in some occasions where a >>>> standard offset change and a savings change happen at the same time >>>> (canceling each other), resulting in no wall time transition. This >>>> means that the "rules" in the sample code is a valid ZoneRules >>>> instance. >>>> >>>> However, there is an assumption in ZoneRules where no (wall time) >>>> transition means the fixed offset zone. With that assumption, the >>>> example rule is considered a fixed offset zone which is not >>>> correct. So the fix proposed here is not to throw an IAE but to >>>> recognize the rule as a valid, non-fixed offset ZoneRules instance. >>>> >>>> Naoto >>>> >>>> >>> > From jai.forums2013 at gmail.com Tue Mar 3 08:07:52 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 3 Mar 2020 13:37:52 +0530 Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly In-Reply-To: References: Message-ID: <95c0331a-94a8-7441-f55e-d0b45709efb2@gmail.com> On 03/03/20 12:45 pm, Langer, Christoph wrote: > Unfortunately I don't get the mails from Martin ? Same for me. They always end up in spam folder which I usually check once a month. I see that there's already https://bugs.openjdk.java.net/browse/JDK-8213225 which seems to be the same issue. -Jaikiran From christoph.langer at sap.com Tue Mar 3 08:10:27 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 3 Mar 2020 08:10:27 +0000 Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly In-Reply-To: <95c0331a-94a8-7441-f55e-d0b45709efb2@gmail.com> References: <95c0331a-94a8-7441-f55e-d0b45709efb2@gmail.com> Message-ID: > On 03/03/20 12:45 pm, Langer, Christoph wrote: > > Unfortunately I don't get the mails from Martin ? > > Same for me. They always end up in spam folder which I usually check > once a month. I see that there's already > https://bugs.openjdk.java.net/browse/JDK-8213225 which seems to be the > same issue. > You are lucky, that you at least get it delivered to the spam folder... ?? /Christoph From aph at redhat.com Tue Mar 3 09:19:28 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 3 Mar 2020 09:19:28 +0000 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7343D525-DB1F-4FB0-AF3E-0159D3C97DB6@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2310d10b-64ec-5680-a780-71138252a259@oracle.com> <3e097a38-2bad-0fa2-e16a-993a4a2718e5@oracle.com> <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> <7343D525-DB1F-4FB0-AF3E-0159D3C97DB6@oracle.com> Message-ID: <99f5cc63-8d3f-5678-5077-d4fa2a3e817e@redhat.com> On 3/2/20 9:51 PM, Kim Barrett wrote: >> On Mar 2, 2020, at 7:00 AM, Andrew Haley wrote: >> >> On 11/19/18 8:39 PM, Kim Barrett wrote: >>> I don't see any benefit to making the first C++ code change that uses >>> a new feature also incorporate the needed build system changes. >>> Indeed, how does one develop that feature usage unless one has the >>> build system changes already in hand? >>> >>> It seems to me that if the documentation says one can use some new >>> language feature but the build system hasn't been updated to actually >>> support doing so, then the documentation is wrong. And recall that >>> this JEP includes making some new features available immediately. >>> (That initial list might be modified as part of this JEP discussion.) >> >> What is the status of this? I thought we'd decide, but I still see >> >> $1_CXXSTD_CXXFLAG="-std=gnu++98" >> >> in flags-cflags.m4 >> >> I need std::make_unsigned in order to fix some undefined behaviour in >> HotSpot. I could implement it myself in share/metaprogramming but if >> we've agreed to allow C++14, can we please get it done now? Thx. > > In light of JEP 362 "Deprecate the Solaris and SPARC Ports" > https://bugs.openjdk.java.net/browse/JDK-8231554 > with the intended removal of Oracle Developer Studio (aka Solaris > Studio) as a supported compiler sometime soon, we don't want to spend > effort getting HotSpot to production quality on that platform with > C++11/14 features enabled and in use. OK. So, I guess this means that we're stuck with C++98 (!) for a while. It's not too hard for me to write the support for make_unsigned and add it to share/metaprogramming. I'll do that and see what people say. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Mar 3 09:26:44 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 3 Mar 2020 09:26:44 +0000 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2310d10b-64ec-5680-a780-71138252a259@oracle.com> <3e097a38-2bad-0fa2-e16a-993a4a2718e5@oracle.com> <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> Message-ID: <4081af4f-372d-911e-840b-de97847cba3a@redhat.com> On 3/2/20 10:46 PM, Volker Simonis wrote: > As lead of the 8 and 11 update projects you probably know best, if this fix > will eventually be considered for backporting and choose your means wisely > :) Yeah, I know. Srsly. :-) But one of the few things of which I am certain is that we must not allow the needs of backporting to determine the future of Java. That's the way of staying in the past. As Patrick Head put it, ?Some people tell me that Formula 1 would be better if the drivers still used stick shifts, but that?s a bit like saying, 'isn?t it a pity we don?t still walk around in clogs!'? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Tue Mar 3 10:22:25 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Mar 2020 11:22:25 +0100 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <4081af4f-372d-911e-840b-de97847cba3a@redhat.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2310d10b-64ec-5680-a780-71138252a259@oracle.com> <3e097a38-2bad-0fa2-e16a-993a4a2718e5@oracle.com> <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> <4081af4f-372d-911e-840b-de97847cba3a@redhat.com> Message-ID: On Tue, Mar 3, 2020 at 10:26 AM Andrew Haley wrote: > > On 3/2/20 10:46 PM, Volker Simonis wrote: > > > As lead of the 8 and 11 update projects you probably know best, if this fix > > will eventually be considered for backporting and choose your means wisely > > :) > > Yeah, I know. Srsly. :-) > > But one of the few things of which I am certain is that we must not > allow the needs of backporting to determine the future of Java. That's > the way of staying in the past. > > As Patrick Head put it, ?Some people tell me that Formula 1 would be > better if the drivers still used stick shifts, but that?s a bit like > saying, 'isn?t it a pity we don?t still walk around in clogs!'? > Totally agree. > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From volker.simonis at gmail.com Tue Mar 3 10:27:20 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Mar 2020 11:27:20 +0100 Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly In-Reply-To: <192690F5-D7CF-4180-80D4-89EE7034DB1E@oracle.com> References: <192690F5-D7CF-4180-80D4-89EE7034DB1E@oracle.com> Message-ID: Thanks for the review Martin, Lance. On Mon, Mar 2, 2020 at 5:30 PM Lance Andersen wrote: > > I think the revised patch looks fine > > On Mar 2, 2020, at 10:15 AM, Volker Simonis wrote: > > On Fri, Feb 28, 2020 at 8:02 PM Martin Buchholz wrote: > > > Welcome to the troublesome world of zip implementations! > > > Well, not many remember that the zip format was designed to work > efficiently with floppy discs :) > > It looks like by creating a new JarEntry you are discarding possible information from the old one, e.g. you might be discarding whether the input entry was compressed. If "jar u" does that, I would consider it a bug! > > > You're right. My fix was a little to simple, and can be improved: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235.01 > > Preserving the time, comment, extra information, compression method > and size/CRC if the compression method was "stored" is the best we can > do. And this is actually exactly what "jar -" does (see [1]). > > [1] http://hg.openjdk.java.net/jdk/jdk/file/e04746cec89c/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#l934 > > Arguably there is a missing API that would allow you to copy zip entries from an input to an output completely intact, without having to decompress and recompress. (might be hard to design!) > > > Yes, I did think about this as well. It might not be that hard at all. > We could simply add readRawEntry()/wrtiteRawEntry() methods to > ZipInputStream/ZipOutputStream. We'd have to tweak > ZipOutputStream.closeEntry() such that it can handle such "raw" writes > (e.g. it wouldn't be able to check the CRC any more) and various > methods like "skip()" in ZipInputStream. I think this might be > interesting not only because it would allow updating zip-files without > changing untouched entries, but also because it will considerably > improve the speed of updating (i.e. we would save the time for > repeatedly inflating and deflating). I'm not sure though how frequent > the use-case of updating a zip-file really is? > > But that would definitely be a larger enhancement with SE scope. Do > you think it's worth it? > > Probably there should be no such utility method as updateJarFile at all. Perhaps instead the jar/zip code could be refactored so that tests can reuse the same code used by "jar u". > > > I'll leave that as an extra improvement for others :) > > On Fri, Feb 28, 2020 at 10:50 AM Volker Simonis wrote: > > > Hi, > > can I please have a review for this small test fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235/ > https://bugs.openjdk.java.net/browse/JDK-8240235 > > JarUtils.updateJar() and JarUtils.updateJarFile() update jar files by > reading JarEntry-s from a source jar file and writing these exact > JarEntry-s to the destination jar file followed be the inflated and > re-deflated data belonging to this entry. > > This approach is not correct, because JarEntry contains both, the > compressed and uncompressed size of the corresponding entry. But the > original Defalter which initially compressed that entry can be either > different from the current one or it might have used a different > compression level compared to the current Deflater which re-deflates > the entry data. > > When the newly created entry is closed, the new compressed size will > be checked against the original compressed size if that was recorded > in the JarEntry and an exception will be thrown, when they differ: > > java.util.zip.ZipException: invalid entry compressed size (expected > 237 but got 238 bytes) > at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) > at java.base/java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:192) > at java.base/java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:108) > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:294) > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:252) > at HasUnsignedEntryTest.start(HasUnsignedEntryTest.java:77) > at HasUnsignedEntryTest.main(HasUnsignedEntryTest.java:44) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:832) > Suppressed: java.util.zip.ZipException: invalid entry > compressed size (expected 237 but got 238 bytes) > at > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) > at > java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) > at > java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237) > at > java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:280) > > The fix is trivial. Instead of copying the JarEntry-s verbatim to the > output stream, simply write newly created JarEntry-s to the output > stream which only contain the entry name. This is also the way how > this is handled by the jar tool, when it updates jar files. > > Thank you and best regards, > Volker > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From adam.farley at uk.ibm.com Tue Mar 3 10:43:08 2020 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 3 Mar 2020 10:43:08 +0000 Subject: RFR: 8239365: ProcessBuilder/Basic.java test modifications for AIX execution Message-ID: Hi All, Reviews and sponsor requested for a small test change. Short version: When an AIX machine has the file set "bos.msg.en_US.rte", the error messages are not in a form that the test expects, causing failure. The simplest option appears to be adding the second potential form of the message into the regex (see webrev). http://cr.openjdk.java.net/~afarley/8239365.1/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8239365 Best Regards Adam Farley IBM Runtimes Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From thomas.stuefe at gmail.com Tue Mar 3 10:52:10 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 3 Mar 2020 11:52:10 +0100 Subject: RFR: 8239365: ProcessBuilder/Basic.java test modifications for AIX execution In-Reply-To: References: Message-ID: This is why I always was against handing up the result of strerror to the user :) The same problem we would have when running with different locales. We should have a platform agnostic string table in the java lib for that purpose... As for the test, looks good, but I personally would shorten the AIX patterns a bit or maybe try to find a short form fitting all platforms (e.g. "[Pp]ermission"). But thats just idle bikeshedding, lets see what others think. Cheers Thomas On Tue, Mar 3, 2020 at 11:43 AM Adam Farley8 wrote: > Hi All, > > Reviews and sponsor requested for a small test change. > > Short version: When an AIX machine has the file set "bos.msg.en_US.rte", > the error messages are not in a form that the test expects, causing > failure. > > The simplest option appears to be adding the second potential form of the > message into the regex (see webrev). > > http://cr.openjdk.java.net/~afarley/8239365.1/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8239365 > > Best Regards > > Adam Farley > IBM Runtimes > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > From vipinmv1 at in.ibm.com Tue Mar 3 10:53:44 2020 From: vipinmv1 at in.ibm.com (Vipin Mv1) Date: Tue, 3 Mar 2020 10:53:44 +0000 Subject: RFR 8129841 Update comment for Java_java_net_Inet6AddressImpl_getHostByAddr Message-ID: Hi All, Please find the below changes for the issue https://bugs.openjdk.java.net/browse/JDK-8129841. Apart from the requested changes, I have made additional changes to the Signature where ever I found it incorrect. Thanks Vipin M V diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet4AddressImpl.c --- a/src/java.base/unix/native/libnet/Inet4AddressImpl.c Wed Feb 05 12:20:36 2020 -0300 +++ b/src/java.base/unix/native/libnet/Inet4AddressImpl.c Tue Mar 03 15:32:21 2020 +0530 @@ -218,7 +218,7 @@ /* * Class: java_net_Inet4AddressImpl * Method: getHostByAddr - * Signature: (I)Ljava/lang/String; + * Signature: ([B)Ljava/lang/String; * * Theoretically the UnknownHostException could be enriched with gai error * information. But as it is silently ignored anyway, there's no need for this. diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet6AddressImpl.c --- a/src/java.base/unix/native/libnet/Inet6AddressImpl.c Wed Feb 05 12:20:36 2020 -0300 +++ b/src/java.base/unix/native/libnet/Inet6AddressImpl.c Tue Mar 03 15:32:21 2020 +0530 @@ -413,7 +413,7 @@ /* * Class: java_net_Inet6AddressImpl * Method: getHostByAddr - * Signature: (I)Ljava/lang/String; + * Signature: ([B)Ljava/lang/String; * * Theoretically the UnknownHostException could be enriched with gai error * information. But as it is silently ignored anyway, there's no need for this. @@ -668,7 +668,7 @@ /* * Class: java_net_Inet6AddressImpl * Method: isReachable0 - * Signature: ([bII[bI)Z + * Signature: ([BII[BII)Z */ JNIEXPORT jboolean JNICALL Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this, diff -r 387369ff21a4 src/java.base/windows/native/libnet/Inet4AddressImpl.c --- a/src/java.base/windows/native/libnet/Inet4AddressImpl.c Wed Feb 05 12:20:36 2020 -0300 +++ b/src/java.base/windows/native/libnet/Inet4AddressImpl.c Tue Mar 03 15:32:21 2020 +0530 @@ -171,7 +171,7 @@ /* * Class: java_net_Inet4AddressImpl * Method: getHostByAddr - * Signature: (I)Ljava/lang/String; + * Signature: ([B)Ljava/lang/String; * * Theoretically the UnknownHostException could be enriched with gai error * information. But as it is silently ignored anyway, there's no need for this. diff -r 387369ff21a4 src/java.base/windows/native/libnet/Inet6AddressImpl.c --- a/src/java.base/windows/native/libnet/Inet6AddressImpl.c Wed Feb 05 12:20:36 2020 -0300 +++ b/src/java.base/windows/native/libnet/Inet6AddressImpl.c Tue Mar 03 15:32:21 2020 +0530 @@ -240,7 +240,7 @@ /* * Class: java_net_Inet6AddressImpl * Method: getHostByAddr - * Signature: (I)Ljava/lang/String; + * Signature: ([B)Ljava/lang/String; * * Theoretically the UnknownHostException could be enriched with gai error * information. But as it is silently ignored anyway, there's no need for this. @@ -435,7 +435,7 @@ /* * Class: java_net_Inet6AddressImpl * Method: isReachable0 - * Signature: ([bII[bI)Z + * Signature: ([BII[BII)Z */ JNIEXPORT jboolean JNICALL Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this, From volker.simonis at gmail.com Tue Mar 3 11:01:47 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Mar 2020 12:01:47 +0100 Subject: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing Message-ID: Hi, can I please get a review for the following small fix: http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/ https://bugs.openjdk.java.net/browse/JDK-8240333 The "jmod" tool needs to update .jar files as well as .jmod files when adding hashes to the module-info file. This is handled in the method jdk.tools.jmod.JmodTask.updateModularJar() for modular jar files and in the methods jdk.tools.jmod.JmodTask.updateJmodFile() and jdk.tools.jmod.JmodOutputStream.writeEntry() for .jmod files. Unfortunately, both implementations are incorrect because they are writing the JarEntry/ZipEntry entries which they reading from the ZipInputStream verbatim to the ZipOutputStream. This approach is not correct, because Zip/Entry/JarEntry contains both, the compressed and uncompressed size of the corresponding entry. But the original Deflater which initially compressed that entry can be either different from the current one or it might have used a different compression level compared to the current Deflater which re-deflates the entry data. When the newly created entry is closed, the new compressed size will be checked against the original compressed size if that was recorded in the ZipEntry/JarEntry entry and an exception will be thrown, when they differ. For modular jar files it looks as follows: $ jmod hash --module-path . --hash-modules .* Error: java.util.zip.ZipException: invalid entry compressed size (expected 58 but got 57 bytes) java.io.UncheckedIOException: java.util.zip.ZipException: invalid entry compressed size (expected 58 but got 57 bytes) at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:995) at java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571) at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326) at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:980) at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModuleInfo(JmodTask.java:957) at jdk.jlink/jdk.tools.jmod.JmodTask.lambda$hashModules$3(JmodTask.java:300) at java.base/java.util.HashMap.forEach(HashMap.java:1425) at jdk.jlink/jdk.tools.jmod.JmodTask.hashModules(JmodTask.java:291) at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:220) at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34) Suppressed: java.util.zip.ZipException: invalid entry compressed size (expected 58 but got 57 bytes) at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) at java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) at java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237) at java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:976) ... 6 more Caused by: java.util.zip.ZipException: invalid entry compressed size (expected 58 but got 57 bytes) at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:992) ... 10 more For jmod files it looks like this: $ jmod hash --module-path . --hash-modules .* Error: java.util.zip.ZipException: invalid entry compressed size (expected 383 but got 377 bytes) java.io.UncheckedIOException: java.util.zip.ZipException: invalid entry compressed size (expected 383 but got 377 bytes) at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateJmodFile$4(JmodTask.java:1021) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571) at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateJmodFile(JmodTask.java:1009) at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModuleInfo(JmodTask.java:955) at jdk.jlink/jdk.tools.jmod.JmodTask.lambda$hashModules$3(JmodTask.java:300) at java.base/java.util.HashMap.forEach(HashMap.java:1425) at jdk.jlink/jdk.tools.jmod.JmodTask.hashModules(JmodTask.java:291) at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:220) at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34) Suppressed: java.util.zip.ZipException: invalid entry compressed size (expected 383 but got 377 bytes) at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) at java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) at java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237) at java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) at jdk.jlink/jdk.tools.jmod.JmodOutputStream.close(JmodOutputStream.java:114) at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateJmodFile(JmodTask.java:1006) ... 6 more Caused by: java.util.zip.ZipException: invalid entry compressed size (expected 383 but got 377 bytes) at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) at jdk.jlink/jdk.tools.jmod.JmodOutputStream.writeEntry(JmodOutputStream.java:97) at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateJmodFile$4(JmodTask.java:1018) ... 17 more The errors can be provoked by creating the initial jar or jmod files with a different zlib implementation (e.g. LD_LIBRARY_PATH=/ziptests/build/zlib-cloudflare jar -cf ../mb_cf.jar *) The fix is simple. Instead of copying the ZipEntry/JarEntry entries verbatim to the output stream, simply write newly created ZipEntry entries to the output stream which only contain the required attributes. This is also the way how this is done by the jar tool, when it updates jar files. For the modular jar file case, creating a new entry is not feasible, because at that specific location we are dealing with JerEntry entries which can contain additional information. Unfortunately, it is not possible to set this information on a newly created JarEntry entry. But we can still reset the "compressedSize" of the JarEntry to "-1" which also prevents the additional check after the entry has been written. Thank you and best regards, Volker PS: and by the way, this is the last bug related to the wrong usage of ZipOutputSream.putNextEntry() within the OpenJDK :) I've scanned all the sources and couldn't find any other suspicious places. From Roger.Riggs at oracle.com Tue Mar 3 15:02:24 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 3 Mar 2020 10:02:24 -0500 Subject: RFR: 8239365: ProcessBuilder/Basic.java test modifications for AIX execution In-Reply-To: References: Message-ID: Hi Adam, It doesn't look like you saw my comments from 2/21. Please take another look. http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-February/064878.html Roger On 3/3/20 5:43 AM, Adam Farley8 wrote: > Hi All, > > Reviews and sponsor requested for a small test change. > > Short version: When an AIX machine has the file set "bos.msg.en_US.rte", > the error messages are not in a form that the test expects, causing > failure. > > The simplest option appears to be adding the second potential form of the > message into the regex (see webrev). > > http://cr.openjdk.java.net/~afarley/8239365.1/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8239365 > > Best Regards > > Adam Farley > IBM Runtimes > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From martinrb at google.com Tue Mar 3 16:00:26 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 3 Mar 2020 08:00:26 -0800 Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly In-Reply-To: References: Message-ID: For the truly desperate in search of a spam folder, recent emails from google.com can be viewed here: https://openjdk.markmail.org/search/?q=from%3Agoogle.com%20date%3A2020- On Mon, Mar 2, 2020 at 11:15 PM Langer, Christoph wrote: > Hi Volker, > > sure, looks good. Unfortunately I don't get the mails from Martin ? > > Cheers > Christoph > > > -----Original Message----- > > From: Volker Simonis > > Sent: Montag, 2. M?rz 2020 16:17 > > To: Langer, Christoph > > Cc: Java Core Libs > > Subject: Re: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar > files > > incorrectly > > > > Hi Christoph, > > > > thanks for looking at my change. I've slightly improved the > > implementation as suggested by Martin to preserve all the zip > > attributes which can be preserved. Still fine for you? > > > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235.01 > > > > On Sun, Mar 1, 2020 at 9:21 PM Langer, Christoph > > wrote: > > > > > > Hi Volker, > > > > > > this looks good to me. > > > > > > Best regards > > > Christoph > > > > > > > -----Original Message----- > > > > From: core-libs-dev On > > Behalf > > > > Of Volker Simonis > > > > Sent: Freitag, 28. Februar 2020 19:48 > > > > To: Java Core Libs > > > > Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar > files > > incorrectly > > > > > > > > Hi, > > > > > > > > can I please have a review for this small test fix: > > > > > > > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235/ > > > > https://bugs.openjdk.java.net/browse/JDK-8240235 > > > > > > > > JarUtils.updateJar() and JarUtils.updateJarFile() update jar files by > > > > reading JarEntry-s from a source jar file and writing these exact > > > > JarEntry-s to the destination jar file followed be the inflated and > > > > re-deflated data belonging to this entry. > > > > > > > > This approach is not correct, because JarEntry contains both, the > > > > compressed and uncompressed size of the corresponding entry. But the > > > > original Defalter which initially compressed that entry can be either > > > > different from the current one or it might have used a different > > > > compression level compared to the current Deflater which re-deflates > > > > the entry data. > > > > > > > > When the newly created entry is closed, the new compressed size will > > > > be checked against the original compressed size if that was recorded > > > > in the JarEntry and an exception will be thrown, when they differ: > > > > > > > > java.util.zip.ZipException: invalid entry compressed size (expected > > > > 237 but got 238 bytes) > > > > at > > > > > > > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:26 > > > > 7) > > > > at > > > > > > java.base/java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java > > > > :192) > > > > at > > > > > > java.base/java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java > > > > :108) > > > > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:294) > > > > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:252) > > > > at HasUnsignedEntryTest.start(HasUnsignedEntryTest.java:77) > > > > at HasUnsignedEntryTest.main(HasUnsignedEntryTest.java:44) > > > > at > > > > > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > > > Method) > > > > at > > > > > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet > > > > hodAccessorImpl.java:62) > > > > at > > > > > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega > > > > tingMethodAccessorImpl.java:43) > > > > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > > > > at > > > > > > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp > > > > er.java:127) > > > > at java.base/java.lang.Thread.run(Thread.java:832) > > > > Suppressed: java.util.zip.ZipException: invalid entry > > > > compressed size (expected 237 but got 238 bytes) > > > > at > > > > > > > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:26 > > > > 7) > > > > at > > > > > > java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) > > > > at > > > > > > > java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.ja > > > > va:237) > > > > at > > > > > java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) > > > > at > jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:280) > > > > > > > > The fix is trivial. Instead of copying the JarEntry-s verbatim to the > > > > output stream, simply write newly created JarEntry-s to the output > > > > stream which only contain the entry name. This is also the way how > > > > this is handled by the jar tool, when it updates jar files. > > > > > > > > Thank you and best regards, > > > > Volker > From martinrb at google.com Tue Mar 3 16:20:30 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 3 Mar 2020 08:20:30 -0800 Subject: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing In-Reply-To: References: Message-ID: Looks Good To Me ... except you should fix that "delfated" typo. Those looking for a zip implementation career path can try to fix up all the compressedSize in the local headers so that they are correctly filled in. Which is hard because you don't know the compressedSize when you are writing the local entry header with putNextEntry. On Tue, Mar 3, 2020 at 3:02 AM Volker Simonis wrote: > Hi, > > can I please get a review for the following small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/ > https://bugs.openjdk.java.net/browse/JDK-8240333 > > The "jmod" tool needs to update .jar files as well as .jmod files when > adding hashes to the module-info file. This is handled in the method > jdk.tools.jmod.JmodTask.updateModularJar() for modular jar files and > in the methods jdk.tools.jmod.JmodTask.updateJmodFile() and > jdk.tools.jmod.JmodOutputStream.writeEntry() for .jmod files. > > Unfortunately, both implementations are incorrect because they are > writing the JarEntry/ZipEntry entries which they reading from the > ZipInputStream verbatim to the ZipOutputStream. This approach is not > correct, because Zip/Entry/JarEntry contains both, the compressed and > uncompressed size of the corresponding entry. But the original > Deflater which initially compressed that entry can be either different > from the current one or it might have used a different compression > level compared to the current Deflater which re-deflates the entry > data. > > When the newly created entry is closed, the new compressed size will > be checked against the original compressed size if that was recorded > in the ZipEntry/JarEntry entry and an exception will be thrown, when > they differ. For modular jar files it looks as follows: > > $ jmod hash --module-path . --hash-modules .* > Error: java.util.zip.ZipException: invalid entry compressed size > (expected 58 but got 57 bytes) > java.io.UncheckedIOException: java.util.zip.ZipException: invalid > entry compressed size (expected 58 but got 57 bytes) > at > jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:995) > at > java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571) > at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) > at > jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:980) > at > jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModuleInfo(JmodTask.java:957) > at > jdk.jlink/jdk.tools.jmod.JmodTask.lambda$hashModules$3(JmodTask.java:300) > at java.base/java.util.HashMap.forEach(HashMap.java:1425) > at jdk.jlink/jdk.tools.jmod.JmodTask.hashModules(JmodTask.java:291) > at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:220) > at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34) > Suppressed: java.util.zip.ZipException: invalid entry compressed size > (expected 58 but got 57 bytes) > at > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) > at java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) > at > java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237) > at java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) > at > jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:976) > ... 6 more > Caused by: java.util.zip.ZipException: invalid entry compressed size > (expected 58 but got 57 bytes) > at > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) > at > jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:992) > ... 10 more > > For jmod files it looks like this: > > $ jmod hash --module-path . --hash-modules .* > Error: java.util.zip.ZipException: invalid entry compressed size > (expected 383 but got 377 bytes) > java.io.UncheckedIOException: java.util.zip.ZipException: invalid > entry compressed size (expected 383 but got 377 bytes) > at > jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateJmodFile$4(JmodTask.java:1021) > at > java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) > at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at > java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571) > at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at > java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) > at > java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at > java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) > at > jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateJmodFile(JmodTask.java:1009) > at > jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModuleInfo(JmodTask.java:955) > at > jdk.jlink/jdk.tools.jmod.JmodTask.lambda$hashModules$3(JmodTask.java:300) > at java.base/java.util.HashMap.forEach(HashMap.java:1425) > at jdk.jlink/jdk.tools.jmod.JmodTask.hashModules(JmodTask.java:291) > at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:220) > at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34) > Suppressed: java.util.zip.ZipException: invalid entry compressed size > (expected 383 but got 377 bytes) > at > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) > at java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) > at > java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237) > at java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) > at > jdk.jlink/jdk.tools.jmod.JmodOutputStream.close(JmodOutputStream.java:114) > at > jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateJmodFile(JmodTask.java:1006) > ... 6 more > Caused by: java.util.zip.ZipException: invalid entry compressed size > (expected 383 but got 377 bytes) > at > java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) > at > jdk.jlink/jdk.tools.jmod.JmodOutputStream.writeEntry(JmodOutputStream.java:97) > at > jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateJmodFile$4(JmodTask.java:1018) > ... 17 more > > The errors can be provoked by creating the initial jar or jmod files > with a different zlib implementation (e.g. > LD_LIBRARY_PATH=/ziptests/build/zlib-cloudflare jar -cf ../mb_cf.jar > *) > > The fix is simple. Instead of copying the ZipEntry/JarEntry entries > verbatim to the output stream, simply write newly created ZipEntry > entries to the output stream which only contain the required > attributes. This is also the way how this is done by the jar tool, > when it updates jar files. > > For the modular jar file case, creating a new entry is not feasible, > because at that specific location we are dealing with JerEntry entries > which can contain additional information. Unfortunately, it is not > possible to set this information on a newly created JarEntry entry. > But we can still reset the "compressedSize" of the JarEntry to "-1" > which also prevents the additional check after the entry has been > written. > > Thank you and best regards, > Volker > > PS: and by the way, this is the last bug related to the wrong usage of > ZipOutputSream.putNextEntry() within the OpenJDK :) I've scanned all > the sources and couldn't find any other suspicious places. > From Alan.Bateman at oracle.com Tue Mar 3 16:27:16 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Mar 2020 16:27:16 +0000 Subject: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing In-Reply-To: References: Message-ID: <91a4dfc2-fc8e-b05b-6a9f-ef8012895e67@oracle.com> On 03/03/2020 11:01, Volker Simonis wrote: > Hi, > > can I please get a review for the following small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/ > https://bugs.openjdk.java.net/browse/JDK-8240333 > > The code changes okay but I think the comment needs a bit of clean-up. Maybe drop L96-97 so that it just says that it preserves the attributes that don't change. -Alan. From naoto.sato at oracle.com Tue Mar 3 16:27:42 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 3 Mar 2020 08:27:42 -0800 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: <640e6fe3-939d-1413-5d77-df8e949812f7@oracle.com> References: <0acbeef9-741a-f474-8980-4160441ba1d9@oracle.com> <3861e14e-0753-ae51-bd12-8839cbab30b6@oracle.com> <4b40de92-09cb-a88c-2f55-5f0b332a532f@oracle.com> <640e6fe3-939d-1413-5d77-df8e949812f7@oracle.com> Message-ID: Hi Joe, thanks for the review. Are you suggesting something like isFixedOffset() { return isFixedOffset; } Naoto On 3/2/20 11:20 PM, Joe Wang wrote: > Hi Naoto, > > The fix would be fine if you want to keep it as is since it does work. > > I noticed though that for standard zones (the ones loaded from tz > database), savingsInstantTransitions and standardTransitions are > consistent in that they are both empty for the standard zones, e.g. > Etc/GMT, and not empty for zones with a country/city id, including > countries that don't actually observe DST. This means a check for one of > them is enough for standard zones, which was done in the current > implementation (that is, isFixedOffset() returns > savingsInstantTransitions.length == 0). For custom ZoneRules created > with the "of" method, it would depend on whether they are set through > the relevant parameters (in the test case, the later was set but the > former was empty, that was why isFixedOffset was true). It would > therefore be possible to add and use a transient boolean field to > represent isFixedOffset. > > Just my two cents. > > -Joe > > On 3/2/20 10:37 AM, Roger Riggs wrote: >> Looks good. >> >> Give it a day to see if anyone else has comments. >> >> Thanks, Roger >> >> On 3/2/20 1:35 PM, naoto.sato at oracle.com wrote: >>> Hi Roger, thanks for the review. >>> >>> On 3/2/20 8:44 AM, Roger Riggs wrote: >>>> Hi Naoto, >>>> >>>> look ok. >>>> >>>> ZoneRules.java: 488, 644, 761, 791 >>>> I'd suggest calling isFixedOffset() instead of repeating the code: >>>> standardTransitions.length == 0 && savingsInstantTransitions.length >>>> == 0 >>> >>> Modified as suggested: >>> >>> http://cr.openjdk.java.net/~naoto/8239836/webrev.01/ >>> >>>> >>>> It should be inlined in cases where the performance matters. >>> >>> None of those locations is invoked during ZoneRules object >>> instantiation. So I believe it is OK to replace them with >>> isFixedOffset(). >>> >>> Naoto >>> >>>> >>>> Thanks, Roger >>>> >>>> >>>> On 2/27/20 3:41 PM, naoto.sato at oracle.com wrote: >>>>> Hello, >>>>> >>>>> Please review the fix to the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8239836 >>>>> >>>>> The proposed changeset is located at: >>>>> >>>>> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ >>>>> >>>>> It turned out that 'transitionList' is not necessarily a superset of >>>>> 'standardOffsetTransitionList', as in some occasions where a >>>>> standard offset change and a savings change happen at the same time >>>>> (canceling each other), resulting in no wall time transition. This >>>>> means that the "rules" in the sample code is a valid ZoneRules >>>>> instance. >>>>> >>>>> However, there is an assumption in ZoneRules where no (wall time) >>>>> transition means the fixed offset zone. With that assumption, the >>>>> example rule is considered a fixed offset zone which is not >>>>> correct. So the fix proposed here is not to throw an IAE but to >>>>> recognize the rule as a valid, non-fixed offset ZoneRules instance. >>>>> >>>>> Naoto >>>>> >>>>> >>>> >> > From Alan.Bateman at oracle.com Tue Mar 3 16:30:26 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Mar 2020 16:30:26 +0000 Subject: [11u] RFR: 8232854: URLClassLoader.close() doesn't close cached JAR file on Windows when load() fails In-Reply-To: References: <361f077a-6d89-6de4-c613-2fed37a4c269@redhat.com> Message-ID: <6afd9da0-ae54-37a9-d043-a3b468de1a7d@oracle.com> On 02/03/2020 20:44, Alex Kashchenko wrote: > > Yes, I can work on this issue for jdk/jdk. I found this part of code > complicated and would appreciate the guidance. > JDK-8132359 is the main issue (yes, JDK-8232854 is a bit confusing). I think Michael is looking into whether it needs to touch or the URLClassPath code or whether it can be fixed in the jar protocol handler. -Alan From huizhe.wang at oracle.com Tue Mar 3 16:59:31 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 3 Mar 2020 08:59:31 -0800 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: References: <0acbeef9-741a-f474-8980-4160441ba1d9@oracle.com> <3861e14e-0753-ae51-bd12-8839cbab30b6@oracle.com> <4b40de92-09cb-a88c-2f55-5f0b332a532f@oracle.com> <640e6fe3-939d-1413-5d77-df8e949812f7@oracle.com> Message-ID: <5b5e8fd0-0f99-9d90-29cd-b7229ed01e63@oracle.com> On 3/3/20 8:27 AM, naoto.sato at oracle.com wrote: > Hi Joe, thanks for the review. > > Are you suggesting something like > > isFixedOffset() { > ??? return isFixedOffset; > } Yes, something like that. It could be initiated while the rules is constructed. I feel it might be semantically clearer as transitions indirectly reflect that the offset is fixed. Your call. Best, Joe > > Naoto > > On 3/2/20 11:20 PM, Joe Wang wrote: >> Hi Naoto, >> >> The fix would be fine if you want to keep it as is since it does work. >> >> I noticed though that for standard zones (the ones loaded from tz >> database), savingsInstantTransitions and standardTransitions are >> consistent in that they are both empty for the standard zones, e.g. >> Etc/GMT, and not empty for zones with a country/city id, including >> countries that don't actually observe DST. This means a check for one >> of them is enough for standard zones, which was done in the current >> implementation (that is, isFixedOffset() returns >> savingsInstantTransitions.length == 0). For custom ZoneRules created >> with the "of" method, it would depend on whether they are set through >> the relevant parameters (in the test case, the later was set but the >> former was empty, that was why isFixedOffset was true). It would >> therefore be possible to add and use a transient boolean field to >> represent isFixedOffset. >> >> Just my two cents. >> >> -Joe >> >> On 3/2/20 10:37 AM, Roger Riggs wrote: >>> Looks good. >>> >>> Give it a day to see if anyone else has comments. >>> >>> Thanks, Roger >>> >>> On 3/2/20 1:35 PM, naoto.sato at oracle.com wrote: >>>> Hi Roger, thanks for the review. >>>> >>>> On 3/2/20 8:44 AM, Roger Riggs wrote: >>>>> Hi Naoto, >>>>> >>>>> look ok. >>>>> >>>>> ZoneRules.java: 488, 644, 761, 791 >>>>> I'd suggest calling isFixedOffset() instead of repeating the code: >>>>> standardTransitions.length == 0 && >>>>> savingsInstantTransitions.length == 0 >>>> >>>> Modified as suggested: >>>> >>>> http://cr.openjdk.java.net/~naoto/8239836/webrev.01/ >>>> >>>>> >>>>> It should be inlined in cases where the performance matters. >>>> >>>> None of those locations is invoked during ZoneRules object >>>> instantiation. So I believe it is OK to replace them with >>>> isFixedOffset(). >>>> >>>> Naoto >>>> >>>>> >>>>> Thanks, Roger >>>>> >>>>> >>>>> On 2/27/20 3:41 PM, naoto.sato at oracle.com wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the fix to the following issue: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8239836 >>>>>> >>>>>> The proposed changeset is located at: >>>>>> >>>>>> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ >>>>>> >>>>>> It turned out that 'transitionList' is not necessarily a superset of >>>>>> 'standardOffsetTransitionList', as in some occasions where a >>>>>> standard offset change and a savings change happen at the same >>>>>> time (canceling each other), resulting in no wall time >>>>>> transition. This means that the "rules" in the sample code is a >>>>>> valid ZoneRules instance. >>>>>> >>>>>> However, there is an assumption in ZoneRules where no (wall time) >>>>>> transition means the fixed offset zone. With that assumption, the >>>>>> example rule is considered a fixed offset zone which is not >>>>>> correct. So the fix proposed here is not to throw an IAE but to >>>>>> recognize the rule as a valid, non-fixed offset ZoneRules instance. >>>>>> >>>>>> Naoto >>>>>> >>>>>> >>>>> >>> >> From alexander.zuev at oracle.com Tue Mar 3 17:23:23 2020 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 3 Mar 2020 20:23:23 +0300 Subject: RFR: JDK-8238692: MacOS runtime Installer issue In-Reply-To: <18b6a598-2637-b2a0-2096-96ef206a42ca@oracle.com> References: <10d409ca-52b2-7521-b91d-04b90170aaad@oracle.com> <18b6a598-2637-b2a0-2096-96ef206a42ca@oracle.com> Message-ID: <10ed983f-8ab4-031f-3bf3-bd2c9643e2bf@oracle.com> Last version looks fine to me. /Alex On 2/21/20 20:10, Andy Herrick wrote: > After internal discussion of default values for mac-package-identifier > I have removed the fix for [3] from this main fix to issue [2]. > > please review the revised webrev at [1] > > /Andy > > On 2/18/2020 2:46 PM, Andy Herrick wrote: >> >> Please review the jpackage fix at [1] for the related issues [2], >> [3], and [4]. >> >> This will basically make pkg type runtime installers work on macosx, >> while we wait for JDK-8237971 to either fix or disable dmg type >> runtime installers. >> >> /Andy >> >> [1] http://cr.openjdk.java.net/~herrick/8238692/webrev.02/ >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8238692 >> >> [3] https://bugs.openjdk.java.net/browse/JDK-8237966 >> >> [4] https://bugs.openjdk.java.net/browse/JDK-8237970 >> >> >> From alexander.zuev at oracle.com Tue Mar 3 17:25:37 2020 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 3 Mar 2020 20:25:37 +0300 Subject: RFR: JDK-8237966,: Creating runtime pkg requires --mac-package-identifier In-Reply-To: <771e7b78-cd7d-2402-8094-e7add463e1b6@oracle.com> References: <771e7b78-cd7d-2402-8094-e7add463e1b6@oracle.com> Message-ID: <2724ca17-9dc8-592b-cd0d-fc9de0cd4f4d@oracle.com> Looks fine to me. /Alex On 2/26/20 20:48, Andy Herrick wrote: > Please review the fix to issue [1] at [2]. > > The initial concern with defaulting to the application or installer > name was that is might not be a valid mac package identifier (use only > alphanumeric, '.' , and '-' chars)? but this can be true when the id > is derived from main class (as in application case) or explicitly > specified (using --mac-package-identifier).? So this change now tests > it in any case. > > [1] https://bugs.openjdk.java.net/browse/JDK-8237966 > > [2] http://cr.openjdk.java.net/~herrick/8237966/webrev.01/ > > /Andy > From lance.andersen at oracle.com Tue Mar 3 18:00:01 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 3 Mar 2020 13:00:01 -0500 Subject: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing In-Reply-To: <91a4dfc2-fc8e-b05b-6a9f-ef8012895e67@oracle.com> References: <91a4dfc2-fc8e-b05b-6a9f-ef8012895e67@oracle.com> Message-ID: I think this all looks OK. I would consider the same comment clean-up in JmodTask.java as well Best Lance > On Mar 3, 2020, at 11:27 AM, Alan Bateman wrote: > > On 03/03/2020 11:01, Volker Simonis wrote: >> Hi, >> >> can I please get a review for the following small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/ >> https://bugs.openjdk.java.net/browse/JDK-8240333 >> >> > The code changes okay but I think the comment needs a bit of clean-up. Maybe drop L96-97 so that it just says that it preserves the attributes that don't change. > > -Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From volker.simonis at gmail.com Tue Mar 3 18:00:07 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Mar 2020 19:00:07 +0100 Subject: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing In-Reply-To: References: Message-ID: On Tue, Mar 3, 2020 at 5:20 PM Martin Buchholz wrote: > > Looks Good To Me ... except you should fix that "delfated" typo. > Thanks. Corrected the typo along with some comment shortening suggested by Alan: http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333.01/ > Those looking for a zip implementation career path :-)) > can try to fix up all the compressedSize in the local headers so that they are correctly filled in. Which is hard because you don't know the compressedSize when you are writing the local entry header with putNextEntry. > You can't know it be fore you are doing it :) > On Tue, Mar 3, 2020 at 3:02 AM Volker Simonis wrote: >> >> Hi, >> >> can I please get a review for the following small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/ >> https://bugs.openjdk.java.net/browse/JDK-8240333 >> >> The "jmod" tool needs to update .jar files as well as .jmod files when >> adding hashes to the module-info file. This is handled in the method >> jdk.tools.jmod.JmodTask.updateModularJar() for modular jar files and >> in the methods jdk.tools.jmod.JmodTask.updateJmodFile() and >> jdk.tools.jmod.JmodOutputStream.writeEntry() for .jmod files. >> >> Unfortunately, both implementations are incorrect because they are >> writing the JarEntry/ZipEntry entries which they reading from the >> ZipInputStream verbatim to the ZipOutputStream. This approach is not >> correct, because Zip/Entry/JarEntry contains both, the compressed and >> uncompressed size of the corresponding entry. But the original >> Deflater which initially compressed that entry can be either different >> from the current one or it might have used a different compression >> level compared to the current Deflater which re-deflates the entry >> data. >> >> When the newly created entry is closed, the new compressed size will >> be checked against the original compressed size if that was recorded >> in the ZipEntry/JarEntry entry and an exception will be thrown, when >> they differ. For modular jar files it looks as follows: >> >> $ jmod hash --module-path . --hash-modules .* >> Error: java.util.zip.ZipException: invalid entry compressed size >> (expected 58 but got 57 bytes) >> java.io.UncheckedIOException: java.util.zip.ZipException: invalid >> entry compressed size (expected 58 but got 57 bytes) >> at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:995) >> at java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571) >> at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326) >> at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) >> at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:980) >> at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModuleInfo(JmodTask.java:957) >> at jdk.jlink/jdk.tools.jmod.JmodTask.lambda$hashModules$3(JmodTask.java:300) >> at java.base/java.util.HashMap.forEach(HashMap.java:1425) >> at jdk.jlink/jdk.tools.jmod.JmodTask.hashModules(JmodTask.java:291) >> at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:220) >> at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34) >> Suppressed: java.util.zip.ZipException: invalid entry compressed size >> (expected 58 but got 57 bytes) >> at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) >> at java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) >> at java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237) >> at java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) >> at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:976) >> ... 6 more >> Caused by: java.util.zip.ZipException: invalid entry compressed size >> (expected 58 but got 57 bytes) >> at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) >> at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:992) >> ... 10 more >> >> For jmod files it looks like this: >> >> $ jmod hash --module-path . --hash-modules .* >> Error: java.util.zip.ZipException: invalid entry compressed size >> (expected 383 but got 377 bytes) >> java.io.UncheckedIOException: java.util.zip.ZipException: invalid >> entry compressed size (expected 383 but got 377 bytes) >> at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateJmodFile$4(JmodTask.java:1021) >> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) >> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) >> at java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571) >> at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326) >> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) >> at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) >> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) >> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) >> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) >> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) >> at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateJmodFile(JmodTask.java:1009) >> at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModuleInfo(JmodTask.java:955) >> at jdk.jlink/jdk.tools.jmod.JmodTask.lambda$hashModules$3(JmodTask.java:300) >> at java.base/java.util.HashMap.forEach(HashMap.java:1425) >> at jdk.jlink/jdk.tools.jmod.JmodTask.hashModules(JmodTask.java:291) >> at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:220) >> at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34) >> Suppressed: java.util.zip.ZipException: invalid entry compressed size >> (expected 383 but got 377 bytes) >> at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) >> at java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360) >> at java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237) >> at java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377) >> at jdk.jlink/jdk.tools.jmod.JmodOutputStream.close(JmodOutputStream.java:114) >> at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateJmodFile(JmodTask.java:1006) >> ... 6 more >> Caused by: java.util.zip.ZipException: invalid entry compressed size >> (expected 383 but got 377 bytes) >> at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) >> at jdk.jlink/jdk.tools.jmod.JmodOutputStream.writeEntry(JmodOutputStream.java:97) >> at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateJmodFile$4(JmodTask.java:1018) >> ... 17 more >> >> The errors can be provoked by creating the initial jar or jmod files >> with a different zlib implementation (e.g. >> LD_LIBRARY_PATH=/ziptests/build/zlib-cloudflare jar -cf ../mb_cf.jar >> *) >> >> The fix is simple. Instead of copying the ZipEntry/JarEntry entries >> verbatim to the output stream, simply write newly created ZipEntry >> entries to the output stream which only contain the required >> attributes. This is also the way how this is done by the jar tool, >> when it updates jar files. >> >> For the modular jar file case, creating a new entry is not feasible, >> because at that specific location we are dealing with JerEntry entries >> which can contain additional information. Unfortunately, it is not >> possible to set this information on a newly created JarEntry entry. >> But we can still reset the "compressedSize" of the JarEntry to "-1" >> which also prevents the additional check after the entry has been >> written. >> >> Thank you and best regards, >> Volker >> >> PS: and by the way, this is the last bug related to the wrong usage of >> ZipOutputSream.putNextEntry() within the OpenJDK :) I've scanned all >> the sources and couldn't find any other suspicious places. From volker.simonis at gmail.com Tue Mar 3 18:01:02 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Mar 2020 19:01:02 +0100 Subject: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing In-Reply-To: <91a4dfc2-fc8e-b05b-6a9f-ef8012895e67@oracle.com> References: <91a4dfc2-fc8e-b05b-6a9f-ef8012895e67@oracle.com> Message-ID: On Tue, Mar 3, 2020 at 5:27 PM Alan Bateman wrote: > > On 03/03/2020 11:01, Volker Simonis wrote: > > Hi, > > > > can I please get a review for the following small fix: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/ > > https://bugs.openjdk.java.net/browse/JDK-8240333 > > > > > The code changes okay but I think the comment needs a bit of clean-up. > Maybe drop L96-97 so that it just says that it preserves the attributes > that don't change. > Thanks. Shortened the comments as suggested: http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333.01/ OK, now? > -Alan. From volker.simonis at gmail.com Tue Mar 3 18:03:20 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Mar 2020 19:03:20 +0100 Subject: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing In-Reply-To: References: <91a4dfc2-fc8e-b05b-6a9f-ef8012895e67@oracle.com> Message-ID: Thanks Lance. I've just sent out an updated webrev with the shortened comments: http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333.01/ On Tue, Mar 3, 2020 at 7:00 PM Lance Andersen wrote: > > I think this all looks OK. I would consider the same comment clean-up in JmodTask.java as well > > Best > Lance > > On Mar 3, 2020, at 11:27 AM, Alan Bateman wrote: > > On 03/03/2020 11:01, Volker Simonis wrote: > > Hi, > > can I please get a review for the following small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/ > https://bugs.openjdk.java.net/browse/JDK-8240333 > > > The code changes okay but I think the comment needs a bit of clean-up. Maybe drop L96-97 so that it just says that it preserves the attributes that don't change. > > -Alan. > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Tue Mar 3 18:04:26 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 3 Mar 2020 13:04:26 -0500 Subject: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing In-Reply-To: References: <91a4dfc2-fc8e-b05b-6a9f-ef8012895e67@oracle.com> Message-ID: <67BB0A81-542A-4AF7-B4A5-F05E9F36F1D3@oracle.com> Looks good to me Thank you Volker > On Mar 3, 2020, at 1:03 PM, Volker Simonis wrote: > > Thanks Lance. > > I've just sent out an updated webrev with the shortened comments: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333.01/ > > > On Tue, Mar 3, 2020 at 7:00 PM Lance Andersen > wrote: >> >> I think this all looks OK. I would consider the same comment clean-up in JmodTask.java as well >> >> Best >> Lance >> >> On Mar 3, 2020, at 11:27 AM, Alan Bateman wrote: >> >> On 03/03/2020 11:01, Volker Simonis wrote: >> >> Hi, >> >> can I please get a review for the following small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/ >> https://bugs.openjdk.java.net/browse/JDK-8240333 >> >> >> The code changes okay but I think the comment needs a bit of clean-up. Maybe drop L96-97 so that it just says that it preserves the attributes that don't change. >> >> -Alan. >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Tue Mar 3 18:15:35 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 3 Mar 2020 10:15:35 -0800 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: <5b5e8fd0-0f99-9d90-29cd-b7229ed01e63@oracle.com> References: <0acbeef9-741a-f474-8980-4160441ba1d9@oracle.com> <3861e14e-0753-ae51-bd12-8839cbab30b6@oracle.com> <4b40de92-09cb-a88c-2f55-5f0b332a532f@oracle.com> <640e6fe3-939d-1413-5d77-df8e949812f7@oracle.com> <5b5e8fd0-0f99-9d90-29cd-b7229ed01e63@oracle.com> Message-ID: <3cff7c02-1897-7fde-3bba-018246671152@oracle.com> Thanks, Joe. Updated: http://cr.openjdk.java.net/~naoto/8239836/webrev.02/ Naoto On 3/3/20 8:59 AM, Joe Wang wrote: > > On 3/3/20 8:27 AM, naoto.sato at oracle.com wrote: >> Hi Joe, thanks for the review. >> >> Are you suggesting something like >> >> isFixedOffset() { >> ??? return isFixedOffset; >> } > > Yes, something like that. It could be initiated while the rules is > constructed. I feel it might be semantically clearer as transitions > indirectly reflect that the offset is fixed. Your call. > > Best, > Joe > >> >> Naoto >> >> On 3/2/20 11:20 PM, Joe Wang wrote: >>> Hi Naoto, >>> >>> The fix would be fine if you want to keep it as is since it does work. >>> >>> I noticed though that for standard zones (the ones loaded from tz >>> database), savingsInstantTransitions and standardTransitions are >>> consistent in that they are both empty for the standard zones, e.g. >>> Etc/GMT, and not empty for zones with a country/city id, including >>> countries that don't actually observe DST. This means a check for one >>> of them is enough for standard zones, which was done in the current >>> implementation (that is, isFixedOffset() returns >>> savingsInstantTransitions.length == 0). For custom ZoneRules created >>> with the "of" method, it would depend on whether they are set through >>> the relevant parameters (in the test case, the later was set but the >>> former was empty, that was why isFixedOffset was true). It would >>> therefore be possible to add and use a transient boolean field to >>> represent isFixedOffset. >>> >>> Just my two cents. >>> >>> -Joe >>> >>> On 3/2/20 10:37 AM, Roger Riggs wrote: >>>> Looks good. >>>> >>>> Give it a day to see if anyone else has comments. >>>> >>>> Thanks, Roger >>>> >>>> On 3/2/20 1:35 PM, naoto.sato at oracle.com wrote: >>>>> Hi Roger, thanks for the review. >>>>> >>>>> On 3/2/20 8:44 AM, Roger Riggs wrote: >>>>>> Hi Naoto, >>>>>> >>>>>> look ok. >>>>>> >>>>>> ZoneRules.java: 488, 644, 761, 791 >>>>>> I'd suggest calling isFixedOffset() instead of repeating the code: >>>>>> standardTransitions.length == 0 && >>>>>> savingsInstantTransitions.length == 0 >>>>> >>>>> Modified as suggested: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8239836/webrev.01/ >>>>> >>>>>> >>>>>> It should be inlined in cases where the performance matters. >>>>> >>>>> None of those locations is invoked during ZoneRules object >>>>> instantiation. So I believe it is OK to replace them with >>>>> isFixedOffset(). >>>>> >>>>> Naoto >>>>> >>>>>> >>>>>> Thanks, Roger >>>>>> >>>>>> >>>>>> On 2/27/20 3:41 PM, naoto.sato at oracle.com wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review the fix to the following issue: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8239836 >>>>>>> >>>>>>> The proposed changeset is located at: >>>>>>> >>>>>>> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ >>>>>>> >>>>>>> It turned out that 'transitionList' is not necessarily a superset of >>>>>>> 'standardOffsetTransitionList', as in some occasions where a >>>>>>> standard offset change and a savings change happen at the same >>>>>>> time (canceling each other), resulting in no wall time >>>>>>> transition. This means that the "rules" in the sample code is a >>>>>>> valid ZoneRules instance. >>>>>>> >>>>>>> However, there is an assumption in ZoneRules where no (wall time) >>>>>>> transition means the fixed offset zone. With that assumption, the >>>>>>> example rule is considered a fixed offset zone which is not >>>>>>> correct. So the fix proposed here is not to throw an IAE but to >>>>>>> recognize the rule as a valid, non-fixed offset ZoneRules instance. >>>>>>> >>>>>>> Naoto >>>>>>> >>>>>>> >>>>>> >>>> >>> > From huizhe.wang at oracle.com Tue Mar 3 18:50:22 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 3 Mar 2020 10:50:22 -0800 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: <3cff7c02-1897-7fde-3bba-018246671152@oracle.com> References: <0acbeef9-741a-f474-8980-4160441ba1d9@oracle.com> <3861e14e-0753-ae51-bd12-8839cbab30b6@oracle.com> <4b40de92-09cb-a88c-2f55-5f0b332a532f@oracle.com> <640e6fe3-939d-1413-5d77-df8e949812f7@oracle.com> <5b5e8fd0-0f99-9d90-29cd-b7229ed01e63@oracle.com> <3cff7c02-1897-7fde-3bba-018246671152@oracle.com> Message-ID: <439545cf-8396-8437-377d-88c6d6a3a622@oracle.com> Looks good to me. Thanks, Joe On 3/3/20 10:15 AM, naoto.sato at oracle.com wrote: > Thanks, Joe. Updated: > > http://cr.openjdk.java.net/~naoto/8239836/webrev.02/ > > Naoto > > On 3/3/20 8:59 AM, Joe Wang wrote: >> >> On 3/3/20 8:27 AM, naoto.sato at oracle.com wrote: >>> Hi Joe, thanks for the review. >>> >>> Are you suggesting something like >>> >>> isFixedOffset() { >>> ??? return isFixedOffset; >>> } >> >> Yes, something like that. It could be initiated while the rules is >> constructed. I feel it might be semantically clearer as transitions >> indirectly reflect that the offset is fixed. Your call. >> >> Best, >> Joe >> >>> >>> Naoto >>> >>> On 3/2/20 11:20 PM, Joe Wang wrote: >>>> Hi Naoto, >>>> >>>> The fix would be fine if you want to keep it as is since it does work. >>>> >>>> I noticed though that for standard zones (the ones loaded from tz >>>> database), savingsInstantTransitions and standardTransitions are >>>> consistent in that they are both empty for the standard zones, e.g. >>>> Etc/GMT, and not empty for zones with a country/city id, including >>>> countries that don't actually observe DST. This means a check for >>>> one of them is enough for standard zones, which was done in the >>>> current implementation (that is, isFixedOffset() returns >>>> savingsInstantTransitions.length == 0). For custom ZoneRules >>>> created with the "of" method, it would depend on whether they are >>>> set through the relevant parameters (in the test case, the later >>>> was set but the former was empty, that was why isFixedOffset was >>>> true). It would therefore be possible to add and use a transient >>>> boolean field to represent isFixedOffset. >>>> >>>> Just my two cents. >>>> >>>> -Joe >>>> >>>> On 3/2/20 10:37 AM, Roger Riggs wrote: >>>>> Looks good. >>>>> >>>>> Give it a day to see if anyone else has comments. >>>>> >>>>> Thanks, Roger >>>>> >>>>> On 3/2/20 1:35 PM, naoto.sato at oracle.com wrote: >>>>>> Hi Roger, thanks for the review. >>>>>> >>>>>> On 3/2/20 8:44 AM, Roger Riggs wrote: >>>>>>> Hi Naoto, >>>>>>> >>>>>>> look ok. >>>>>>> >>>>>>> ZoneRules.java: 488, 644, 761, 791 >>>>>>> I'd suggest calling isFixedOffset() instead of repeating the code: >>>>>>> standardTransitions.length == 0 && >>>>>>> savingsInstantTransitions.length == 0 >>>>>> >>>>>> Modified as suggested: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/8239836/webrev.01/ >>>>>> >>>>>>> >>>>>>> It should be inlined in cases where the performance matters. >>>>>> >>>>>> None of those locations is invoked during ZoneRules object >>>>>> instantiation. So I believe it is OK to replace them with >>>>>> isFixedOffset(). >>>>>> >>>>>> Naoto >>>>>> >>>>>>> >>>>>>> Thanks, Roger >>>>>>> >>>>>>> >>>>>>> On 2/27/20 3:41 PM, naoto.sato at oracle.com wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review the fix to the following issue: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8239836 >>>>>>>> >>>>>>>> The proposed changeset is located at: >>>>>>>> >>>>>>>> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ >>>>>>>> >>>>>>>> It turned out that 'transitionList' is not necessarily a >>>>>>>> superset of >>>>>>>> 'standardOffsetTransitionList', as in some occasions where a >>>>>>>> standard offset change and a savings change happen at the same >>>>>>>> time (canceling each other), resulting in no wall time >>>>>>>> transition. This means that the "rules" in the sample code is a >>>>>>>> valid ZoneRules instance. >>>>>>>> >>>>>>>> However, there is an assumption in ZoneRules where no (wall >>>>>>>> time) transition means the fixed offset zone. With that >>>>>>>> assumption, the example rule is considered a fixed offset zone >>>>>>>> which is not correct. So the fix proposed here is not to throw >>>>>>>> an IAE but to recognize the rule as a valid, non-fixed offset >>>>>>>> ZoneRules instance. >>>>>>>> >>>>>>>> Naoto >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> From Alan.Bateman at oracle.com Tue Mar 3 19:05:15 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Mar 2020 19:05:15 +0000 Subject: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing In-Reply-To: References: <91a4dfc2-fc8e-b05b-6a9f-ef8012895e67@oracle.com> Message-ID: <216e6211-0a4e-5905-d049-88a5d65cb687@oracle.com> On 03/03/2020 18:01, Volker Simonis wrote: > : > Thanks. Shortened the comments as suggested: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333.01/ > > OK, now? > Thanks, looks good to me. -Alan From alexey.semenyuk at oracle.com Tue Mar 3 21:49:31 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 3 Mar 2020 16:49:31 -0500 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2310d10b-64ec-5680-a780-71138252a259@oracle.com> <3e097a38-2bad-0fa2-e16a-993a4a2718e5@oracle.com> <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> <4081af4f-372d-911e-840b-de97847cba3a@redhat.com> Message-ID: How about C++11? I have a pending patch for jpackage that depends on C++11 features that I hesitate to pull in jdk15. - Alexey On 3/3/2020 5:22 AM, Volker Simonis wrote: > On Tue, Mar 3, 2020 at 10:26 AM Andrew Haley wrote: >> On 3/2/20 10:46 PM, Volker Simonis wrote: >> >>> As lead of the 8 and 11 update projects you probably know best, if this fix >>> will eventually be considered for backporting and choose your means wisely >>> :) >> Yeah, I know. Srsly. :-) >> >> But one of the few things of which I am certain is that we must not >> allow the needs of backporting to determine the future of Java. That's >> the way of staying in the past. >> >> As Patrick Head put it, ?Some people tell me that Formula 1 would be >> better if the drivers still used stick shifts, but that?s a bit like >> saying, 'isn?t it a pity we don?t still walk around in clogs!'? >> > Totally agree. > >> -- >> Andrew Haley (he/him) >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> https://keybase.io/andrewhaley >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> From scolebourne at joda.org Tue Mar 3 23:30:30 2020 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 3 Mar 2020 23:30:30 +0000 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: References: Message-ID: I fear more changes are needed here. 1) The code is isFixedOffset() is indeed wrong, but the fix is insufficient. The zone is fixed if baseStandardOffset=baseWallOffset and all three other lists are empty. A fixed offset rule is the equivalent of a ZoneOffset. See ZoneId.normalized() for the code that assumes that. 2) The code in getOffset(Instant) is wrong, but so is the proposed fix. The purpose of the if statement is to optimise the following few lines which refer to savingsInstantTransitions and wallOffsets. The code does have a bug as it should return the first wall offset. Corrected code: public ZoneOffset getOffset(Instant instant) { if (savingsInstantTransitions.length == 0) { return wallOffsets[0]; } With the correct definition of isFixedOffset() it becomes apparent that this if statement is in fact not related to the fixed offset. Currently this test case fails (a zone in DST for all eternity): ZoneRules rules = ZoneRules.of( ZoneOffset.ofHours(1), ZoneOffset.ofHours(2), Collections.emptyList(), Collections.emptyList(), Collections.emptyList()); assertEquals(rules.getStandardOffset(Instant.EPOCH), ZoneOffset.ofHours(1)); assertEquals(rules.getOffset(Instant.EPOCH), ZoneOffset.ofHours(2)); 3) The code in getStandardOffset(Instant) also has an error as it checks the wrong array. It should check standardTransitions as that is what is used in the following few lines. Corrected code: public ZoneOffset getStandardOffset(Instant instant) { if (standardTransitions.length == 0) { return standardOffsets[0]; } 4) The code in getOffsetInfo(LocalDateTime dt) has a similar fault. Since it protects savingsLocalTransitions, it should return wallOffsets[0]. 5) The code in getDaylightSavings(Instant instant) has an optimising if statement that should refer to isFixedOffset(). 6) Also, in the test. assertTrue(!rules.isFixedOffset()); should be assertFalse(rules.isFixedOffset()); The class has worked so far as every normal case has baseStandardOffset = baseWallOffset, even though it is conceptually valid for this not to be true. Stephen On Thu, 27 Feb 2020 at 20:42, wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8239836 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ > > It turned out that 'transitionList' is not necessarily a superset of > 'standardOffsetTransitionList', as in some occasions where a standard > offset change and a savings change happen at the same time (canceling > each other), resulting in no wall time transition. This means that the > "rules" in the sample code is a valid ZoneRules instance. > > However, there is an assumption in ZoneRules where no (wall time) > transition means the fixed offset zone. With that assumption, the > example rule is considered a fixed offset zone which is not correct. So > the fix proposed here is not to throw an IAE but to recognize the rule > as a valid, non-fixed offset ZoneRules instance. > > Naoto > > From kim.barrett at oracle.com Wed Mar 4 00:29:49 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Mar 2020 19:29:49 -0500 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2310d10b-64ec-5680-a780-71138252a259@oracle.com> <3e097a38-2bad-0fa2-e16a-993a4a2718e5@oracle.com> <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> <4081af4f-372d-911e-840b-de97847cba3a@redhat.com> Message-ID: <81CDF382-1442-4721-AEDD-4F3A051AF192@oracle.com> > On Mar 3, 2020, at 4:49 PM, Alexey Semenyuk wrote: > > How about C++11? I have a pending patch for jpackage that depends on C++11 features that I hesitate to pull in jdk15. The reasons for HotSpot (at least) not already being on C++14 (cost of switching over the Solaris Studio based platform) also apply to C++11. A big part of the work involves dealing with changes to the compilation model, the runtime libraries, and the ABI, all of which are part of Solaris Studio's transition from C++98 to C++11. From alexander.scherbatiy at bell-sw.com Wed Mar 4 10:20:42 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Wed, 4 Mar 2020 13:20:42 +0300 Subject: jpackage with a single java property Message-ID: Hello, CSR for JEP 343: Packaging Tool [1] has description for option value which consists of a list of strings: "If an option value is otherwise a list of strings, they must separated by space characters.? Since the shell would otherwise take them as separate? arguments, the list must be quoted. " For example: ? --java-options -server --java-options "--ea -Dfoo=bar" What about a single java property which value contains space characters (-Dfoo="bar 2")? Should it be possible to pass it in the way: --java-options -Dfoo="bar 2" or the whole property should be quoted like: --java-options "-Dfoo='bar 2'" [1] https://bugs.openjdk.java.net/browse/JDK-8213087 Thanks, Alexander. From aph at redhat.com Wed Mar 4 11:33:19 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 4 Mar 2020 11:33:19 +0000 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <179814ed-649b-93c4-1894-a0f16423d3d3@physik.fu-berlin.de> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2310d10b-64ec-5680-a780-71138252a259@oracle.com> <3e097a38-2bad-0fa2-e16a-993a4a2718e5@oracle.com> <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> <4081af4f-372d-911e-840b-de97847cba3a@redhat.com> <179814ed-649b-93c4-1894-a0f16423d3d3@physik.fu-berlin.de> Message-ID: On 3/3/20 10:18 PM, John Paul Adrian Glaubitz wrote: > On 3/3/20 10:26 AM, Andrew Haley wrote: >> But one of the few things of which I am certain is that we must not >> allow the needs of backporting to determine the future of Java. That's >> the way of staying in the past. > > Unpopular opinion: It's the enterprise customers that mainly pay for the > development of software, not the users of rolling release distributions. I don't think that's an unpopular opinion at all! It's why most of us who work on Java updates get paid. Continuing to depend on C++98 is not good for us in the long term. It means we're using an obsolete programming language, and that inevitably carries its own risks, and we miss opportunities to do things better. > I know that maintaining old stuff is boring but that's where the money > is made. Too many developers unfortunately seem to forget that. Seriously now, who are you talking about? We spend a tremendous amount of time and money maintaining old stuff. >> As Patrick Head put it, ?Some people tell me that Formula 1 would be >> better if the drivers still used stick shifts, but that?s a bit like >> saying, 'isn?t it a pity we don?t still walk around in clogs!'? > > Maintenance of stable software isn't done for nostalgic reasons, it's > because enterprise customers need a reliable and stable platform to > run their businesses on. A lot of businesses are still running on JDK-8 > for this reason. Yes, that's why we do it. > Running bleeding edge software might be an option for a single desktop > user, but not in an enterprise environment with thousands of users > or in a critical environment like the booking system of an airline. Bear in mind that, if people hadn't pressed forward after JDK 7, there wouldn't be a "legacy" JDK 8 to maintain. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Wed Mar 4 12:12:01 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Mar 2020 12:12:01 +0000 Subject: RFR 8129841 Update comment for Java_java_net_Inet6AddressImpl_getHostByAddr In-Reply-To: References: Message-ID: Hi Vipin, I'm forwarding this to net-dev where it should be reviewed. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Vipin Mv1 > Sent: Dienstag, 3. M?rz 2020 11:54 > To: core-libs-dev at openjdk.java.net > Subject: RFR 8129841 Update comment for > Java_java_net_Inet6AddressImpl_getHostByAddr > > Hi All, > > Please find the below changes for the issue > https://bugs.openjdk.java.net/browse/JDK-8129841. Apart from the > requested changes, I have made additional changes to the Signature where > ever I found it incorrect. > > > Thanks > Vipin M V > > > diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet4AddressImpl.c > --- a/src/java.base/unix/native/libnet/Inet4AddressImpl.c Wed Feb 05 > 12:20:36 2020 -0300 > +++ b/src/java.base/unix/native/libnet/Inet4AddressImpl.c Tue Mar 03 > 15:32:21 2020 +0530 > @@ -218,7 +218,7 @@ > /* > * Class: java_net_Inet4AddressImpl > * Method: getHostByAddr > - * Signature: (I)Ljava/lang/String; > + * Signature: ([B)Ljava/lang/String; > * > * Theoretically the UnknownHostException could be enriched with gai error > * information. But as it is silently ignored anyway, there's no need for this. > diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet6AddressImpl.c > --- a/src/java.base/unix/native/libnet/Inet6AddressImpl.c Wed Feb 05 > 12:20:36 2020 -0300 > +++ b/src/java.base/unix/native/libnet/Inet6AddressImpl.c Tue Mar 03 > 15:32:21 2020 +0530 > @@ -413,7 +413,7 @@ > /* > * Class: java_net_Inet6AddressImpl > * Method: getHostByAddr > - * Signature: (I)Ljava/lang/String; > + * Signature: ([B)Ljava/lang/String; > * > * Theoretically the UnknownHostException could be enriched with gai error > * information. But as it is silently ignored anyway, there's no need for this. > @@ -668,7 +668,7 @@ > /* > * Class: java_net_Inet6AddressImpl > * Method: isReachable0 > - * Signature: ([bII[bI)Z > + * Signature: ([BII[BII)Z > */ > JNIEXPORT jboolean JNICALL > Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this, > diff -r 387369ff21a4 > src/java.base/windows/native/libnet/Inet4AddressImpl.c > --- a/src/java.base/windows/native/libnet/Inet4AddressImpl.c Wed > Feb 05 12:20:36 2020 -0300 > +++ b/src/java.base/windows/native/libnet/Inet4AddressImpl.c Tue > Mar 03 15:32:21 2020 +0530 > @@ -171,7 +171,7 @@ > /* > * Class: java_net_Inet4AddressImpl > * Method: getHostByAddr > - * Signature: (I)Ljava/lang/String; > + * Signature: ([B)Ljava/lang/String; > * > * Theoretically the UnknownHostException could be enriched with gai error > * information. But as it is silently ignored anyway, there's no need for this. > diff -r 387369ff21a4 > src/java.base/windows/native/libnet/Inet6AddressImpl.c > --- a/src/java.base/windows/native/libnet/Inet6AddressImpl.c Wed > Feb 05 12:20:36 2020 -0300 > +++ b/src/java.base/windows/native/libnet/Inet6AddressImpl.c Tue > Mar 03 15:32:21 2020 +0530 > @@ -240,7 +240,7 @@ > /* > * Class: java_net_Inet6AddressImpl > * Method: getHostByAddr > - * Signature: (I)Ljava/lang/String; > + * Signature: ([B)Ljava/lang/String; > * > * Theoretically the UnknownHostException could be enriched with gai error > * information. But as it is silently ignored anyway, there's no need for this. > @@ -435,7 +435,7 @@ > /* > * Class: java_net_Inet6AddressImpl > * Method: isReachable0 > - * Signature: ([bII[bI)Z > + * Signature: ([BII[BII)Z > */ > JNIEXPORT jboolean JNICALL > Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this, > > From patrick.concannon at oracle.com Wed Mar 4 12:17:38 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Wed, 4 Mar 2020 12:17:38 +0000 Subject: Need bug id to remove the explicit type argument in test class In-Reply-To: References: Message-ID: Hi Vipin, Always happy to help someone who wants to contribute! I'll create the bug ID for you, and sponsor your fix. Kind regards, Patrick On 02/03/2020 19:33, Vipin Sharma wrote: > Hi, > > My OCA has been processed recently and I want to start Contributing to > OpenJDK. > > As a first fix, I would like to remove the explicit type argument in test > class test/jdk/java/lang/Boolean/MakeBooleanComparable.java to fix one > warning. > > The first line given below is the existing code and the second line is what > I am changing it to. > > List list = new ArrayList(); > List list = new ArrayList<>(); > > If this is not too small change to start with, could you please help me to > create a bug id against this so that I can create a patch and share. > > Regards, > Vipin From christoph.langer at sap.com Wed Mar 4 12:23:23 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Mar 2020 12:23:23 +0000 Subject: Need bug id to remove the explicit type argument in test class In-Reply-To: References: Message-ID: Hi Vipin, it's a really tiny thing but here you go: https://bugs.openjdk.java.net/browse/JDK-8240524 In the change you'll also need to update the copyright year. Maybe you find other places in these tests you want to update? Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Vipin Sharma > Sent: Montag, 2. M?rz 2020 20:34 > To: core-libs-dev at openjdk.java.net > Subject: Need bug id to remove the explicit type argument in test class > > Hi, > > My OCA has been processed recently and I want to start Contributing to > OpenJDK. > > As a first fix, I would like to remove the explicit type argument in test > class test/jdk/java/lang/Boolean/MakeBooleanComparable.java to fix one > warning. > > The first line given below is the existing code and the second line is what > I am changing it to. > > List list = new ArrayList(); > List list = new ArrayList<>(); > > If this is not too small change to start with, could you please help me to > create a bug id against this so that I can create a patch and share. > > Regards, > Vipin From sgehwolf at redhat.com Wed Mar 4 12:53:00 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 04 Mar 2020 13:53:00 +0100 Subject: PING: RFR(s): 8240189: [TESTBUG] Some cgroup tests are failing after JDK-8231111 In-Reply-To: <1625d0c224747641b553831bf4be7e7afefd3c8d.camel@redhat.com> References: <650F46E1-75E5-4FA3-AF6C-451431CE0ABE@oracle.com> <1625d0c224747641b553831bf4be7e7afefd3c8d.camel@redhat.com> Message-ID: <737b4f5966247977a3259bde33628d42c771394c.camel@redhat.com> Hi, I still need a *R*eview for this. Any takers? Thanks, Severin On Fri, 2020-02-28 at 14:52 +0100, Severin Gehwolf wrote: > Hi Bob, > > On Thu, 2020-02-27 at 15:04 -0500, Bob Vandette wrote: > > The updates look fine to me. > > Thanks for the review! > > > Have you scanned through all tests looking for ?.length? and [0] to > > see if we have any more cases that need updating? > > I have now and haven't found any places where it's incorrect. There are > legit cases which still remain after this patch. > > Thanks, > Severin > > > Bob. > > > > > > > On Feb 27, 2020, at 2:31 PM, Severin Gehwolf > > > wrote: > > > > > > Hi, > > > > > > Could somebody please review those test fixes for the Metrics > > > platform > > > tests? Some code paths are apparently not being executed on > > > "common" > > > platforms which didn't make those issues show up earlier :-/ I've > > > missed to update some hard-coded values to account for changes done > > > via > > > JDK-8231111. Matthias Baesken from SAP was kind enough to run this > > > through their testing and no more issues show up after this. Much > > > appreciated, Matthias! > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8240189 > > > webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8240189/01/webrev/ > > > > > > Testing: Docker tests on Linux x86_64 cgroups v1 and Linux cgroups > > > v2 > > > (no change). Additional testing done by SAP. All seems to look > > > good. > > > > > > Thoughts? > > > > > > Thanks, > > > Severin > > > From andy.herrick at oracle.com Wed Mar 4 13:04:51 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 4 Mar 2020 08:04:51 -0500 Subject: jpackage with a single java property In-Reply-To: References: Message-ID: <0aaeb3c4-0f1f-a108-e878-b65d62147a6f@oracle.com> A quick test shows me? that this form works fine: ??? --java-options "-Dfoo='bar 2'" where this form fails: ?? --java-options -Dfoo="bar 2" Initially I can see no reason both form shouldn't work, so this looks like a bug to me. /Andy On 3/4/2020 5:20 AM, Alexander Scherbatiy wrote: > Hello, > > CSR for JEP 343: Packaging Tool [1] has description for option value > which consists of a list of strings: > > "If an option value is otherwise a list of strings, they must > separated by space characters.? Since the shell would otherwise take > them as separate? arguments, the list must be quoted. " > > For example: > > ? --java-options -server --java-options "--ea -Dfoo=bar" > > > What about a single java property which value contains space > characters (-Dfoo="bar 2")? Should it be possible to pass it in the way: > > --java-options -Dfoo="bar 2" > > or the whole property should be quoted like: > > --java-options "-Dfoo='bar 2'" > > > [1] https://bugs.openjdk.java.net/browse/JDK-8213087 > > Thanks, > > Alexander. > > From kevin.rushforth at oracle.com Wed Mar 4 13:45:27 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 4 Mar 2020 05:45:27 -0800 Subject: jpackage with a single java property In-Reply-To: <0aaeb3c4-0f1f-a108-e878-b65d62147a6f@oracle.com> References: <0aaeb3c4-0f1f-a108-e878-b65d62147a6f@oracle.com> Message-ID: <4852b816-741a-85f0-456d-d373526d3c10@oracle.com> No, I doubt this is a bug. If the following worked: --java-options -Dfoo="bar 2" meaning if the entire string `-Dfoo=bar 2` was treated as a single argument, then the following would fail: --java-options "--ea -Dfoo=bar" since it would also be treated as a single argument rather than two separate args as intended. -- Kevin On 3/4/2020 5:04 AM, Andy Herrick wrote: > A quick test shows me? that this form works fine: > > ??? --java-options "-Dfoo='bar 2'" > > where this form fails: > > ?? --java-options -Dfoo="bar 2" > > Initially I can see no reason both form shouldn't work, so this looks > like a bug to me. > > /Andy > > > On 3/4/2020 5:20 AM, Alexander Scherbatiy wrote: >> Hello, >> >> CSR for JEP 343: Packaging Tool [1] has description for option value >> which consists of a list of strings: >> >> "If an option value is otherwise a list of strings, they must >> separated by space characters.? Since the shell would otherwise take >> them as separate? arguments, the list must be quoted. " >> >> For example: >> >> ? --java-options -server --java-options "--ea -Dfoo=bar" >> >> >> What about a single java property which value contains space >> characters (-Dfoo="bar 2")? Should it be possible to pass it in the way: >> >> --java-options -Dfoo="bar 2" >> >> or the whole property should be quoted like: >> >> --java-options "-Dfoo='bar 2'" >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8213087 >> >> Thanks, >> >> Alexander. >> >> From alexander.scherbatiy at bell-sw.com Wed Mar 4 14:24:51 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Wed, 4 Mar 2020 17:24:51 +0300 Subject: jpackage with a single java property In-Reply-To: <4852b816-741a-85f0-456d-d373526d3c10@oracle.com> References: <0aaeb3c4-0f1f-a108-e878-b65d62147a6f@oracle.com> <4852b816-741a-85f0-456d-d373526d3c10@oracle.com> Message-ID: From a user point of view the following provided java command line arguments are different: a="b c" (string "b c" is assigned to a) and "a=b c" (b is assigned to a and c is an additional option). But java command line arguments are indistinguishable in this case: > java Main a="b c" "a=b c" arg[0]='a=b c' arg[1]='a=b c' public class Main { public static void main(String[] args) { for (int i = 0; i < args.length; i++) { System.out.printf("arg[%d]='%s'%n", i, args[i]); } } } Thanks, Alexander. On 04.03.2020 16:45, Kevin Rushforth wrote: > No, I doubt this is a bug. If the following worked: > > --java-options -Dfoo="bar 2" > > meaning if the entire string `-Dfoo=bar 2` was treated as a single > argument, then the following would fail: > > --java-options "--ea -Dfoo=bar" > > since it would also be treated as a single argument rather than two > separate args as intended. > > -- Kevin > > > On 3/4/2020 5:04 AM, Andy Herrick wrote: >> A quick test shows me? that this form works fine: >> >> ??? --java-options "-Dfoo='bar 2'" >> >> where this form fails: >> >> ?? --java-options -Dfoo="bar 2" >> >> Initially I can see no reason both form shouldn't work, so this looks >> like a bug to me. >> >> /Andy >> >> >> On 3/4/2020 5:20 AM, Alexander Scherbatiy wrote: >>> Hello, >>> >>> CSR for JEP 343: Packaging Tool [1] has description for option value >>> which consists of a list of strings: >>> >>> "If an option value is otherwise a list of strings, they must >>> separated by space characters.? Since the shell would otherwise take >>> them as separate? arguments, the list must be quoted. " >>> >>> For example: >>> >>> ? --java-options -server --java-options "--ea -Dfoo=bar" >>> >>> >>> What about a single java property which value contains space >>> characters (-Dfoo="bar 2")? Should it be possible to pass it in the way: >>> >>> --java-options -Dfoo="bar 2" >>> >>> or the whole property should be quoted like: >>> >>> --java-options "-Dfoo='bar 2'" >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8213087 >>> >>> Thanks, >>> >>> Alexander. >>> >>> > From jai.forums2013 at gmail.com Wed Mar 4 14:54:06 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 4 Mar 2020 20:24:06 +0530 Subject: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start In-Reply-To: <02FEC2C4-365E-4EB1-BA4F-37D0C0CD13DD@oracle.com> References: <51EF8E30-12C0-4CDA-9E2E-79F250375567@oracle.com> <4256fa6d-cd3b-4852-72c6-7c9acbd8b489@gmail.com> <3B2A5184-B592-4F3F-80AF-5FCF8AF7035C@oracle.com> <1AE7AAAE-DA56-44AD-B932-AF7EF9F00BA9@oracle.com> <02FEC2C4-365E-4EB1-BA4F-37D0C0CD13DD@oracle.com> Message-ID: <36b7d7ef-6b37-f385-1fb8-50111b0b73cc@gmail.com> Hello Lance, On 28/02/20 2:41 am, Lance Andersen wrote: > Hi Christoph, > > I have cleaned up, re-vamped and added more coverage to the test. ?As > part of this I started to lay the foundation for removing some of the > duplicate code as part of continued clean up and enhanced coverage > going forward > > The revised webrev can be found > at:?http://cr.openjdk.java.net/~lancea/8211917/webrev.00/index.html This all looks good to me (of course, I'm not an official reviewer). The new base testcase for zipfs related testing is definitely going to help in future fixes/enhancements. I just had one question in there: +++ new/test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java ... + {Map.of("create", "true", "noCompression", "true"), + ZipEntry.STORED}, + {Map.of("create", "true", "noCompression", "false"), + ZipEntry.DEFLATED} From what I had read in the javadoc of the private method getDefaultCompressionMethod in jdk.nio.zipfs.ZipFileSystem, the "noCompression" property is only there for backward compatibility reasons and the new way of configuring this semantic is the use of "compressionMethod" property (with value of either STORED or DEFLATED). Is the use of "noCompression" in this base test class intentional or is it just a personal preference? I'm fine either way, but wanted to know if I should stick to this form in any future test cases. -Jaikiran From lance.andersen at oracle.com Wed Mar 4 16:55:54 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 4 Mar 2020 11:55:54 -0500 Subject: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start In-Reply-To: <36b7d7ef-6b37-f385-1fb8-50111b0b73cc@gmail.com> References: <51EF8E30-12C0-4CDA-9E2E-79F250375567@oracle.com> <4256fa6d-cd3b-4852-72c6-7c9acbd8b489@gmail.com> <3B2A5184-B592-4F3F-80AF-5FCF8AF7035C@oracle.com> <1AE7AAAE-DA56-44AD-B932-AF7EF9F00BA9@oracle.com> <02FEC2C4-365E-4EB1-BA4F-37D0C0CD13DD@oracle.com> <36b7d7ef-6b37-f385-1fb8-50111b0b73cc@gmail.com> Message-ID: Hi Jaikiran > On Mar 4, 2020, at 9:54 AM, Jaikiran Pai wrote: > > Hello Lance, > > On 28/02/20 2:41 am, Lance Andersen wrote: >> Hi Christoph, >> >> I have cleaned up, re-vamped and added more coverage to the test. As part of this I started to lay the foundation for removing some of the duplicate code as part of continued clean up and enhanced coverage going forward >> >> The revised webrev can be found at: http://cr.openjdk.java.net/~lancea/8211917/webrev.00/index.html This all looks good to me (of course, I'm not an official reviewer). The new base testcase for zipfs related testing is definitely going to help in future fixes/enhancements. > > I just had one question in there: > > +++ new/test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java > ... > + {Map.of("create", "true", "noCompression", "true"), > + ZipEntry.STORED}, > + {Map.of("create", "true", "noCompression", "false"), > + ZipEntry.DEFLATED} > > From what I had read in the javadoc of the private method getDefaultCompressionMethod in jdk.nio.zipfs.ZipFileSystem, > the "noCompression" property is only there for backward compatibility reasons and the new way > of configuring this semantic is the use of "compressionMethod" property (with value of either STORED > or DEFLATED). Is the use of "noCompression" in this base test class intentional or is it just a personal preference? > I'm fine either way, but wanted to know if I should stick to this form in any future test cases. Yes when I added formal support for some of the existing Zip FS properties, we decided to add compressionMethod as the formal property in the event additional compression methods were added in the future. So noCompression will always exist and this DataProvider is used in several tests so I left it as is. At some point I might change it, but really does not matter as there are other tests which specifically test the compressionMethod property. Best Lance > > -Jaikiran > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From takiguc at linux.vnet.ibm.com Wed Mar 4 17:18:53 2020 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 05 Mar 2020 02:18:53 +0900 Subject: RFR 8232161: Align some one-way conversion in MS950 charset with Windows In-Reply-To: <29c29ad7-a953-97a3-11eb-87ab612a323f@oracle.com> References: <29c29ad7-a953-97a3-11eb-87ab612a323f@oracle.com> Message-ID: Hello Naoto. I appreciate your comments. I applied following changes: * MS950.nr and TestMS950.java data were sorted by Unicode order * Added some comments into TestMS950.java * Change comment on MS950.map Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8232161 Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.02/ Thanks, Ichiroh Takiguchi On 2020-03-03 10:31, naoto.sato at oracle.com wrote: > Hi Takiguchi-san, > > A few comments: > > - I'd recommend sorting the entries in MS950.nr and test data in > TestMS950.java for readability. > > - Add some comment about the objective in the test. It'd be hard for > engineers who have no previous knowledge to these bytes. > > Naoto > > > > On 3/2/20 9:33 AM, Ichiroh Takiguchi wrote: >> Hello. >> >> Could you review the fix ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161 >> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.01/ >> >> CSR 8233385 [1] was approved. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8233385 >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. From alexey.semenyuk at oracle.com Wed Mar 4 17:40:04 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 4 Mar 2020 12:40:04 -0500 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <81CDF382-1442-4721-AEDD-4F3A051AF192@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2310d10b-64ec-5680-a780-71138252a259@oracle.com> <3e097a38-2bad-0fa2-e16a-993a4a2718e5@oracle.com> <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> <4081af4f-372d-911e-840b-de97847cba3a@redhat.com> <81CDF382-1442-4721-AEDD-4F3A051AF192@oracle.com> Message-ID: <968712b9-e9ad-9404-2d48-c3f408b13037@oracle.com> jpackage is not and not planned to be available on Solaris. It is only on Windows, Linux and Mac. Is this a sufficient argument to bring in the patch as is and not rework it to make C++98 compliant? According to the list of supported compilers [1] on platforms where jpackage is available they all support C++11 for several years already. [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms - Alexey On 3/3/2020 7:29 PM, Kim Barrett wrote: >> On Mar 3, 2020, at 4:49 PM, Alexey Semenyuk wrote: >> >> How about C++11? I have a pending patch for jpackage that depends on C++11 features that I hesitate to pull in jdk15. > The reasons for HotSpot (at least) not already being on C++14 (cost of > switching over the Solaris Studio based platform) also apply to C++11. > A big part of the work involves dealing with changes to the compilation > model, the runtime libraries, and the ABI, all of which are part of > Solaris Studio's transition from C++98 to C++11. > From naoto.sato at oracle.com Wed Mar 4 19:05:47 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 4 Mar 2020 11:05:47 -0800 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: References: Message-ID: <030ee6e9-34dd-5c83-f942-96f07161aaca@oracle.com> Hi Stephen, Thank you for the detailed explanation and correcting the implementation. I incorporated all the suggestions below, as well as adding a new test for isFixedOffset() implementation (with some clean-up): https://cr.openjdk.java.net/~naoto/8239836/webrev.03/ Please take a look at it. Naoto On 3/3/20 3:30 PM, Stephen Colebourne wrote: > I fear more changes are needed here. > > 1) The code is isFixedOffset() is indeed wrong, but the fix is > insufficient. The zone is fixed if baseStandardOffset=baseWallOffset > and all three other lists are empty. A fixed offset rule is the > equivalent of a ZoneOffset. See ZoneId.normalized() for the code that > assumes that. > > 2) The code in getOffset(Instant) is wrong, but so is the proposed > fix. The purpose of the if statement is to optimise the following few > lines which refer to savingsInstantTransitions and wallOffsets. The > code does have a bug as it should return the first wall offset. > Corrected code: > public ZoneOffset getOffset(Instant instant) { > if (savingsInstantTransitions.length == 0) { > return wallOffsets[0]; > } > With the correct definition of isFixedOffset() it becomes apparent > that this if statement is in fact not related to the fixed offset. > > Currently this test case fails (a zone in DST for all eternity): > ZoneRules rules = ZoneRules.of( > ZoneOffset.ofHours(1), > ZoneOffset.ofHours(2), > Collections.emptyList(), > Collections.emptyList(), > Collections.emptyList()); > assertEquals(rules.getStandardOffset(Instant.EPOCH), > ZoneOffset.ofHours(1)); > assertEquals(rules.getOffset(Instant.EPOCH), ZoneOffset.ofHours(2)); > > 3) The code in getStandardOffset(Instant) also has an error as it > checks the wrong array. It should check standardTransitions as that is > what is used in the following few lines. Corrected code: > public ZoneOffset getStandardOffset(Instant instant) { > if (standardTransitions.length == 0) { > return standardOffsets[0]; > } > > 4) The code in getOffsetInfo(LocalDateTime dt) has a similar fault. > Since it protects savingsLocalTransitions, it should return > wallOffsets[0]. > > 5) The code in getDaylightSavings(Instant instant) has an optimising > if statement that should refer to isFixedOffset(). > > 6) Also, in the test. > assertTrue(!rules.isFixedOffset()); > should be > assertFalse(rules.isFixedOffset()); > > The class has worked so far as every normal case has > baseStandardOffset = baseWallOffset, even though it is conceptually > valid for this not to be true. > > Stephen > > > > > On Thu, 27 Feb 2020 at 20:42, wrote: >> >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8239836 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ >> >> It turned out that 'transitionList' is not necessarily a superset of >> 'standardOffsetTransitionList', as in some occasions where a standard >> offset change and a savings change happen at the same time (canceling >> each other), resulting in no wall time transition. This means that the >> "rules" in the sample code is a valid ZoneRules instance. >> >> However, there is an assumption in ZoneRules where no (wall time) >> transition means the fixed offset zone. With that assumption, the >> example rule is considered a fixed offset zone which is not correct. So >> the fix proposed here is not to throw an IAE but to recognize the rule >> as a valid, non-fixed offset ZoneRules instance. >> >> Naoto >> >> From naoto.sato at oracle.com Wed Mar 4 19:31:07 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 4 Mar 2020 11:31:07 -0800 Subject: RFR 8232161: Align some one-way conversion in MS950 charset with Windows In-Reply-To: References: <29c29ad7-a953-97a3-11eb-87ab612a323f@oracle.com> Message-ID: <7173239a-e06c-5c9e-7c54-5fe373aa0b41@oracle.com> On 3/4/20 9:18 AM, Ichiroh Takiguchi wrote: > Hello Naoto. > > I appreciate your comments. > > I applied following changes: > * MS950.nr and TestMS950.java data were sorted by Unicode order > * Added some comments into TestMS950.java > * Change comment on MS950.map > > Could you review the fix ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161 > Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.02/ I'd expect the sort order to be aligned with other *.nr files, i.e., sorted by the source byte sequence. Same for the test case (TestMS950.java) and the comment in MS950.map. As to the test comment, how about adding something below to @summary line? "Those test data confirm the preferred b2c irreversible mappings defined in MS950.nr file." Naoto > > Thanks, > Ichiroh Takiguchi > > On 2020-03-03 10:31, naoto.sato at oracle.com wrote: >> Hi Takiguchi-san, >> >> A few comments: >> >> - I'd recommend sorting the entries in MS950.nr and test data in >> TestMS950.java for readability. >> >> - Add some comment about the objective in the test. It'd be hard for >> engineers who have no previous knowledge to these bytes. >> >> Naoto >> >> >> >> On 3/2/20 9:33 AM, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> Could you review the fix ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.01/ >>> >>> CSR 8233385 [1] was approved. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8233385 >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. From christoph.langer at sap.com Wed Mar 4 20:30:04 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Mar 2020 20:30:04 +0000 Subject: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start In-Reply-To: <02FEC2C4-365E-4EB1-BA4F-37D0C0CD13DD@oracle.com> References: <51EF8E30-12C0-4CDA-9E2E-79F250375567@oracle.com> <4256fa6d-cd3b-4852-72c6-7c9acbd8b489@gmail.com> <3B2A5184-B592-4F3F-80AF-5FCF8AF7035C@oracle.com> <1AE7AAAE-DA56-44AD-B932-AF7EF9F00BA9@oracle.com> <02FEC2C4-365E-4EB1-BA4F-37D0C0CD13DD@oracle.com> Message-ID: Hi Lance, I eventually found the time to have a look at your latest webrev. So, overall this looks good. It?s a good start towards cleaning up the tests and use common utility methods. Thanks for doing this. ?? I dislike a bit the fact that we introduce a new testng subfolder in test/jdk/nio/zipfs. Wouldn?t it be possible to consolidate in the current test folder? Other than that, I only have a few nits: test/jdk/jdk/nio/zipfs/testng/test/ManifestOrderTest.java: - package declaration should be moved after the copyright header - line 245: copyed -> copied - line 335: Manfifest -> Manifest - line 369: when its has -> when it has - line 387: Manfiest -> Manifest- line 417: Parameter "final Map attributes" of ManifestOrderTest::verify should be renamed to "manifestAttributes" to make it easier to understand its purpose test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java: - rename to ZipFSBaseTest (Capital ?S?)?? - package declaration should be moved after the copyright header - always use "protected" for methods/members where currently ?public? is used - line 92: use private instead of public static String formatMap, since the method isn?t used outside of ZipFsBaseTest - line 120: public static void verify - > this method is not used by ManifestOrderTest. I think we should only add it when having a test that really uses this verify method. But I generally agree that the verify method is a candidate for communalization - line 176: public void zip: dito, this method doesn?t seem used. So I suggest to remove it for this change Thanks and Best regards Christoph From: Lance Andersen Sent: Donnerstag, 27. Februar 2020 22:12 To: Langer, Christoph Cc: nio-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start Hi Christoph, I have cleaned up, re-vamped and added more coverage to the test. As part of this I started to lay the foundation for removing some of the duplicate code as part of continued clean up and enhanced coverage going forward The revised webrev can be found at: http://cr.openjdk.java.net/~lancea/8211917/webrev.00/index.html Best Lance On Feb 19, 2020, at 3:06 PM, Lance Andersen > wrote: Hi Christoph I think your changes to ZipFileSystem look fine. I am running it through mach5 now. I am still planning to clean up the test a bit and will create a web rev when I do. On Feb 19, 2020, at 4:55 AM, Langer, Christoph > wrote: Hi Lance, Jaikiran, you?re probably right. Both, the gut feeling that using streams at all here will bring some performance penalties as well as the potential double traversal of the value map speak against the suggestion I made. I was actually not really convinced myself ? however, I was looking for a way to write the coding in a more concise manner (without performance penalties, of course). Understand I did not come up with anything but if we do we can always update it later. So, going back to Jaikiran?s latest proposal, I only have a few minor performance tweaks. Please look at this webrev I generated:http://cr.openjdk.java.net/~clanger/webrevs/8211917.0/ First, the manifest node should be looked up by the statement ?inodes.get(IndexNode.keyOf(getBytes("/META-INF/MANIFEST.MF")))?. Using ?getInode(getBytes("/META-INF/MANIFEST.MF"))? would incur an unnecessary Object.requireNonNull() check and would also call the ?entryLookup? function that is needed for mapped entries in MR jars. But even in MR jars, the manifest would not be mapped to some other versioned node. And then within the loop body I restructured the if statements such that in the case of no manifest (probably the most common case), just one ?if (manifestInode == null)? check is performed and not another ?if (inode == manifestInode)? after the call to inodeIterator.next(). So, just minor tweaks but probably still worthwile doing. ?? All good Note that I also added a space after ?while? to be consistent with the rest of the file. Other than that I?m good with the change. The testcase looks comprising and zipfs tests are passing. Best Lance Best regards Christoph From: Lance Andersen > Sent: Mittwoch, 19. Februar 2020 02:42 To: Langer, Christoph > Cc: Jaikiran Pai >; nio-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start Hi Christoph On Feb 17, 2020, at 11:26 AM, Langer, Christoph > wrote: Hi Jaikiran, Lance, I'm a bit late to the game. It occurred to me, whether we could maybe use the streams API to process the inodes. Something like this: diff --git a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java @@ -56,6 +56,7 @@ import java.util.jar.Attributes; import java.util.jar.Manifest; import java.util.regex.Pattern; +import java.util.stream.Stream; import java.util.zip.CRC32; import java.util.zip.Deflater; import java.util.zip.DeflaterOutputStream; @@ -1730,7 +1731,17 @@ Entry e; // write loc - for (IndexNode inode : inodes.values()) { + + // write the manifest inode (if any) first in the loc so that the + // java.util.jar.JarInputStream can find it, since it expects it to be + // the first or second entry in the jar + final IndexNode manifestInode = getInode(getBytes("/META-INF/MANIFEST.MF")); + final Stream inodeStream = manifestInode == null ? + inodes.values().stream() : + Stream.concat(Stream.of(manifestInode), + inodes.values().stream().filter(node -> !manifestInode.equals(node))); + + for (IndexNode inode : (Iterable)inodeStream::iterator) { if (inode instanceof Entry) { // an updated inode e = (Entry)inode; try { What do you think? I am not sure the use of Streams will help us too much here as in your proposed example I believe you would end out traversing the entire list of IndexNodes twice in the case of a Manifest existing. Once when building the Stream and the other when you are walking through the IndexNodes to write them out. Best Lance I didn't have time yet to have a closer look to the testcase. Will do tomorrow. Cheers Christoph -----Original Message----- From: nio-dev > On Behalf Of Jaikiran Pai Sent: Montag, 17. Februar 2020 03:56 To: Lance Andersen > Cc: nio-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start Hello Lance, On 15/02/20 2:27 am, Lance Andersen wrote: Hi Jaikiran, I think the changes to ZipFileSystem are OK. The test overall is good. I am going to streamline it a bit and remove the long lines (we try to keep lines to around 80 characters). I'll keep that in mind for future changes. Thank you for taking care of this. -Jaikiran Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com [cid:image001.gif at 01D5F26C.11092760] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Wed Mar 4 23:00:43 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 4 Mar 2020 18:00:43 -0500 Subject: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start In-Reply-To: References: <51EF8E30-12C0-4CDA-9E2E-79F250375567@oracle.com> <4256fa6d-cd3b-4852-72c6-7c9acbd8b489@gmail.com> <3B2A5184-B592-4F3F-80AF-5FCF8AF7035C@oracle.com> <1AE7AAAE-DA56-44AD-B932-AF7EF9F00BA9@oracle.com> <02FEC2C4-365E-4EB1-BA4F-37D0C0CD13DD@oracle.com> Message-ID: Hi Christoph, Thank you for the comments see below. > On Mar 4, 2020, at 3:30 PM, Langer, Christoph wrote: > > Hi Lance, > > I eventually found the time to have a look at your latest webrev. > > So, overall this looks good. It?s a good start towards cleaning up the tests and use common utility methods. Thanks for doing this. ?? > > I dislike a bit the fact that we introduce a new testng subfolder in test/jdk/nio/zipfs. Wouldn?t it be possible to consolidate in the current test folder? I am trying to add some organization separating the non-testng tests from the testng tests and other testng tests will be moved here. I did the same for JDBC a few years back > Other than that, I only have a few nits: > > test/jdk/jdk/nio/zipfs/testng/test/ManifestOrderTest.java: > - package declaration should be moved after the copyright header moved > - line 245: copyed -> copied Not sure how I missed this but fixed > - line 335: Manfifest -> Manifest done > - line 369: when its has -> when it has done > - line 387: Manfiest -> Manifest- line 417: Parameter "final Map attributes" of ManifestOrderTest::verify should be renamed to "manifestAttributes" to make it easier to understand its purpose > Prefer to leave as is as it gets wordy and I believe the description is clear in the comments > test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java: > - rename to ZipFSBaseTest (Capital ?S?)?? hmm I had that originally but did not like it? but don?t have a strong preference > - package declaration should be moved after the copyright header moved > - always use "protected" for methods/members where currently ?public? is used I updated the methods to be protected > - line 92: use private instead of public static String formatMap, since the method isn?t used outside of ZipFsBaseTest Fair point. I had some other tests that used this outside of the methods that are in this class but I will rework them > - line 120: public static void verify - > this method is not used by ManifestOrderTest. I think we should only add it when having a test that really uses this verify method. But I generally agree that the verify method is a candidate for communalization This will be used by some tests I have created and some I will be moving so rather add it now on the initial push. This is used by several tests that will be migrated > - line 176: public void zip: dito, this method doesn?t seem used. So I suggest to remove it for this change Same comment as above The webrev for the above is http://cr.openjdk.java.net/~lancea/8211917/webrev.01/index.html Mach5 is re-running now Best Lance > > Thanks and Best regards > Christoph > > > > From: Lance Andersen > > Sent: Donnerstag, 27. Februar 2020 22:12 > To: Langer, Christoph > > Cc: nio-dev at openjdk.java.net ; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start > > Hi Christoph, > > I have cleaned up, re-vamped and added more coverage to the test. As part of this I started to lay the foundation for removing some of the duplicate code as part of continued clean up and enhanced coverage going forward > > The revised webrev can be found at: http://cr.openjdk.java.net/~lancea/8211917/webrev.00/index.html > > Best > Lance > > > On Feb 19, 2020, at 3:06 PM, Lance Andersen > wrote: > > Hi Christoph > > I think your changes to ZipFileSystem look fine. I am running it through mach5 now. I am still planning to clean up the test a bit and will create a web rev when I do. > > > > > On Feb 19, 2020, at 4:55 AM, Langer, Christoph > wrote: > > Hi Lance, Jaikiran, > > you?re probably right. Both, the gut feeling that using streams at all here will bring some performance penalties as well as the potential double traversal of the value map speak against the suggestion I made. I was actually not really convinced myself ? however, I was looking for a way to write the coding in a more concise manner (without performance penalties, of course). > Understand I did not come up with anything but if we do we can always update it later. > > So, going back to Jaikiran?s latest proposal, I only have a few minor performance tweaks. Please look at this webrev I generated:http://cr.openjdk.java.net/~clanger/webrevs/8211917.0/ > > First, the manifest node should be looked up by the statement ?inodes.get(IndexNode.keyOf(getBytes("/META-INF/MANIFEST.MF")))?. Using ?getInode(getBytes("/META-INF/MANIFEST.MF"))? would incur an unnecessary Object.requireNonNull() check and would also call the ?entryLookup? function that is needed for mapped entries in MR jars. But even in MR jars, the manifest would not be mapped to some other versioned node. > > And then within the loop body I restructured the if statements such that in the case of no manifest (probably the most common case), just one ?if (manifestInode == null)? check is performed and not another ?if (inode == manifestInode)? after the call to inodeIterator.next(). > > So, just minor tweaks but probably still worthwile doing. ?? > > All good > > > Note that I also added a space after ?while? to be consistent with the rest of the file. > > Other than that I?m good with the change. The testcase looks comprising and zipfs tests are passing. > > Best > Lance > > > Best regards > Christoph > > > From: Lance Andersen > > Sent: Mittwoch, 19. Februar 2020 02:42 > To: Langer, Christoph > > Cc: Jaikiran Pai >; nio-dev at openjdk.java.net ; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start > > Hi Christoph > > > > On Feb 17, 2020, at 11:26 AM, Langer, Christoph > wrote: > > Hi Jaikiran, Lance, > > I'm a bit late to the game. It occurred to me, whether we could maybe use the streams API to process the inodes. Something like this: > > diff --git a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java > --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java > +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java > @@ -56,6 +56,7 @@ > import java.util.jar.Attributes; > import java.util.jar.Manifest; > import java.util.regex.Pattern; > +import java.util.stream.Stream; > import java.util.zip.CRC32; > import java.util.zip.Deflater; > import java.util.zip.DeflaterOutputStream; > @@ -1730,7 +1731,17 @@ > Entry e; > > // write loc > - for (IndexNode inode : inodes.values()) { > + > + // write the manifest inode (if any) first in the loc so that the > + // java.util.jar.JarInputStream can find it, since it expects it to be > + // the first or second entry in the jar > + final IndexNode manifestInode = getInode(getBytes("/META-INF/MANIFEST.MF")); > + final Stream inodeStream = manifestInode == null ? > + inodes.values().stream() : > + Stream.concat(Stream.of(manifestInode), > + inodes.values().stream().filter(node -> !manifestInode.equals(node))); > + > + for (IndexNode inode : (Iterable)inodeStream::iterator) { > if (inode instanceof Entry) { // an updated inode > e = (Entry)inode; > try { > > What do you think? > > I am not sure the use of Streams will help us too much here as in your proposed example I believe you would end out traversing the entire list of IndexNodes twice in the case of a Manifest existing. Once when building the Stream and the other when you are walking through the IndexNodes to write them out. > > Best > Lance > > > > I didn't have time yet to have a closer look to the testcase. Will do tomorrow. > > Cheers > Christoph > > > > -----Original Message----- > From: nio-dev > On Behalf Of Jaikiran > Pai > Sent: Montag, 17. Februar 2020 03:56 > To: Lance Andersen > > Cc: nio-dev at openjdk.java.net ; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8211917: (zipfs) Creating or updating a JAR file system > should put the MANIFEST.MF at the start > > Hello Lance, > > On 15/02/20 2:27 am, Lance Andersen wrote: > > > Hi Jaikiran, > > I think the changes to ZipFileSystem are OK. > > The test overall is good. I am going to streamline it a bit and > remove the long lines (we try to keep lines to around 80 characters). > > I'll keep that in mind for future changes. Thank you for taking care of > this. > > -Jaikiran > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From denghui.ddh at alibaba-inc.com Thu Mar 5 02:44:26 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 05 Mar 2020 10:44:26 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIzODY2NTogQWRkIEpGUiBldmVudCBmb3IgZGlyZWN0IG1lbW9yeSBzdGF0?= =?UTF-8?B?aXN0aWNz?= In-Reply-To: References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> , Message-ID: <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> Hi Erik, Updated. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ Thanks Denghui Dong ------------------------------------------------------------------ From:Erik Gahlin Send Time:2020?3?5?(???) 06:33 To:???(??) Cc:hotspot-jfr-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Denghui, Looking through you patch again. Could you add copyright headers, and change ?5000 ms? to ?5 s? in the .jfc files. When you reply with the updated patch, could you please include core-libs-dev at openjdk.java.net in the reply since you are modifying exports in java.base. Thanks Erik On 4 Mar 2020, at 20:35, Erik Gahlin wrote: Hi Denghui, I have tested your fix and it seems to work. TestDefaultConfiguration takes into account the event is periodic, so it doesn't complain as I expected. Looks good. I can sponsor this. Thanks Erik On 3 Mar 2020, at 07:14, Denghui Dong wrote: Hi Erik, I agree with you that the default interval should be changed to 5s, the webrev (http://cr.openjdk.java.net/~ddong/8238665/webrev.01/) has been updated. No need to modify TestDefaultConfigurations.java, it is passed. Testing (Linux release/slow debug build): jdk/jfr, all passed except TestNativeLibrariesEvent and TestNetworkUtilizationEvent(unstable). And these two test failures were not caused by this patch. And there were some test errors in slow debug build, I have checked the error test list and confirm they are also error in slow debug build without this patch, such as TestRecordedFrame. There are two new files in this patch, should I add copyright header to them? Thanks Denghui Dong ------------------------------------------------------------------ From:Erik Gahlin Send Time:2020?3?3?(???) 04:08 To:???(??) Cc:hotspot-jfr-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Denghui, Thanks for the explanation. I think the default interval could be increased to once every 5 seconds. Have you run the all the tests in test/jdk/jdk/jfr? I would expect TestDefaultConfigurations to have failed unless modified. Thanks Erik On 2020-02-26 14:40, ???(??) wrote: PING: Could you review it? Bug: https://bugs.openjdk.java.net/browse/JDK-8238665 Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ ------------------------------------------------------------------ From:???(??) Send Time:2020?2?11?(???) 16:13 To:Erik Gahlin Cc:hotspot-jfr-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Erik, Thanks for the review. See answers embedded. New webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ On Feb 11, 2020, at 1:52 AM, Erik Gahlin wrote: Hi Denghiu, Can you explain when this event can be useful, i.e. when troubleshooting x etc.? This makes it easier to determine if the event should be on by default, if it is worth the increased startup cost that the instrumentation creates and what a reasonable period for the event should be. Many Java middleware(e.g. Netty) and applications use direct memory for achieving higher performance, if java process use too much direct memory, some exceptions will occur, such as oom-killer. Hence, it?s necessary to monitor it, and we use JMX to monitor it in our production environment currently. src/jdk.jfr/share/classes/jdk/jfr/events/DirectMemoryStatisticsEvent.java: @Label("TotalCapacity") -> @Label("Total Capacity") @Label("MemoryUsed") -> @Label("Memory Used?) Updated What is meant by 'limit'? Could we have a better field name and/or description that explains what this fields contains, because it is not obvious from that name. Fields that contains bytes, should have the DataAmount; annotation. What is the value if -XX:MaxDirectMemorySize has not been set? limit -> maxCapacity if -XX:MaxDirectMemorySize has not been set, the value of Runtime.getRuntime().maxMemory() will be used. Can you make the event class final. Updated @StackTrace(false) should not be needed. Removed test/jdk/jdk/jfr/event/runtime/TestDirectMemoryStatisticsEvent.java: Use try-with-resources on the Recording object. Updated Thanks Denghui Dong Thanks Erik On 2020-02-07 06:24, Denghui Dong wrote: Hi, Could I have a review of a change that adds JFR event for direct memory statistics Bug: https://bugs.openjdk.java.net/browse/JDK-8238665 Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.00/ Test: test/jdk/jdk/jfr/event/runtime/TestDirectMemoryStatisticsEvent.java Thanks Denghui Dong From calvin.cheung at oracle.com Thu Mar 5 05:13:02 2020 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 4 Mar 2020 21:13:02 -0800 Subject: RFR(S): 8232081: Try to link all classes during dynamic CDS dump In-Reply-To: <00090c43-1e0d-2b1c-d2a5-1b5f1b29199d@oracle.com> References: <9b40145a-db72-6313-3b98-5e5aea754e25@oracle.com> <1167ff6d-3997-6390-d020-d0946fad0af8@oracle.com> <3f373a33-c7ed-0237-1dd5-f8ac8e8794ee@oracle.com> <8ac4612b-fae3-bb16-f2ab-fa323c33ca51@oracle.com> <00090c43-1e0d-2b1c-d2a5-1b5f1b29199d@oracle.com> Message-ID: <7a54e00f-c049-a5ef-0afc-bb6c9d0f30ad@oracle.com> Hi David, Ioi, Here's an updated webrev which doesn't involve changing InstanceKlass::verify_on() and made use of the changes for JDK-8240481. ??? http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.03/ thanks, Calvin On 3/1/20 10:14 PM, David Holmes wrote: > Hi Calvin, > > On 28/02/2020 4:12 pm, Calvin Cheung wrote: >> Hi David, >> >> On 2/27/20 5:40 PM, David Holmes wrote: >>> Hi Calvin, Ioi, >>> >>> Looking good - comments below. >>> >>> A meta-question: normal application classes are rarely loaded but >>> not linked so I'm a little surprised this is an issue. What is the >>> main source of such classes - generated classes like lambda forms? >>> Also why do we need to link them when loading from the archive if >>> they were never linked when the application actually executed ?? >> >> I saw that Ioi already answered the above. >> >> I'll try to answer your questions inline below.. > > Responses inline below ... > >>> >>> On 28/02/2020 10:48 am, Calvin Cheung wrote: >>>> Hi David, Ioi, >>>> >>>> Thanks for your review and suggestions. >>>> >>>> On 2/26/20 9:46 PM, Ioi Lam wrote: >>>>> >>>>> >>>>> On 2/26/20 7:50 PM, David Holmes wrote: >>>>>> Hi Calvin, >>>>>> >>>>>> Adding core-libs-dev as you are messing with their code :) >>>>>> >>>>>> On 27/02/2020 1:19 pm, Calvin Cheung wrote: >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8232081 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/ >>>>>>> >>>>>>> The proposed changeset for this RFE adds a >>>>>>> JVM_LinkClassesForCDS() function to be called from >>>>>>> java/lang/Shutdown to notify the JVM to link the classes loaded >>>>>>> by the builtin class loaders. The >>>>>> >>>>>> This would be much less disruptive if this was handled purely on >>>>>> the VM side once we have started shutdown. No need to make any >>>>>> changes to the Java side then, nor jvm.cpp. >>>>>> >>>>> >>>>> Hi David, >>>>> >>>>> To link the classes, we need to be able to run Java code -- when >>>>> linking a class X loaded by the app loader, X will be verified. >>>>> During verification of X, we may need to load additional classes >>>>> from the app loader, which executes Java code during its class >>>>> loading operations. >>>>> >>>>> We also need to handle all the exit conditions. As far as I can >>>>> tell, an app can exit the JVM in two ways: >>>>> >>>>> (1) Explicitly calling System.exit(). This will call >>>>> java.lang.Shutdown.exit() which does this: >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l163 >>>>> >>>>> >>>>> ??????????? beforeHalt(); // native >>>>> ??????????? runHooks(); >>>>> ??????????? halt(status); >>>>> >>>>> (2) When all non-daemon threads have died (e.g., falling out of >>>>> the bottom of HelloWorld.main()). There's no explicit call to >>>>> System.exit(), but the JVM will proactively call >>>>> java.lang.Shutdown.shutdown() inside >>>>> JavaThread::invoke_shutdown_hooks() >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/hotspot/share/runtime/thread.cpp#l4331 >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l184 >>>>> >>>>> >>>>> If we want to avoid modifying the Java code, I think we can >>>>> intercept JVM_BeforeHalt() and >>>>> JavaThread::invoke_shutdown_hooks(). This way we should be able to >>>>> handle all the classes (except those that are loaded inside >>>>> Shutdown.runHooks). >>>> >>>> I've implemented the above. No changes to the Java side. >>>> >>>> updated webrev: >>>> >>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.01/ >>> >>> This looks much better to me. I wasn't sure if you were that >>> concerned about catching the classes loaded by the Shutdown hooks, >>> but it is good you are not as it seems problematic to me to trigger >>> class loading etc after the shutdown hooks have executed - you may >>> hit unexpected conditions. So this approach is good. >>> >>> A few minor comments: >>> >>> src/hotspot/share/memory/metaspaceShared.cpp >>> src/hotspot/share/memory/metaspaceShared.hpp >>> >>> Why the change from TRAPS to "Thread* THREAD"? >> I forgot why I changed it but I've changed it back and it still works. > > Ok. > >>> >>> --- >>> >>> src/hotspot/share/oops/instanceKlass.cpp >>> >>> I'm not clear how verify_on is used so am unsure how the additional >>> error state check may affect code unrelated to dynamic dumping ?? >> >> Some of the appcds tests by design have some classes which fail >> verification. Without the change, the following assert would fail: >> >> void vtableEntry::verify(klassVtable* vt, outputStream* st) { >> ?? Klass* vtklass = vt->klass(); >> ?? if (vtklass->is_instance_klass() && >> ????? (InstanceKlass::cast(vtklass)->major_version() >= >> klassVtable::VTABLE_TRANSITIVE_OVERRIDE_VERSION)) { >> *assert*(method() != NULL, "must have set method"); >> ?? } > > Okay so you need to exclude for that case but ... > >> Here's the call stack during dynamic CDS dump to the above function: >> >> vtableEntry::verify(klassVtable *, outputStream *) : void >> ???? klassVtable::verify(outputStream *, bool) : void >> ???????? InstanceKlass::verify_on(outputStream *) : void >> ???????????? Klass::verify() : void >> ???????????????? ClassLoaderData::verify() : void >> ???????????????????? ClassLoaderDataGraph::verify() : void >> ???????????????????????? Universe::verify(enum VerifyOption, const >> char *) : void >> ???????????????????????????? Universe::verify(const char *) : void >> DynamicArchiveBuilder::verify_universe(const char *) : void >> DynamicArchiveBuilder::doit() : void (2 matches) >> VM_PopulateDynamicDumpSharedSpace::doit() : void >> VM_Operation::evaluate() : void >> >> The is_linked() function is implemented as: >> >> ???? bool is_linked() const?????????????????? { return _init_state >= >> linked; } >> >> which includes 'initialization_error'. > > ... AFAICS Universe::verify is call from a number of places, all of > which would reach this modified code. As that existing code has > included classes that are in the error state then it seems to me that > unless you can prove otherwise you need to keep the existing code > as-is for the non-CDS dump case. > >> A previous version of the changeset (including the change in question >> in instanceKlass.cpp) passed tier1 - 4 testing. Let me know if I >> should run other tests to make sure the change is good. > > There may well not be a test that covers this. > > Thanks, > David > >>> >>> Also can I suggest (as you are touching this code) to delete the >>> ancient comment: >>> >>> 3580???? // $$$ This used to be done only for m/s collections. Doing it >>> 3581???? // always seemed a valid generalization.? (DLD -- 6/00) >> >> I'm glad that you suggested to remove the above comment. I've no clue >> what it means either. >> >> updated webrev: >> >> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.02/ >> >> thanks, >> Calvin >>> >>> Thanks, >>> David >>> ----- >>> >>>> I also updated the test to test the shutdown hook and System.exit() >>>> scenarios. >>>> >>>> All appcds tests passed on my linux host. I'll run more tests using >>>> mach5. >>>> >>>> thanks, >>>> >>>> Calvin >>>> >>>> >>>>> >>>>> What do you think? >>>>> >>>>> - Ioi >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> MetaspaceShared::link_and_cleanup_shared_classes() has been >>>>>>> modified to handle both static and dynamic CDS dump. For dynamic >>>>>>> CDS dump, only classes loaded by the builtin class loaders will >>>>>>> be linked. Local performance testing using javac on >>>>>>> HelloWorld.java shows an improvement of >5%. >>>>>>> >>>>>>> Passed tier1 - 4 tests. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Calvin >>>>>>> >>>>> From erik.gahlin at oracle.com Thu Mar 5 05:23:11 2020 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 5 Mar 2020 06:23:11 +0100 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> Message-ID: <7DA7FCB2-3C07-40CE-8F42-5F1F093CB7AA@oracle.com> Hi Denghui, The copyright headers should have the classpath exception, similar to other files in the same directory. If somebody in core-libs could review this, especially the modification of src/java.base/share/classes/module-info.java, I can the push this. Thanks Erik > On 5 Mar 2020, at 03:44, Denghui Dong wrote: > > Hi Erik, > Updated. > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ > > Thanks > Denghui Dong > ------------------------------------------------------------------ > From:Erik Gahlin > Send Time:2020?3?5?(???) 06:33 > To:???(??) > Cc:hotspot-jfr-dev > Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics > > Hi Denghui, > > Looking through you patch again. > > Could you add copyright headers, and change ?5000 ms? to ?5 s? in the .jfc files. When you reply with the updated patch, could you please include core-libs-dev at openjdk.java.net in the reply since you are modifying exports in java.base. > > Thanks > Erik > > > On 4 Mar 2020, at 20:35, Erik Gahlin > wrote: > > Hi Denghui, > > I have tested your fix and it seems to work. TestDefaultConfiguration takes into account the event is periodic, so it doesn't complain as I expected. > > Looks good. I can sponsor this. > > Thanks > Erik > > > On 3 Mar 2020, at 07:14, Denghui Dong > wrote: > > Hi Erik, > I agree with you that the default interval should be changed to 5s, the webrev (http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ ) has been updated. > No need to modify TestDefaultConfigurations.java, it is passed. > > Testing > (Linux release/slow debug build): jdk/jfr, all passed except TestNativeLibrariesEvent and TestNetworkUtilizationEvent(unstable). And these two test failures were not caused by this patch. > And there were some test errors in slow debug build, I have checked the error test list and confirm they are also error in slow debug build without this patch, such as TestRecordedFrame. > > There are two new files in this patch, should I add copyright header to them? > > Thanks > Denghui Dong > ------------------------------------------------------------------ > From:Erik Gahlin > > Send Time:2020?3?3?(???) 04:08 > To:???(??) > > Cc:hotspot-jfr-dev > > Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics > > Hi Denghui, > > Thanks for the explanation. > I think the default interval could be increased to once every 5 seconds. > > Have you run the all the tests in test/jdk/jdk/jfr? I would expect TestDefaultConfigurations to have failed unless modified. > Thanks > Erik > On 2020-02-26 14:40, ???(??) wrote: > PING: Could you review it? > Bug: https://bugs.openjdk.java.net/browse/JDK-8238665 > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ > > ------------------------------------------------------------------ > From:???(??) > Send Time:2020?2?11?(???) 16:13 > To:Erik Gahlin > Cc:hotspot-jfr-dev > Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics > > Hi Erik, > > Thanks for the review. See answers embedded. > > New webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ > > On Feb 11, 2020, at 1:52 AM, Erik Gahlin > wrote: > > Hi Denghiu, > > Can you explain when this event can be useful, i.e. when troubleshooting x etc.? This makes it easier to determine if the event should be on by default, if it is worth the increased startup cost that the instrumentation creates and what a reasonable period for the event should be. > > Many Java middleware(e.g. Netty) and applications use direct memory for achieving higher performance, if java process use too much direct memory, some exceptions will occur, such as oom-killer. Hence, it?s necessary to monitor it, and we use JMX to monitor it in our production environment currently. > > src/jdk.jfr/share/classes/jdk/jfr/events/DirectMemoryStatisticsEvent.java: > > @Label("TotalCapacity") -> @Label("Total Capacity") > @Label("MemoryUsed") -> @Label("Memory Used?) > > Updated > > What is meant by 'limit'? Could we have a better field name and/or description that explains what this fields contains, because it is not obvious from that name. Fields that contains bytes, should have the DataAmount; annotation. > > What is the value if -XX:MaxDirectMemorySize has not been set? > > limit -> maxCapacity > > if -XX:MaxDirectMemorySize has not been set, the value of Runtime.getRuntime().maxMemory() will be used. > > Can you make the event class final. > > Updated > > @StackTrace(false) should not be needed. > > Removed > > test/jdk/jdk/jfr/event/runtime/TestDirectMemoryStatisticsEvent.java: > > Use try-with-resources on the Recording object. > > Updated > > Thanks > Denghui Dong > > Thanks > Erik > > On 2020-02-07 06:24, Denghui Dong wrote: > Hi, > > Could I have a review of a change that adds JFR event for direct memory statistics > > Bug: https://bugs.openjdk.java.net/browse/JDK-8238665 > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.00/ > Test: test/jdk/jdk/jfr/event/runtime/TestDirectMemoryStatisticsEvent.java > > Thanks > Denghui Dong > > > From denghui.ddh at alibaba-inc.com Thu Mar 5 06:26:33 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 05 Mar 2020 14:26:33 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIzODY2NTogQWRkIEpGUiBldmVudCBmb3IgZGlyZWN0IG1lbW9yeSBzdGF0?= =?UTF-8?B?aXN0aWNz?= In-Reply-To: <7DA7FCB2-3C07-40CE-8F42-5F1F093CB7AA@oracle.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com>, <7DA7FCB2-3C07-40CE-8F42-5F1F093CB7AA@oracle.com> Message-ID: <663cbc2e-ab51-4184-b8bf-510392866de0.denghui.ddh@alibaba-inc.com> Added. Thanks, Denghui Dong ------------------------------------------------------------------ From:Erik Gahlin Send Time:2020?3?5?(???) 13:23 To:???(??) ; core-libs-dev Cc:hotspot-jfr-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Denghui, The copyright headers should have the classpath exception, similar to other files in the same directory. If somebody in core-libs could review this, especially the modification of src/java.base/share/classes/module-info.java, I can the push this. Thanks Erik On 5 Mar 2020, at 03:44, Denghui Dong wrote: Hi Erik, Updated. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ Thanks Denghui Dong ------------------------------------------------------------------ From:Erik Gahlin Send Time:2020?3?5?(???) 06:33 To:???(??) Cc:hotspot-jfr-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Denghui, Looking through you patch again. Could you add copyright headers, and change ?5000 ms? to ?5 s? in the .jfc files. When you reply with the updated patch, could you please include core-libs-dev at openjdk.java.net in the reply since you are modifying exports in java.base. Thanks Erik On 4 Mar 2020, at 20:35, Erik Gahlin wrote: Hi Denghui, I have tested your fix and it seems to work. TestDefaultConfiguration takes into account the event is periodic, so it doesn't complain as I expected. Looks good. I can sponsor this. Thanks Erik On 3 Mar 2020, at 07:14, Denghui Dong wrote: Hi Erik, I agree with you that the default interval should be changed to 5s, the webrev (http://cr.openjdk.java.net/~ddong/8238665/webrev.01/) has been updated. No need to modify TestDefaultConfigurations.java, it is passed. Testing (Linux release/slow debug build): jdk/jfr, all passed except TestNativeLibrariesEvent and TestNetworkUtilizationEvent(unstable). And these two test failures were not caused by this patch. And there were some test errors in slow debug build, I have checked the error test list and confirm they are also error in slow debug build without this patch, such as TestRecordedFrame. There are two new files in this patch, should I add copyright header to them? Thanks Denghui Dong ------------------------------------------------------------------ From:Erik Gahlin Send Time:2020?3?3?(???) 04:08 To:???(??) Cc:hotspot-jfr-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Denghui, Thanks for the explanation. I think the default interval could be increased to once every 5 seconds. Have you run the all the tests in test/jdk/jdk/jfr? I would expect TestDefaultConfigurations to have failed unless modified. Thanks Erik On 2020-02-26 14:40, ???(??) wrote: PING: Could you review it? Bug: https://bugs.openjdk.java.net/browse/JDK-8238665 Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ ------------------------------------------------------------------ From:???(??) Send Time:2020?2?11?(???) 16:13 To:Erik Gahlin Cc:hotspot-jfr-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Erik, Thanks for the review. See answers embedded. New webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ On Feb 11, 2020, at 1:52 AM, Erik Gahlin wrote: Hi Denghiu, Can you explain when this event can be useful, i.e. when troubleshooting x etc.? This makes it easier to determine if the event should be on by default, if it is worth the increased startup cost that the instrumentation creates and what a reasonable period for the event should be. Many Java middleware(e.g. Netty) and applications use direct memory for achieving higher performance, if java process use too much direct memory, some exceptions will occur, such as oom-killer. Hence, it?s necessary to monitor it, and we use JMX to monitor it in our production environment currently. src/jdk.jfr/share/classes/jdk/jfr/events/DirectMemoryStatisticsEvent.java: @Label("TotalCapacity") -> @Label("Total Capacity") @Label("MemoryUsed") -> @Label("Memory Used?) Updated What is meant by 'limit'? Could we have a better field name and/or description that explains what this fields contains, because it is not obvious from that name. Fields that contains bytes, should have the DataAmount; annotation. What is the value if -XX:MaxDirectMemorySize has not been set? limit -> maxCapacity if -XX:MaxDirectMemorySize has not been set, the value of Runtime.getRuntime().maxMemory() will be used. Can you make the event class final. Updated @StackTrace(false) should not be needed. Removed test/jdk/jdk/jfr/event/runtime/TestDirectMemoryStatisticsEvent.java: Use try-with-resources on the Recording object. Updated Thanks Denghui Dong Thanks Erik On 2020-02-07 06:24, Denghui Dong wrote: Hi, Could I have a review of a change that adds JFR event for direct memory statistics Bug: https://bugs.openjdk.java.net/browse/JDK-8238665 Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.00/ Test: test/jdk/jdk/jfr/event/runtime/TestDirectMemoryStatisticsEvent.java Thanks Denghui Dong From david.holmes at oracle.com Thu Mar 5 07:34:40 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Mar 2020 17:34:40 +1000 Subject: RFR(S): 8232081: Try to link all classes during dynamic CDS dump In-Reply-To: <7a54e00f-c049-a5ef-0afc-bb6c9d0f30ad@oracle.com> References: <9b40145a-db72-6313-3b98-5e5aea754e25@oracle.com> <1167ff6d-3997-6390-d020-d0946fad0af8@oracle.com> <3f373a33-c7ed-0237-1dd5-f8ac8e8794ee@oracle.com> <8ac4612b-fae3-bb16-f2ab-fa323c33ca51@oracle.com> <00090c43-1e0d-2b1c-d2a5-1b5f1b29199d@oracle.com> <7a54e00f-c049-a5ef-0afc-bb6c9d0f30ad@oracle.com> Message-ID: On 5/03/2020 3:13 pm, Calvin Cheung wrote: > Hi David, Ioi, > > Here's an updated webrev which doesn't involve changing > InstanceKlass::verify_on() and made use of the changes for JDK-8240481. > > ??? http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.03/ No further comments from me. Thanks for cleaning that up. David > thanks, > Calvin > > On 3/1/20 10:14 PM, David Holmes wrote: >> Hi Calvin, >> >> On 28/02/2020 4:12 pm, Calvin Cheung wrote: >>> Hi David, >>> >>> On 2/27/20 5:40 PM, David Holmes wrote: >>>> Hi Calvin, Ioi, >>>> >>>> Looking good - comments below. >>>> >>>> A meta-question: normal application classes are rarely loaded but >>>> not linked so I'm a little surprised this is an issue. What is the >>>> main source of such classes - generated classes like lambda forms? >>>> Also why do we need to link them when loading from the archive if >>>> they were never linked when the application actually executed ?? >>> >>> I saw that Ioi already answered the above. >>> >>> I'll try to answer your questions inline below.. >> >> Responses inline below ... >> >>>> >>>> On 28/02/2020 10:48 am, Calvin Cheung wrote: >>>>> Hi David, Ioi, >>>>> >>>>> Thanks for your review and suggestions. >>>>> >>>>> On 2/26/20 9:46 PM, Ioi Lam wrote: >>>>>> >>>>>> >>>>>> On 2/26/20 7:50 PM, David Holmes wrote: >>>>>>> Hi Calvin, >>>>>>> >>>>>>> Adding core-libs-dev as you are messing with their code :) >>>>>>> >>>>>>> On 27/02/2020 1:19 pm, Calvin Cheung wrote: >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8232081 >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/ >>>>>>>> >>>>>>>> The proposed changeset for this RFE adds a >>>>>>>> JVM_LinkClassesForCDS() function to be called from >>>>>>>> java/lang/Shutdown to notify the JVM to link the classes loaded >>>>>>>> by the builtin class loaders. The >>>>>>> >>>>>>> This would be much less disruptive if this was handled purely on >>>>>>> the VM side once we have started shutdown. No need to make any >>>>>>> changes to the Java side then, nor jvm.cpp. >>>>>>> >>>>>> >>>>>> Hi David, >>>>>> >>>>>> To link the classes, we need to be able to run Java code -- when >>>>>> linking a class X loaded by the app loader, X will be verified. >>>>>> During verification of X, we may need to load additional classes >>>>>> from the app loader, which executes Java code during its class >>>>>> loading operations. >>>>>> >>>>>> We also need to handle all the exit conditions. As far as I can >>>>>> tell, an app can exit the JVM in two ways: >>>>>> >>>>>> (1) Explicitly calling System.exit(). This will call >>>>>> java.lang.Shutdown.exit() which does this: >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l163 >>>>>> >>>>>> >>>>>> ??????????? beforeHalt(); // native >>>>>> ??????????? runHooks(); >>>>>> ??????????? halt(status); >>>>>> >>>>>> (2) When all non-daemon threads have died (e.g., falling out of >>>>>> the bottom of HelloWorld.main()). There's no explicit call to >>>>>> System.exit(), but the JVM will proactively call >>>>>> java.lang.Shutdown.shutdown() inside >>>>>> JavaThread::invoke_shutdown_hooks() >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/hotspot/share/runtime/thread.cpp#l4331 >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l184 >>>>>> >>>>>> >>>>>> If we want to avoid modifying the Java code, I think we can >>>>>> intercept JVM_BeforeHalt() and >>>>>> JavaThread::invoke_shutdown_hooks(). This way we should be able to >>>>>> handle all the classes (except those that are loaded inside >>>>>> Shutdown.runHooks). >>>>> >>>>> I've implemented the above. No changes to the Java side. >>>>> >>>>> updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.01/ >>>> >>>> This looks much better to me. I wasn't sure if you were that >>>> concerned about catching the classes loaded by the Shutdown hooks, >>>> but it is good you are not as it seems problematic to me to trigger >>>> class loading etc after the shutdown hooks have executed - you may >>>> hit unexpected conditions. So this approach is good. >>>> >>>> A few minor comments: >>>> >>>> src/hotspot/share/memory/metaspaceShared.cpp >>>> src/hotspot/share/memory/metaspaceShared.hpp >>>> >>>> Why the change from TRAPS to "Thread* THREAD"? >>> I forgot why I changed it but I've changed it back and it still works. >> >> Ok. >> >>>> >>>> --- >>>> >>>> src/hotspot/share/oops/instanceKlass.cpp >>>> >>>> I'm not clear how verify_on is used so am unsure how the additional >>>> error state check may affect code unrelated to dynamic dumping ?? >>> >>> Some of the appcds tests by design have some classes which fail >>> verification. Without the change, the following assert would fail: >>> >>> void vtableEntry::verify(klassVtable* vt, outputStream* st) { >>> ?? Klass* vtklass = vt->klass(); >>> ?? if (vtklass->is_instance_klass() && >>> ????? (InstanceKlass::cast(vtklass)->major_version() >= >>> klassVtable::VTABLE_TRANSITIVE_OVERRIDE_VERSION)) { >>> *assert*(method() != NULL, "must have set method"); >>> ?? } >> >> Okay so you need to exclude for that case but ... >> >>> Here's the call stack during dynamic CDS dump to the above function: >>> >>> vtableEntry::verify(klassVtable *, outputStream *) : void >>> ???? klassVtable::verify(outputStream *, bool) : void >>> ???????? InstanceKlass::verify_on(outputStream *) : void >>> ???????????? Klass::verify() : void >>> ???????????????? ClassLoaderData::verify() : void >>> ???????????????????? ClassLoaderDataGraph::verify() : void >>> ???????????????????????? Universe::verify(enum VerifyOption, const >>> char *) : void >>> ???????????????????????????? Universe::verify(const char *) : void >>> DynamicArchiveBuilder::verify_universe(const char *) : void >>> DynamicArchiveBuilder::doit() : void (2 matches) >>> VM_PopulateDynamicDumpSharedSpace::doit() : void >>> VM_Operation::evaluate() : void >>> >>> The is_linked() function is implemented as: >>> >>> ???? bool is_linked() const?????????????????? { return _init_state >= >>> linked; } >>> >>> which includes 'initialization_error'. >> >> ... AFAICS Universe::verify is call from a number of places, all of >> which would reach this modified code. As that existing code has >> included classes that are in the error state then it seems to me that >> unless you can prove otherwise you need to keep the existing code >> as-is for the non-CDS dump case. >> >>> A previous version of the changeset (including the change in question >>> in instanceKlass.cpp) passed tier1 - 4 testing. Let me know if I >>> should run other tests to make sure the change is good. >> >> There may well not be a test that covers this. >> >> Thanks, >> David >> >>>> >>>> Also can I suggest (as you are touching this code) to delete the >>>> ancient comment: >>>> >>>> 3580???? // $$$ This used to be done only for m/s collections. Doing it >>>> 3581???? // always seemed a valid generalization.? (DLD -- 6/00) >>> >>> I'm glad that you suggested to remove the above comment. I've no clue >>> what it means either. >>> >>> updated webrev: >>> >>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.02/ >>> >>> thanks, >>> Calvin >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> I also updated the test to test the shutdown hook and System.exit() >>>>> scenarios. >>>>> >>>>> All appcds tests passed on my linux host. I'll run more tests using >>>>> mach5. >>>>> >>>>> thanks, >>>>> >>>>> Calvin >>>>> >>>>> >>>>>> >>>>>> What do you think? >>>>>> >>>>>> - Ioi >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> MetaspaceShared::link_and_cleanup_shared_classes() has been >>>>>>>> modified to handle both static and dynamic CDS dump. For dynamic >>>>>>>> CDS dump, only classes loaded by the builtin class loaders will >>>>>>>> be linked. Local performance testing using javac on >>>>>>>> HelloWorld.java shows an improvement of >5%. >>>>>>>> >>>>>>>> Passed tier1 - 4 tests. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Calvin >>>>>>>> >>>>>> From Alan.Bateman at oracle.com Thu Mar 5 08:46:08 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Mar 2020 08:46:08 +0000 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> Message-ID: On 05/03/2020 02:44, Denghui Dong wrote: > Hi Erik, > Updated. > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ > ManagementFactoryHelper has a method to get the list of MXBeans for the buffer pools. That could be easily changed to return an unmodifable list. That would allow you to emit statistics for memory-mapped files too (the current patch seems to be limited to emitting stats for direct buffers). -Alan. From christoph.langer at sap.com Thu Mar 5 09:03:14 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Mar 2020 09:03:14 +0000 Subject: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start In-Reply-To: References: <51EF8E30-12C0-4CDA-9E2E-79F250375567@oracle.com> <4256fa6d-cd3b-4852-72c6-7c9acbd8b489@gmail.com> <3B2A5184-B592-4F3F-80AF-5FCF8AF7035C@oracle.com> <1AE7AAAE-DA56-44AD-B932-AF7EF9F00BA9@oracle.com> <02FEC2C4-365E-4EB1-BA4F-37D0C0CD13DD@oracle.com> Message-ID: Hi Lance, Thanks for addressing my points. Here my answer to those things which weren't in full agreement yet: > I dislike a bit the fact that we introduce a new testng subfolder in > test/jdk/nio/zipfs. Wouldn?t it be possible to consolidate in the current test > folder? > > I am trying to add some organization separating the non-testng ?tests from > the ?testng tests and other testng tests will be moved here. ?I did the same > for JDBC a few years back ok, maybe it's a good idea to do this here and gradually move all testng tests over. > - line 387: Manfiest -> Manifest I think you missed that one > - line 417: Parameter "final Map > attributes" of ManifestOrderTest::verify should be renamed to > "manifestAttributes" to make it easier to understand its purpose > > > Prefer to leave as is as it gets wordy and I believe the description is clear in > the comments Hm, I needed to look twice to grasp it. So, I'd still prefer something with "manifest" in the variable name. But I leave it to you since it's probably a personal taste thing ?? However, two more things here: The Javadoc of verify says (line 412): * @param attributes Is there a Manifest to check You should rather go with the Javadoc of validateManifest here as well: * @param attributes A Map containing the attributes expected in the Manifest; * otherwise empty Also, I spotted in the Javadoc, line 413: * @param entries Entries to validate are in the JAR I guess the "are" is wrong here. > test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java: > - rename to ZipFSBaseTest (Capital ?S?)?? > hmm ?I had that originally but did not like it? ?but don?t have a strong > preference Ok, leave it as you have it ?? > - line 120: public static void verify - > this method is not used by > ManifestOrderTest. I think we should only add it when having a test that > really uses this verify method. But I generally agree that the verify method is > a candidate for communalization > > This will be used by some tests I have created and some I will be moving so > rather add it now on the initial push. ?This is used by several tests that will be > migrated > > - line 176: public void zip: dito, this method doesn?t seem used. So I suggest > to remove it for this change > Same comment as above OK. > The webrev for the above > is?http://cr.openjdk.java.net/~lancea/8211917/webrev.01/index.html Looks good, apart from my comments above. Thanks Christoph From denghui.ddh at alibaba-inc.com Thu Mar 5 09:54:30 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 05 Mar 2020 17:54:30 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIzODY2NTogQWRkIEpGUiBldmVudCBmb3IgZGlyZWN0IG1lbW9yeSBzdGF0?= =?UTF-8?B?aXN0aWNz?= In-Reply-To: References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com>, Message-ID: <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> Hi Alan, If I use ManagementFactoryHelper to get memory pools, I still need to modify src/java.management/share/classes/module-info.java to export sun.management, right? Thanks, Denghui Dong ------------------------------------------------------------------ From:Alan Bateman Send Time:2020?3?5?(???) 16:46 To:???(??) ; Erik Gahlin ; hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics On 05/03/2020 02:44, Denghui Dong wrote: > Hi Erik, > Updated. > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ > ManagementFactoryHelper has a method to get the list of MXBeans for the buffer pools. That could be easily changed to return an unmodifable list. That would allow you to emit statistics for memory-mapped files too (the current patch seems to be limited to emitting stats for direct buffers). -Alan. From Alan.Bateman at oracle.com Thu Mar 5 10:39:28 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Mar 2020 10:39:28 +0000 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> Message-ID: <967d3181-f223-660d-3b4a-9bdf49a3a863@oracle.com> On 05/03/2020 09:54, Denghui Dong wrote: > Hi Alan, > > If I use?ManagementFactoryHelper to get memory pools, I still need to > modify?src/java.management/share/classes/module-info.java > to export sun.management, right? > I should have been clearer in my comment. I think it should be possible to put a helper in somewhere like jdk.internal.misc to replace ManagementFactoryHelper.getBufferPoolMXBeans(). It can return an unmodifable list of the MXBeans for the buffer pools. This should allow periodic stats/events for buffer pools other than the direct buffer pool. -Alan. From erik.gahlin at oracle.com Thu Mar 5 11:55:03 2020 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 5 Mar 2020 12:55:03 +0100 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> Message-ID: <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> We should avoid adding a dependency on java.management. The jdk.jfr module today only depends java.base so JFR can be used in constrained environments. All JMX related functionality is in jdk.management.jfr. Erik > On 5 Mar 2020, at 10:54, Denghui Dong wrote: > > Hi Alan, > > If I use ManagementFactoryHelper to get memory pools, I still need to modify src/java.management/share/classes/module-info.java > to export sun.management, right? > > Thanks, > Denghui Dong > ------------------------------------------------------------------ > From:Alan Bateman > Send Time:2020?3?5?(???) 16:46 > To:???(??) ; Erik Gahlin ; hotspot-jfr-dev ; core-libs-dev > Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics > > On 05/03/2020 02:44, Denghui Dong wrote: > > Hi Erik, > > Updated. > > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ > > > ManagementFactoryHelper has a method to get the list of MXBeans for the > buffer pools. That could be easily changed to return an unmodifable > list. That would allow you to emit statistics for memory-mapped files > too (the current patch seems to be limited to emitting stats for direct > buffers). > > -Alan. From lance.andersen at oracle.com Thu Mar 5 12:35:52 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 5 Mar 2020 07:35:52 -0500 Subject: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start In-Reply-To: References: <51EF8E30-12C0-4CDA-9E2E-79F250375567@oracle.com> <4256fa6d-cd3b-4852-72c6-7c9acbd8b489@gmail.com> <3B2A5184-B592-4F3F-80AF-5FCF8AF7035C@oracle.com> <1AE7AAAE-DA56-44AD-B932-AF7EF9F00BA9@oracle.com> <02FEC2C4-365E-4EB1-BA4F-37D0C0CD13DD@oracle.com> Message-ID: <2516AAC0-4D5B-4C10-8B86-E41152E56109@oracle.com> Hi Christoph > On Mar 5, 2020, at 4:03 AM, Langer, Christoph wrote: > > Hi Lance, > > Thanks for addressing my points. Here my answer to those things which weren't in full agreement yet: Please see below > >> I dislike a bit the fact that we introduce a new testng subfolder in >> test/jdk/nio/zipfs. Wouldn?t it be possible to consolidate in the current test >> folder? >> >> I am trying to add some organization separating the non-testng tests from >> the testng tests and other testng tests will be moved here. I did the same >> for JDBC a few years back > > ok, maybe it's a good idea to do this here and gradually move all testng tests over. > >> - line 387: Manfiest -> Manifest > > I think you missed that one Fixed must have not saved it but it is there now > > >> - line 417: Parameter "final Map >> attributes" of ManifestOrderTest::verify should be renamed to >> "manifestAttributes" to make it easier to understand its purpose >> >> >> Prefer to leave as is as it gets wordy and I believe the description is clear in >> the comments > > Hm, I needed to look twice to grasp it. So, I'd still prefer something with "manifest" in the variable name. But I leave it to you since it's probably a personal taste thing ?? I left the variable name as to your point it sometimes is a personal preference ;-) > > However, two more things here: > > The Javadoc of verify says (line 412): > * @param attributes Is there a Manifest to check > > You should rather go with the Javadoc of validateManifest here as well: > * @param attributes A Map containing the attributes expected in the Manifest; > * otherwise empty Updated? Thought I had done that previously as that @param was originally a boolean ?. > > Also, I spotted in the Javadoc, line 413: > * @param entries Entries to validate are in the JAR > > I guess the "are" is wrong here. Fixed > >> test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java: >> - rename to ZipFSBaseTest (Capital ?S?)?? >> hmm I had that originally but did not like it? but don?t have a strong >> preference > > Ok, leave it as you have it ?? :-) > >> - line 120: public static void verify - > this method is not used by >> ManifestOrderTest. I think we should only add it when having a test that >> really uses this verify method. But I generally agree that the verify method is >> a candidate for communalization >> >> This will be used by some tests I have created and some I will be moving so >> rather add it now on the initial push. This is used by several tests that will be >> migrated >> >> - line 176: public void zip: dito, this method doesn?t seem used. So I suggest >> to remove it for this change >> Same comment as above > > OK. > >> The webrev for the above >> is http://cr.openjdk.java.net/~lancea/8211917/webrev.01/index.html > > Looks good, apart from my comments above. Thank you again for the review The revised webrev is at http://cr.openjdk.java.net/~lancea/8211917/webrev.02/index.html Best Lance > > Thanks > Christoph > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From erik.gahlin at oracle.com Thu Mar 5 14:10:53 2020 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 5 Mar 2020 15:10:53 +0100 Subject: RFR: 8222000: JFR: Process start event Message-ID: Hi Could I have review of a JFR event that is emitted when a process is started from Java. Bug: https://bugs.openjdk.java.net/browse/JDK-8222000 Webrev: http://cr.openjdk.java.net/~egahlin/8222000/ Testing: tier1,tier2 + jdk/jdk/jfr Thanks Erik From markus.gronlund at oracle.com Thu Mar 5 14:22:31 2020 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 5 Mar 2020 06:22:31 -0800 (PST) Subject: RFR: 8222000: JFR: Process start event In-Reply-To: References: Message-ID: <632cf65e-7619-45c9-8068-013e0ecaba18@default> Hi Erik, Looks good. Quite straightforward, thank you for adding this capability. Thanks Markus -----Original Message----- From: Erik Gahlin Sent: den 5 mars 2020 15:11 To: hotspot-jfr-dev ; core-libs-dev at openjdk.java.net Subject: RFR: 8222000: JFR: Process start event Hi Could I have review of a JFR event that is emitted when a process is started from Java. Bug: https://bugs.openjdk.java.net/browse/JDK-8222000 Webrev: http://cr.openjdk.java.net/~egahlin/8222000/ Testing: tier1,tier2 + jdk/jdk/jfr Thanks Erik From Roger.Riggs at oracle.com Thu Mar 5 14:27:59 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 5 Mar 2020 09:27:59 -0500 Subject: RFR: 8222000: JFR: Process start event In-Reply-To: References: Message-ID: <9c0f1d28-de53-5737-1d99-0d8df070619a@oracle.com> Hi Erik, Would the event be more useful if the executable arg[0] was a separate field from the arguments? Though I exect it depends on what is later evaluating the event fields. If all of cmdarrray is being joined, then the event field name is more appropriately called 'command';? similar to the single arg form of Runtime.exec and new ProcessBuilder(...). A small point but the joining with ' ' space has the usual problem of trying to parse out the arguments later. using ',' comma might be less ambiguous.? (and Arrays.toString). Otherwise, looks fine to me. Is there already a Process exited event? Its not quite as convenient to instrument but useful if it captures the exit status. (ProcessImpl - Windows and Linux versions). Roger On 3/5/20 9:10 AM, Erik Gahlin wrote: > Hi > > Could I have review of a JFR event that is emitted when a process is > started from Java. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8222000 > > Webrev: > http://cr.openjdk.java.net/~egahlin/8222000/ > > Testing: > tier1,tier2 + jdk/jdk/jfr > > Thanks > Erik > > > > From adam.farley at uk.ibm.com Thu Mar 5 14:31:54 2020 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 5 Mar 2020 14:31:54 +0000 Subject: RFR: 8239365: ProcessBuilder/Basic.java test modifications for AIX execution In-Reply-To: References: Message-ID: Hi All, As mentioned by Tom, a third opinion is sought on the aforementioned minor test change. @Tom - I'd prefer to use the full version of the error messages to keep things clear, though I would not object to using your abbreviated version if it means getting the change in. So long as it passes when it should pass, and fails only when it should fail, clarity is a "would be nice", but ultimately a secondary priority. Thanks for your feedback. :) Best Regards Adam Farley IBM Runtimes "Thomas St?fe" wrote on 03/03/2020 10:52:10: > From: "Thomas St?fe" > To: Adam Farley8 > Cc: core-libs-dev > Date: 03/03/2020 10:52 > Subject: [EXTERNAL] Re: RFR: 8239365: ProcessBuilder/Basic.java test > modifications for AIX execution > > This is why I always was against handing up the result of strerror > to the user :) The same problem we would have when running with > different locales. We should have a platform agnostic string table > in the java lib for that purpose... > > As for the test, looks good, but I personally would shorten the AIX > patterns a bit or maybe try to find a short form fitting all > platforms (e.g. "[Pp]ermission"). > > But thats just idle bikeshedding, lets see what others think. > > Cheers Thomas > > On Tue, Mar 3, 2020 at 11:43 AM Adam Farley8 wrote: > Hi All, > > Reviews and sponsor requested for a small test change. > > Short version: When an AIX machine has the file set "bos.msg.en_US.rte", > the error messages are not in a form that the test expects, causing > failure. > > The simplest option appears to be adding the second potential form of the > message into the regex (see webrev). > > http://cr.openjdk.java.net/~afarley/8239365.1/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8239365 > > Best Regards > > Adam Farley > IBM Runtimes > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From aauclair at curtisswright.com Thu Mar 5 14:42:33 2020 From: aauclair at curtisswright.com (Auclair, Andrew) Date: Thu, 5 Mar 2020 14:42:33 +0000 Subject: jpackage Linux rpath Message-ID: <4e9553b9506345098824f95e9be2fe24@useimail1301.ATL.CW.LOCAL> Hi, We are in the process of upgrading to jpackage in Java 14 from javapackager in Java 10. So far the transition has been smooth and we're really liking jpackage. One question has come up regarding our Linux install. Currently we are using Patchelf on CentOS to set an rpath for the executables generated by javapackager. We have continued this with jpackage, but we were wondering if there's a way to set the rpath with jpackage to avoid using Patchelf. Thanks, Andrew Auclair Software Engineer Tactical Communications Group A Curtiss-Wright Company 2 Highwood Drive, Building 2, Suite 200 Tewksbury, MA 01876-1157 ---------------------------------------------------------------------- This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to the U.S. Export Regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with U.S. Export Regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. From christoph.langer at sap.com Thu Mar 5 15:06:59 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Mar 2020 15:06:59 +0000 Subject: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start In-Reply-To: <2516AAC0-4D5B-4C10-8B86-E41152E56109@oracle.com> References: <51EF8E30-12C0-4CDA-9E2E-79F250375567@oracle.com> <4256fa6d-cd3b-4852-72c6-7c9acbd8b489@gmail.com> <3B2A5184-B592-4F3F-80AF-5FCF8AF7035C@oracle.com> <1AE7AAAE-DA56-44AD-B932-AF7EF9F00BA9@oracle.com> <02FEC2C4-365E-4EB1-BA4F-37D0C0CD13DD@oracle.com> <2516AAC0-4D5B-4C10-8B86-E41152E56109@oracle.com> Message-ID: Hi Lance, The revised webrev is at http://cr.openjdk.java.net/~lancea/8211917/webrev.02/index.html This looks good to me now. Ship it ?? Cheers Christoph From denghui.ddh at alibaba-inc.com Thu Mar 5 15:19:11 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 05 Mar 2020 23:19:11 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIzODY2NTogQWRkIEpGUiBldmVudCBmb3IgZGlyZWN0IG1lbW9yeSBzdGF0?= =?UTF-8?B?aXN0aWNz?= In-Reply-To: <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com>, <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> Message-ID: Hi Alan and Erik, Sorry, I'm not sure if I fully understand what you mean. For this feature, I still think exporting jdk.internal.access to jdk.jfr is a good solutionsince there are some other packages has already exported to jdk.jfr in this module. Thanks, Denghui Dong ------------------------------------------------------------------ From:Erik Gahlin Send Time:2020?3?5?(???) 19:55 To:???(??) Cc:hotspot-jfr-dev ; core-libs-dev ; Alan Bateman Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics We should avoid adding a dependency on java.management. The jdk.jfr module today only depends java.base so JFR can be used in constrained environments. All JMX related functionality is in jdk.management.jfr. Erik On 5 Mar 2020, at 10:54, Denghui Dong wrote: Hi Alan, If I use ManagementFactoryHelper to get memory pools, I still need to modify src/java.management/share/classes/module-info.java to export sun.management, right? Thanks, Denghui Dong ------------------------------------------------------------------ From:Alan Bateman Send Time:2020?3?5?(???) 16:46 To:???(??) ; Erik Gahlin ; hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics On 05/03/2020 02:44, Denghui Dong wrote: > Hi Erik, > Updated. > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ > ManagementFactoryHelper has a method to get the list of MXBeans for the buffer pools. That could be easily changed to return an unmodifable list. That would allow you to emit statistics for memory-mapped files too (the current patch seems to be limited to emitting stats for direct buffers). -Alan. From naoto.sato at oracle.com Thu Mar 5 16:58:27 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 5 Mar 2020 08:58:27 -0800 Subject: [15] RFR: 8216332: Grapheme regex does not work with emoji sequences Message-ID: <60545389-a3ac-eddb-2c5e-fe6ef67ae1c7@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8216332 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8216332/webrev.00/ Before this fix, the rule GB11 (Do not break within emoji modifier sequences or emoji zwj sequences [1]) was only applied once, and was ignored thereafter for the repeated possible rule candidates. The fix is to simply stop resetting the GB11 mode. Naoto [1] https://unicode.org/reports/tr29/#GB11 From ioi.lam at oracle.com Thu Mar 5 17:17:29 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 5 Mar 2020 09:17:29 -0800 Subject: RFR(S): 8232081: Try to link all classes during dynamic CDS dump In-Reply-To: <7a54e00f-c049-a5ef-0afc-bb6c9d0f30ad@oracle.com> References: <9b40145a-db72-6313-3b98-5e5aea754e25@oracle.com> <1167ff6d-3997-6390-d020-d0946fad0af8@oracle.com> <3f373a33-c7ed-0237-1dd5-f8ac8e8794ee@oracle.com> <8ac4612b-fae3-bb16-f2ab-fa323c33ca51@oracle.com> <00090c43-1e0d-2b1c-d2a5-1b5f1b29199d@oracle.com> <7a54e00f-c049-a5ef-0afc-bb6c9d0f30ad@oracle.com> Message-ID: <5fa95d9f-47a7-c1c7-90e5-87db0173e3b7@oracle.com> Hi Calvin, Looks good overall. I just have two comment: I think this is not needed: ?306 void ConstantPool::resolve_class_constants(TRAPS) { ?307?? Arguments::assert_is_dumping_archive(); because this function is used to resolve all Strings in the statically dumped classes to archive all the Strings. However, the archive heap is not supported for the dynamic archive. So I think it's better to avoid calling this function from LinkSharedClassesClosure for dynamic dump. LinkSharedClassesClosure::_is_static -- maybe we can avoid adding this field and just check "if (DumpSharedSpaces)" instead? Thanks - Ioi On 3/4/20 9:13 PM, Calvin Cheung wrote: > Hi David, Ioi, > > Here's an updated webrev which doesn't involve changing > InstanceKlass::verify_on() and made use of the changes for JDK-8240481. > > ??? http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.03/ > > thanks, > Calvin > > On 3/1/20 10:14 PM, David Holmes wrote: >> Hi Calvin, >> >> On 28/02/2020 4:12 pm, Calvin Cheung wrote: >>> Hi David, >>> >>> On 2/27/20 5:40 PM, David Holmes wrote: >>>> Hi Calvin, Ioi, >>>> >>>> Looking good - comments below. >>>> >>>> A meta-question: normal application classes are rarely loaded but >>>> not linked so I'm a little surprised this is an issue. What is the >>>> main source of such classes - generated classes like lambda forms? >>>> Also why do we need to link them when loading from the archive if >>>> they were never linked when the application actually executed ?? >>> >>> I saw that Ioi already answered the above. >>> >>> I'll try to answer your questions inline below.. >> >> Responses inline below ... >> >>>> >>>> On 28/02/2020 10:48 am, Calvin Cheung wrote: >>>>> Hi David, Ioi, >>>>> >>>>> Thanks for your review and suggestions. >>>>> >>>>> On 2/26/20 9:46 PM, Ioi Lam wrote: >>>>>> >>>>>> >>>>>> On 2/26/20 7:50 PM, David Holmes wrote: >>>>>>> Hi Calvin, >>>>>>> >>>>>>> Adding core-libs-dev as you are messing with their code :) >>>>>>> >>>>>>> On 27/02/2020 1:19 pm, Calvin Cheung wrote: >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8232081 >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/ >>>>>>>> >>>>>>>> The proposed changeset for this RFE adds a >>>>>>>> JVM_LinkClassesForCDS() function to be called from >>>>>>>> java/lang/Shutdown to notify the JVM to link the classes loaded >>>>>>>> by the builtin class loaders. The >>>>>>> >>>>>>> This would be much less disruptive if this was handled purely on >>>>>>> the VM side once we have started shutdown. No need to make any >>>>>>> changes to the Java side then, nor jvm.cpp. >>>>>>> >>>>>> >>>>>> Hi David, >>>>>> >>>>>> To link the classes, we need to be able to run Java code -- when >>>>>> linking a class X loaded by the app loader, X will be verified. >>>>>> During verification of X, we may need to load additional classes >>>>>> from the app loader, which executes Java code during its class >>>>>> loading operations. >>>>>> >>>>>> We also need to handle all the exit conditions. As far as I can >>>>>> tell, an app can exit the JVM in two ways: >>>>>> >>>>>> (1) Explicitly calling System.exit(). This will call >>>>>> java.lang.Shutdown.exit() which does this: >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l163 >>>>>> >>>>>> >>>>>> ??????????? beforeHalt(); // native >>>>>> ??????????? runHooks(); >>>>>> ??????????? halt(status); >>>>>> >>>>>> (2) When all non-daemon threads have died (e.g., falling out of >>>>>> the bottom of HelloWorld.main()). There's no explicit call to >>>>>> System.exit(), but the JVM will proactively call >>>>>> java.lang.Shutdown.shutdown() inside >>>>>> JavaThread::invoke_shutdown_hooks() >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/hotspot/share/runtime/thread.cpp#l4331 >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l184 >>>>>> >>>>>> >>>>>> If we want to avoid modifying the Java code, I think we can >>>>>> intercept JVM_BeforeHalt() and >>>>>> JavaThread::invoke_shutdown_hooks(). This way we should be able >>>>>> to handle all the classes (except those that are loaded inside >>>>>> Shutdown.runHooks). >>>>> >>>>> I've implemented the above. No changes to the Java side. >>>>> >>>>> updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.01/ >>>> >>>> This looks much better to me. I wasn't sure if you were that >>>> concerned about catching the classes loaded by the Shutdown hooks, >>>> but it is good you are not as it seems problematic to me to trigger >>>> class loading etc after the shutdown hooks have executed - you may >>>> hit unexpected conditions. So this approach is good. >>>> >>>> A few minor comments: >>>> >>>> src/hotspot/share/memory/metaspaceShared.cpp >>>> src/hotspot/share/memory/metaspaceShared.hpp >>>> >>>> Why the change from TRAPS to "Thread* THREAD"? >>> I forgot why I changed it but I've changed it back and it still works. >> >> Ok. >> >>>> >>>> --- >>>> >>>> src/hotspot/share/oops/instanceKlass.cpp >>>> >>>> I'm not clear how verify_on is used so am unsure how the additional >>>> error state check may affect code unrelated to dynamic dumping ?? >>> >>> Some of the appcds tests by design have some classes which fail >>> verification. Without the change, the following assert would fail: >>> >>> void vtableEntry::verify(klassVtable* vt, outputStream* st) { >>> ?? Klass* vtklass = vt->klass(); >>> ?? if (vtklass->is_instance_klass() && >>> ????? (InstanceKlass::cast(vtklass)->major_version() >= >>> klassVtable::VTABLE_TRANSITIVE_OVERRIDE_VERSION)) { >>> *assert*(method() != NULL, "must have set method"); >>> ?? } >> >> Okay so you need to exclude for that case but ... >> >>> Here's the call stack during dynamic CDS dump to the above function: >>> >>> vtableEntry::verify(klassVtable *, outputStream *) : void >>> ???? klassVtable::verify(outputStream *, bool) : void >>> ???????? InstanceKlass::verify_on(outputStream *) : void >>> ???????????? Klass::verify() : void >>> ???????????????? ClassLoaderData::verify() : void >>> ???????????????????? ClassLoaderDataGraph::verify() : void >>> ???????????????????????? Universe::verify(enum VerifyOption, const >>> char *) : void >>> ???????????????????????????? Universe::verify(const char *) : void >>> DynamicArchiveBuilder::verify_universe(const char *) : void >>> DynamicArchiveBuilder::doit() : void (2 matches) >>> VM_PopulateDynamicDumpSharedSpace::doit() : void >>> VM_Operation::evaluate() : void >>> >>> The is_linked() function is implemented as: >>> >>> ???? bool is_linked() const?????????????????? { return _init_state >>> >= linked; } >>> >>> which includes 'initialization_error'. >> >> ... AFAICS Universe::verify is call from a number of places, all of >> which would reach this modified code. As that existing code has >> included classes that are in the error state then it seems to me that >> unless you can prove otherwise you need to keep the existing code >> as-is for the non-CDS dump case. >> >>> A previous version of the changeset (including the change in >>> question in instanceKlass.cpp) passed tier1 - 4 testing. Let me know >>> if I should run other tests to make sure the change is good. >> >> There may well not be a test that covers this. >> >> Thanks, >> David >> >>>> >>>> Also can I suggest (as you are touching this code) to delete the >>>> ancient comment: >>>> >>>> 3580???? // $$$ This used to be done only for m/s collections. >>>> Doing it >>>> 3581???? // always seemed a valid generalization.? (DLD -- 6/00) >>> >>> I'm glad that you suggested to remove the above comment. I've no >>> clue what it means either. >>> >>> updated webrev: >>> >>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.02/ >>> >>> thanks, >>> Calvin >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> I also updated the test to test the shutdown hook and >>>>> System.exit() scenarios. >>>>> >>>>> All appcds tests passed on my linux host. I'll run more tests >>>>> using mach5. >>>>> >>>>> thanks, >>>>> >>>>> Calvin >>>>> >>>>> >>>>>> >>>>>> What do you think? >>>>>> >>>>>> - Ioi >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> MetaspaceShared::link_and_cleanup_shared_classes() has been >>>>>>>> modified to handle both static and dynamic CDS dump. For >>>>>>>> dynamic CDS dump, only classes loaded by the builtin class >>>>>>>> loaders will be linked. Local performance testing using javac >>>>>>>> on HelloWorld.java shows an improvement of >5%. >>>>>>>> >>>>>>>> Passed tier1 - 4 tests. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Calvin >>>>>>>> >>>>>> From erik.gahlin at oracle.com Thu Mar 5 17:21:41 2020 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 5 Mar 2020 18:21:41 +0100 Subject: RFR: 8222000: JFR: Process start event In-Reply-To: <9c0f1d28-de53-5737-1d99-0d8df070619a@oracle.com> References: <9c0f1d28-de53-5737-1d99-0d8df070619a@oracle.com> Message-ID: <690737ba-da3a-ba7c-3513-ba16cdcdd07e@oracle.com> Hi Roger, Thanks for the feedback. Runtime.exec doesn't take arg[0] as a separate parameter, so it may make sense to not split it up in the event. For example, if plan is to execute "hg clone url", but the user forgets to add "hg", then it will look as if "clone" is the command, which could be confusing. I will change the field name to 'command' to make it consistent with the single arg form of Runtime.exec. Regarding delimiters, I think there are two use cases. Making something easy for humans to read and making it unambiguous for machine parsing. Since comma, or comma space, might be part of an argument, it is still unsafe for a parser. It would be possible to add escape sequences, but then it would be even harder for humans to read, which I think is the main use case. If we in the future would add support for serializing a String[], we could add another field, i.e. commandArray, which would work for machines without special parse logic. There is no ProcessEnd event today, but that is something that could be added in the future. The exit status could be useful. Updated webrev: http://cr.openjdk.java.net/~egahlin/8222000/ Thanks Erik On 2020-03-05 15:27, Roger Riggs wrote: > Hi Erik, > > Would the event be more useful if the executable arg[0] was a separate > field from the arguments? > Though I exect it depends on what is later evaluating the event fields. > > If all of cmdarrray is being joined, then the event field name is more > appropriately > called 'command';? similar to the single arg form of Runtime.exec and > new ProcessBuilder(...). > > A small point but the joining with ' ' space has the usual problem of > trying to parse out the arguments later. > using ',' comma might be less ambiguous.? (and Arrays.toString). > > Otherwise, looks fine to me. > > Is there already a Process exited event? Its not quite as convenient > to instrument but useful if it captures the exit status. (ProcessImpl > - Windows and Linux versions). > > Roger > > > > On 3/5/20 9:10 AM, Erik Gahlin wrote: >> Hi >> >> Could I have review of a JFR event that is emitted when a process is >> started from Java. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8222000 >> >> Webrev: >> http://cr.openjdk.java.net/~egahlin/8222000/ >> >> Testing: >> tier1,tier2 + jdk/jdk/jfr >> >> Thanks >> Erik >> >> >> >> > From vipinsharma85 at gmail.com Thu Mar 5 17:26:48 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Thu, 5 Mar 2020 22:56:48 +0530 Subject: RFR 8240524: Removed warnings from test classes Message-ID: Hi All, Please review patch to remove warnings from test classes. Bug : https://bugs.openjdk.java.net/browse/JDK-8240524 Webrev : http://cr.openjdk.java.net/~clanger/webrevs/8240524.0/ Change description: Class: test/jdk/java/lang/Boolean/GetBoolean.java Fixed following warning: 1. "Exception 'java.lang.Exception' is never thrown in the method? Class: test/jdk/java/lang/Boolean/MakeBooleanComparable.java Fixed following warnings: 1. Explicit type argument Boolean can be replaced with <> 2. C-style array declaration of parameter 'args' Class: test/jdk/java/lang/Boolean/ParseBoolean.java Fixed following warning: 1. Exception 'java.lang.Exception' is never thrown in the method Regards, Vipin From erik.gahlin at oracle.com Thu Mar 5 17:36:42 2020 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 5 Mar 2020 18:36:42 +0100 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> Message-ID: Yes, I think it is fine to export from java.base to jdk.jfr for this feature. If you would add support for other buffer pools, it should not be over MXBeans, but using classes/interfaces that is available in java.base. Erik On 2020-03-05 16:19, Denghui Dong wrote: > Hi?Alan?and?Erik, > > Sorry,?I'm?not?sure?if?I?fully?understand?what?you?mean. > For?this?feature,?I?still?think?exporting?jdk.internal.access?to?jdk.jfr?is?a?good?solutionsince?there?are > some?other?packages?has?already?exported?to?jdk.jfr?in?this?module. > > Thanks, > Denghui?Dong > > ------------------------------------------------------------------ > From:Erik Gahlin > Send Time:2020?3?5?(???) 19:55 > To:???(??) > Cc:hotspot-jfr-dev ; > core-libs-dev ; Alan Bateman > > Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics > > We should avoid adding a dependency on java.management. The > jdk.jfr module today only depends java.base so JFR can be used in > constrained environments. All JMX related functionality is in > jdk.management.jfr. > > Erik > > On 5 Mar 2020, at 10:54, Denghui Dong > wrote: > > Hi Alan, > > If I use?ManagementFactoryHelper to get memory pools, I still > need to modify?src/java.management/share/classes/module-info.java > to export sun.management, right? > > Thanks, > Denghui Dong > ------------------------------------------------------------------ > From:Alan Bateman > > Send Time:2020?3?5?(???) 16:46 > To:???(??) >; Erik Gahlin > >; > hotspot-jfr-dev >; core-libs-dev > > > Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics > > On?05/03/2020?02:44,?Denghui?Dong?wrote: > >?Hi?Erik, > >?Updated. > >?Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ > > > ManagementFactoryHelper?has?a?method?to?get?the?list?of?MXBeans?for?the > > buffer?pools.?That?could?be?easily?changed?to?return?an?unmodifable > list.?That?would?allow?you?to?emit?statistics?for?memory-mapped?files > too?(the?current?patch?seems?to?be?limited?to?emitting?stats?for?direct > > buffers). > > -Alan. > From Roger.Riggs at oracle.com Thu Mar 5 18:02:05 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 5 Mar 2020 13:02:05 -0500 Subject: RFR: 8222000: JFR: Process start event In-Reply-To: <690737ba-da3a-ba7c-3513-ba16cdcdd07e@oracle.com> References: <9c0f1d28-de53-5737-1d99-0d8df070619a@oracle.com> <690737ba-da3a-ba7c-3513-ba16cdcdd07e@oracle.com> Message-ID: Hi Erik, The update looks fine. On 3/5/20 12:21 PM, Erik Gahlin wrote: > Hi Roger, > > Thanks for the feedback. > > Runtime.exec doesn't take arg[0] as a separate parameter, so it may > make sense to not split it up in the event. For example, if plan is to > execute "hg clone url", but the user forgets to add "hg", then it will > look as if "clone" is the command, which could be confusing. The main interface for launching processes is ProcessBuilder. Runtime.exec is a legacy interface and no longer drives the terminology. > > I will change the field name to 'command' to make it consistent with > the single arg form of Runtime.exec. tnx > > Regarding delimiters, I think there are two use cases. Making > something easy for humans to read and making it unambiguous for > machine parsing. Since comma, or comma space, might be part of an > argument, it is still unsafe for a parser. It would be possible to add > escape sequences, but then it would be even harder for humans to read, > which I think is the main use case. If we in the future would add > support for serializing a String[], we could add another field, i.e. > commandArray, which would work for machines without special parse logic. understood, it wasn't clear what the focus of a string in the JFR stream is intended to mean or how it would be interpreted. I'm thinking that more and more it will be tools and AI's (not people) that will be looking through the reams and reams of output at scale. > > There is no ProcessEnd event today, but that is something that could > be added in the future. The exit status could be useful. one step at a time. Thanks, Roger > > Updated webrev: > http://cr.openjdk.java.net/~egahlin/8222000/ > > Thanks > Erik > > On 2020-03-05 15:27, Roger Riggs wrote: >> Hi Erik, >> >> Would the event be more useful if the executable arg[0] was a >> separate field from the arguments? >> Though I exect it depends on what is later evaluating the event fields. >> >> If all of cmdarrray is being joined, then the event field name is >> more appropriately >> called 'command';? similar to the single arg form of Runtime.exec and >> new ProcessBuilder(...). >> >> A small point but the joining with ' ' space has the usual problem of >> trying to parse out the arguments later. >> using ',' comma might be less ambiguous.? (and Arrays.toString). >> >> Otherwise, looks fine to me. >> >> Is there already a Process exited event? Its not quite as convenient >> to instrument but useful if it captures the exit status. (ProcessImpl >> - Windows and Linux versions). >> >> Roger >> >> >> >> On 3/5/20 9:10 AM, Erik Gahlin wrote: >>> Hi >>> >>> Could I have review of a JFR event that is emitted when a process is >>> started from Java. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8222000 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~egahlin/8222000/ >>> >>> Testing: >>> tier1,tier2 + jdk/jdk/jfr >>> >>> Thanks >>> Erik >>> >>> >>> >>> >> From glaubitz at physik.fu-berlin.de Tue Mar 3 22:18:57 2020 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 3 Mar 2020 23:18:57 +0100 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <4081af4f-372d-911e-840b-de97847cba3a@redhat.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2310d10b-64ec-5680-a780-71138252a259@oracle.com> <3e097a38-2bad-0fa2-e16a-993a4a2718e5@oracle.com> <3923dfe9-a3e5-49ab-dd65-0cf8950b9cc4@redhat.com> <4081af4f-372d-911e-840b-de97847cba3a@redhat.com> Message-ID: <179814ed-649b-93c4-1894-a0f16423d3d3@physik.fu-berlin.de> On 3/3/20 10:26 AM, Andrew Haley wrote: > But one of the few things of which I am certain is that we must not > allow the needs of backporting to determine the future of Java. That's > the way of staying in the past. Unpopular opinion: It's the enterprise customers that mainly pay for the development of software, not the users of rolling release distributions. I know that maintaining old stuff is boring but that's where the money is made. Too many developers unfortunately seem to forget that. > As Patrick Head put it, ?Some people tell me that Formula 1 would be > better if the drivers still used stick shifts, but that?s a bit like > saying, 'isn?t it a pity we don?t still walk around in clogs!'? Maintenance of stable software isn't done for nostalgic reasons, it's because enterprise customers need a reliable and stable platform to run their businesses on. A lot of businesses are still running on JDK-8 for this reason. Running bleeding edge software might be an option for a single desktop user, but not in an enterprise environment with thousands of users or in a critical environment like the booking system of an airline. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From alexey.semenyuk at oracle.com Thu Mar 5 18:50:47 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 5 Mar 2020 13:50:47 -0500 Subject: jpackage Linux rpath In-Reply-To: <4e9553b9506345098824f95e9be2fe24@useimail1301.ATL.CW.LOCAL> References: <4e9553b9506345098824f95e9be2fe24@useimail1301.ATL.CW.LOCAL> Message-ID: <7db36eef-cbcf-74b3-0513-12921fbed850@oracle.com> Hi Andrew, jpackage is providing similar functionality as javapackager, so I think you need to keep using patchelf with jpackage as you used it with javapackager. I assume you use jpackage in two phases. The first phase creates application image and you use patchelf on launchers created by jpackage and then in the second phase you pack application image with modified launchers into rpm/deb package. If this is the case and you would benefit from running jpackage in one phase, then I can think of adding to jpackage ability to run 3rd party script after application image creation. In this case you will need to create shell script using patchelf, place the script in resource directory so that jpackage can run the script after application image is created but before building rpm/deb package. - Alexey On 3/5/2020 9:42 AM, Auclair, Andrew wrote: > Hi, > > We are in the process of upgrading to jpackage in Java 14 from javapackager in Java 10. So far the transition has been smooth and we're really liking jpackage. > > One question has come up regarding our Linux install. Currently we are using Patchelf on CentOS to set an rpath for the executables generated by javapackager. We have continued this with jpackage, but we were wondering if there's a way to set the rpath with jpackage to avoid using Patchelf. > > Thanks, > > Andrew Auclair > Software Engineer > Tactical Communications Group > A Curtiss-Wright Company > 2 Highwood Drive, Building 2, Suite 200 > Tewksbury, MA 01876-1157 > > ---------------------------------------------------------------------- > This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to the U.S. Export Regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with U.S. Export Regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. From aauclair at curtisswright.com Thu Mar 5 18:57:40 2020 From: aauclair at curtisswright.com (Auclair, Andrew) Date: Thu, 5 Mar 2020 18:57:40 +0000 Subject: jpackage Linux rpath [EXTERNAL] In-Reply-To: <7db36eef-cbcf-74b3-0513-12921fbed850@oracle.com> References: <4e9553b9506345098824f95e9be2fe24@useimail1301.ATL.CW.LOCAL> <7db36eef-cbcf-74b3-0513-12921fbed850@oracle.com> Message-ID: <08e24f1376cb4d2cb801034c7c373417@useimail1301.ATL.CW.LOCAL> Hi Alexey, Thanks for the response! I think we will continue to do what we're doing now because it works just fine and is pretty simple. If anyone d is interested, this is how we do it: We run everything through a doLast in our build.gradle file and run an exec {} for jpackage and then if we're on linux we run another exec {} for patchelf. exec { def icon executable "${System.env.JAVA_HOME}/bin/jpackage" if (OperatingSystem.current().isLinux()) { icon = "Example.png" } else { icon = " Example.ico" } args = ["--type", "app-image", "--icon", icon, "--input", "build/libs", "--dest", "build/install/tmp", "--name", " Example ", "--main-class", "com.example", "--main-jar", " Example.jar"] } if (OperatingSystem.current().isLinux()) { exec { executable "patchelf" args = ["--force-rpath", "--set-rpath", "\$ORIGIN", "../build/install/Example "] } } Thanks Again, Andrew -----Original Message----- From: Alexey Semenyuk Sent: Thursday, March 5, 2020 1:51 PM To: Auclair, Andrew ; core-libs-dev at openjdk.java.net Subject: Re: jpackage Linux rpath [EXTERNAL] Hi Andrew, jpackage is providing similar functionality as javapackager, so I think you need to keep using patchelf with jpackage as you used it with javapackager. I assume you use jpackage in two phases. The first phase creates application image and you use patchelf on launchers created by jpackage and then in the second phase you pack application image with modified launchers into rpm/deb package. If this is the case and you would benefit from running jpackage in one phase, then I can think of adding to jpackage ability to run 3rd party script after application image creation. In this case you will need to create shell script using patchelf, place the script in resource directory so that jpackage can run the script after application image is created but before building rpm/deb package. - Alexey On 3/5/2020 9:42 AM, Auclair, Andrew wrote: > Hi, > > We are in the process of upgrading to jpackage in Java 14 from javapackager in Java 10. So far the transition has been smooth and we're really liking jpackage. > > One question has come up regarding our Linux install. Currently we are using Patchelf on CentOS to set an rpath for the executables generated by javapackager. We have continued this with jpackage, but we were wondering if there's a way to set the rpath with jpackage to avoid using Patchelf. > > Thanks, > > Andrew Auclair > Software Engineer > Tactical Communications Group > A Curtiss-Wright Company > 2 Highwood Drive, Building 2, Suite 200 Tewksbury, MA 01876-1157 > > ---------------------------------------------------------------------- > This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to the U.S. Export Regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with U.S. Export Regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. ---------------------------------------------------------------------- This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to the U.S. Export Regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with U.S. Export Regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. From snazy at gmx.de Thu Mar 5 19:00:50 2020 From: snazy at gmx.de (Robert Stupp) Date: Thu, 05 Mar 2020 20:00:50 +0100 Subject: argfiles parsing broken for argfiles > 4096 bytes Message-ID: <1768c55f6ba0722d96f2bb978c3ce3f820779cfa.camel@gmx.de> Hi, I recently came across a bug in the java executable with an argfile that's larger than 4096 bytes, if a 4096-byte-chunk ends in a comment line. One bug happens when the last character of a comment line is the 4096th byte and the trailing newline is the first byte in the next chunk. In that case, nextToken() in src/java.base/share/native/libjli/args.c calls JLI_List_addSubstring (in the if-block at the end of nextToken()) with the contents of the current comment line. The next "valid" option gets appended to that comment line and java errors out. I've added some debugging output to the last if-block and pctx- >state==FIND_NEXT and the the substring being added is the comment line. I've also tried and changed this line http://hg.openjdk.java.net/jdk-updates/jdk11u/annotate/20e49753c388/src/java.base/share/native/libjli/args.c#l294 to 'if (anchor != nextc && pctx->state == IN_TOKEN)' and the argfile is parsed correctly. Steps to reproduce:1. save the attached my-argfile2. run 'java @my- argfile my.className'3. java errors out with Error: Could not find or load main class # XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-Dfoo=barCaused by: java.lang.ClassNotFoundException: # XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-Dfoo=bar With the above change (the attached patch in argfile-parse-bug.txt), argfile parsing works as expected.Also updated the condition in the loop looking for a comment's newline, as it looks inconsistent to the condition in the loop for FIND_NEXT/SKIP_LEAD_WS and the condition of the outer for-loop. Robert -------------- next part -------------- # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # 23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 # XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # 2345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 -Dfoo=bar -------------- next part -------------- diff -r 20e49753c388 src/java.base/share/native/libjli/args.c --- a/src/java.base/share/native/libjli/args.c Wed Mar 04 15:26:22 2020 +0100 +++ b/src/java.base/share/native/libjli/args.c Thu Mar 05 19:57:55 2020 +0100 @@ -216,7 +216,7 @@ } else if (pctx->state == IN_COMMENT) { while (ch != '\n' && ch != '\r') { nextc++; - if (nextc > eob) { + if (nextc >= eob) { return NULL; } ch = *nextc; @@ -291,7 +291,7 @@ } assert(nextc == eob); - if (anchor != nextc) { + if (anchor != nextc && pctx->state == IN_TOKEN) { // not yet return until end of stream, we have part of a token. JLI_List_addSubstring(pctx->parts, anchor, nextc - anchor); } From alexey.semenyuk at oracle.com Thu Mar 5 19:02:36 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 5 Mar 2020 14:02:36 -0500 Subject: jpackage Linux rpath [EXTERNAL] In-Reply-To: <08e24f1376cb4d2cb801034c7c373417@useimail1301.ATL.CW.LOCAL> References: <4e9553b9506345098824f95e9be2fe24@useimail1301.ATL.CW.LOCAL> <7db36eef-cbcf-74b3-0513-12921fbed850@oracle.com> <08e24f1376cb4d2cb801034c7c373417@useimail1301.ATL.CW.LOCAL> Message-ID: Andrew, Thank you for sharing! As far as I can see you use jpackage to create application image. I think your solution is optimal for this scenario. - Alexey On 3/5/2020 1:57 PM, Auclair, Andrew wrote: > Hi Alexey, > > Thanks for the response! I think we will continue to do what we're doing now because it works just fine and is pretty simple. > > If anyone d is interested, this is how we do it: We run everything through a doLast in our build.gradle file and run an exec {} for jpackage and then if we're on linux we run another exec {} for patchelf. > > exec { > def icon > executable "${System.env.JAVA_HOME}/bin/jpackage" > if (OperatingSystem.current().isLinux()) { > icon = "Example.png" > } > else { > icon = " Example.ico" > } > args = ["--type", "app-image", "--icon", icon, "--input", "build/libs", "--dest", "build/install/tmp", "--name", " Example ", "--main-class", "com.example", "--main-jar", " Example.jar"] > } > if (OperatingSystem.current().isLinux()) { > exec { > executable "patchelf" > args = ["--force-rpath", "--set-rpath", "\$ORIGIN", "../build/install/Example "] > } > } > > Thanks Again, > Andrew > > -----Original Message----- > From: Alexey Semenyuk > Sent: Thursday, March 5, 2020 1:51 PM > To: Auclair, Andrew ; core-libs-dev at openjdk.java.net > Subject: Re: jpackage Linux rpath [EXTERNAL] > > Hi Andrew, > > jpackage is providing similar functionality as javapackager, so I think you need to keep using patchelf with jpackage as you used it with javapackager. > I assume you use jpackage in two phases. The first phase creates application image and you use patchelf on launchers created by jpackage and then in the second phase you pack application image with modified launchers into rpm/deb package. > If this is the case and you would benefit from running jpackage in one phase, then I can think of adding to jpackage ability to run 3rd party script after application image creation. In this case you will need to create shell script using patchelf, place the script in resource directory so that jpackage can run the script after application image is created but before building rpm/deb package. > > - Alexey > > On 3/5/2020 9:42 AM, Auclair, Andrew wrote: >> Hi, >> >> We are in the process of upgrading to jpackage in Java 14 from javapackager in Java 10. So far the transition has been smooth and we're really liking jpackage. >> >> One question has come up regarding our Linux install. Currently we are using Patchelf on CentOS to set an rpath for the executables generated by javapackager. We have continued this with jpackage, but we were wondering if there's a way to set the rpath with jpackage to avoid using Patchelf. >> >> Thanks, >> >> Andrew Auclair >> Software Engineer >> Tactical Communications Group >> A Curtiss-Wright Company >> 2 Highwood Drive, Building 2, Suite 200 Tewksbury, MA 01876-1157 >> >> ---------------------------------------------------------------------- >> This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to the U.S. Export Regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with U.S. Export Regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. > > ---------------------------------------------------------------------- > This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to the U.S. Export Regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with U.S. Export Regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. From aauclair at curtisswright.com Thu Mar 5 19:25:21 2020 From: aauclair at curtisswright.com (Auclair, Andrew) Date: Thu, 5 Mar 2020 19:25:21 +0000 Subject: jpackage Linux rpath [EXTERNAL] In-Reply-To: References: <4e9553b9506345098824f95e9be2fe24@useimail1301.ATL.CW.LOCAL> <7db36eef-cbcf-74b3-0513-12921fbed850@oracle.com> <08e24f1376cb4d2cb801034c7c373417@useimail1301.ATL.CW.LOCAL> Message-ID: Yes. I talked to a coworker and realized I glossed over that part. We run jpackage to create an application image and then use InstallBuilder to create an installer. We have 6 Java applications and dozens of C++ applications that all go into one big installer. Andrew -----Original Message----- From: Alexey Semenyuk Sent: Thursday, March 5, 2020 2:03 PM To: Auclair, Andrew ; core-libs-dev at openjdk.java.net Subject: Re: jpackage Linux rpath [EXTERNAL] Andrew, Thank you for sharing! As far as I can see you use jpackage to create application image. I think your solution is optimal for this scenario. - Alexey On 3/5/2020 1:57 PM, Auclair, Andrew wrote: > Hi Alexey, > > Thanks for the response! I think we will continue to do what we're doing now because it works just fine and is pretty simple. > > If anyone d is interested, this is how we do it: We run everything through a doLast in our build.gradle file and run an exec {} for jpackage and then if we're on linux we run another exec {} for patchelf. > > exec { > def icon > executable "${System.env.JAVA_HOME}/bin/jpackage" > if (OperatingSystem.current().isLinux()) { > icon = "Example.png" > } > else { > icon = " Example.ico" > } > args = ["--type", "app-image", "--icon", icon, "--input", > "build/libs", "--dest", "build/install/tmp", "--name", " Example ", > "--main-class", "com.example", "--main-jar", " Example.jar"] } if (OperatingSystem.current().isLinux()) { > exec { > executable "patchelf" > args = ["--force-rpath", "--set-rpath", "\$ORIGIN", "../build/install/Example "] > } > } > > Thanks Again, > Andrew > > -----Original Message----- > From: Alexey Semenyuk > Sent: Thursday, March 5, 2020 1:51 PM > To: Auclair, Andrew ; > core-libs-dev at openjdk.java.net > Subject: Re: jpackage Linux rpath [EXTERNAL] > > Hi Andrew, > > jpackage is providing similar functionality as javapackager, so I think you need to keep using patchelf with jpackage as you used it with javapackager. > I assume you use jpackage in two phases. The first phase creates application image and you use patchelf on launchers created by jpackage and then in the second phase you pack application image with modified launchers into rpm/deb package. > If this is the case and you would benefit from running jpackage in one phase, then I can think of adding to jpackage ability to run 3rd party script after application image creation. In this case you will need to create shell script using patchelf, place the script in resource directory so that jpackage can run the script after application image is created but before building rpm/deb package. > > - Alexey > > On 3/5/2020 9:42 AM, Auclair, Andrew wrote: >> Hi, >> >> We are in the process of upgrading to jpackage in Java 14 from javapackager in Java 10. So far the transition has been smooth and we're really liking jpackage. >> >> One question has come up regarding our Linux install. Currently we are using Patchelf on CentOS to set an rpath for the executables generated by javapackager. We have continued this with jpackage, but we were wondering if there's a way to set the rpath with jpackage to avoid using Patchelf. >> >> Thanks, >> >> Andrew Auclair >> Software Engineer >> Tactical Communications Group >> A Curtiss-Wright Company >> 2 Highwood Drive, Building 2, Suite 200 Tewksbury, MA 01876-1157 >> >> --------------------------------------------------------------------- >> - This e-mail and any files transmitted with it are proprietary and >> intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to the U.S. Export Regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with U.S. Export Regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. > > ---------------------------------------------------------------------- > This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to the U.S. Export Regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with U.S. Export Regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. ---------------------------------------------------------------------- This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to the U.S. Export Regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with U.S. Export Regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. From snazy at gmx.de Thu Mar 5 19:34:59 2020 From: snazy at gmx.de (Robert Stupp) Date: Thu, 05 Mar 2020 20:34:59 +0100 Subject: argfiles parsing broken for argfiles > 4096 bytes In-Reply-To: <1768c55f6ba0722d96f2bb978c3ce3f820779cfa.camel@gmx.de> References: <1768c55f6ba0722d96f2bb978c3ce3f820779cfa.camel@gmx.de> Message-ID: <6704dc02d2a4b8e140eb4d55cbae8204d6250fb2.camel@gmx.de> Sorry for the broken formatting... I recently came across a bug in the java executable with an argfile that's larger than 4096 bytes, if a 4096-byte-chunk ends in a comment line. The bug happens when the last character of a comment line is the 4096th byte and the trailing newline is the first byte in the next chunk. In that case, nextToken() in src/java.base/share/native/libjli/args.c calls JLI_List_addSubstring (in the if-block at the end of nextToken()) with the contents of the current comment line. The next "valid" option gets appended to that comment line and java errors out. I've added some debugging output to the last if-block and pctx-> state==FIND_NEXT and the the substring being added is the comment line. I've also tried and changed this line http://hg.openjdk.java.net/jdk-updates/jdk11u/annotate/20e49753c388/src/java.base/share/native/libjli/args.c#l294 to 'if (anchor != nextc && pctx->state == IN_TOKEN)' and the argfile is parsed correctly. Steps to reproduce: 1. save the attached my-argfile 2. run 'java @my-argfile my.className' 3. java errors out with Error: Could not find or load main class # XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -Dfoo=bar Caused by: java.lang.ClassNotFoundException: # XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -Dfoo=bar With the above change (the attached patch in argfile-parse-bug.txt), argfile parsing works as expected.Also updated the condition in the loop looking for a comment's newline, as it looks inconsistent to the condition in the loop for FIND_NEXT/SKIP_LEAD_WS and the condition of the outer for-loop. Robert On Thu, 2020-03-05 at 20:00 +0100, Robert Stupp wrote: > Hi, ... > From snazy at gmx.de Thu Mar 5 19:43:07 2020 From: snazy at gmx.de (Robert Stupp) Date: Thu, 05 Mar 2020 20:43:07 +0100 Subject: argfiles parsing broken for argfiles > 4096 bytes In-Reply-To: <6704dc02d2a4b8e140eb4d55cbae8204d6250fb2.camel@gmx.de> References: <1768c55f6ba0722d96f2bb978c3ce3f820779cfa.camel@gmx.de> <6704dc02d2a4b8e140eb4d55cbae8204d6250fb2.camel@gmx.de> Message-ID: <6014206a3374bf18059488bbf4cfae4bd0e687c7.camel@gmx.de> Another note: I've also seen it appending a comment-line in http://hg.openjdk.java.net/jdk-updates/jdk11u/annotate/20e49753c388/src/java.base/share/native/libjli/args.c#l296 with pctx->state==IN_COMMENT, but wasn't able to reconstruct the behavior with a "clean" argfile. But that behavior was also fixed with the condition ('&& pctx->state == IN_TOKEN') added by the patch. On Thu, 2020-03-05 at 20:34 +0100, Robert Stupp wrote: > Sorry for the broken formatting... > > I recently came across a bug in the java executable with an argfile > that's larger than 4096 bytes, if a 4096-byte-chunk ends in a comment > line. > > The bug happens when the last character of a comment line is the > 4096th > byte and the trailing newline is the first byte in the next chunk. In > that case, nextToken() in src/java.base/share/native/libjli/args.c > calls JLI_List_addSubstring (in the if-block at the end of > nextToken()) > with the contents of the current comment line. The next "valid" > option > gets appended to that comment line and java errors out. > > I've added some debugging output to the last if-block and pctx-> > state==FIND_NEXT and the the substring being added is the comment > line. > > I've also tried and changed this line > http://hg.openjdk.java.net/jdk-updates/jdk11u/annotate/20e49753c388/src/java.base/share/native/libjli/args.c#l294 > to 'if (anchor != nextc && pctx->state == IN_TOKEN)' and the argfile > is > parsed correctly. > > Steps to reproduce: > 1. save the attached my-argfile > 2. run 'java @my-argfile my.className' > 3. java errors out with > Error: Could not find or > load main class # > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > -Dfoo=bar > Caused by: java.lang.ClassNotFoundException: # > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > -Dfoo=bar > > With the above change (the attached patch in argfile-parse-bug.txt), > argfile parsing works as expected.Also updated the condition in the > loop looking for a comment's newline, as it looks inconsistent to the > condition in the loop for FIND_NEXT/SKIP_LEAD_WS and the condition of > the outer for-loop. > > Robert > > > On Thu, 2020-03-05 at 20:00 +0100, Robert Stupp wrote: > > Hi, > ... From calvin.cheung at oracle.com Thu Mar 5 19:48:49 2020 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 5 Mar 2020 11:48:49 -0800 Subject: RFR(S): 8232081: Try to link all classes during dynamic CDS dump In-Reply-To: <5fa95d9f-47a7-c1c7-90e5-87db0173e3b7@oracle.com> References: <9b40145a-db72-6313-3b98-5e5aea754e25@oracle.com> <1167ff6d-3997-6390-d020-d0946fad0af8@oracle.com> <3f373a33-c7ed-0237-1dd5-f8ac8e8794ee@oracle.com> <8ac4612b-fae3-bb16-f2ab-fa323c33ca51@oracle.com> <00090c43-1e0d-2b1c-d2a5-1b5f1b29199d@oracle.com> <7a54e00f-c049-a5ef-0afc-bb6c9d0f30ad@oracle.com> <5fa95d9f-47a7-c1c7-90e5-87db0173e3b7@oracle.com> Message-ID: <35a07978-29f7-8e16-c50a-0c97ee575871@oracle.com> On 3/5/20 9:17 AM, Ioi Lam wrote: > Hi Calvin, > > Looks good overall. I just have two comment: > > I think this is not needed: > > ?306 void ConstantPool::resolve_class_constants(TRAPS) { > ?307?? Arguments::assert_is_dumping_archive(); I've reverted this change. > > because this function is used to resolve all Strings in the statically > dumped classes to archive all the Strings. However, the archive heap > is not supported for the dynamic archive. So I think it's better to > avoid calling this function from LinkSharedClassesClosure for dynamic > dump. Now, the function will not be called with dynamic dump: 1714???????? if (DumpSharedSpaces) { 1715?????????? // The following function is used to resolve all Strings in the statically 1716?????????? // dumped classes to archive all the Strings. The archive heap is not supported 1717?????????? // for the dynamic archive. 1718 ik->constants()->resolve_class_constants(THREAD); 1719???????? } > > LinkSharedClassesClosure::_is_static -- maybe we can avoid adding this > field and just check "if (DumpSharedSpaces)" instead? This is a good simplification. btw, you've removed loader_type() from instanceKlass.hpp when you pushed the change for JDK-8240244. I've added it back as shared_loader_type(). updated webrev: ??? http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.04/ thanks, Calvin > > Thanks > - Ioi > > > > > > On 3/4/20 9:13 PM, Calvin Cheung wrote: >> Hi David, Ioi, >> >> Here's an updated webrev which doesn't involve changing >> InstanceKlass::verify_on() and made use of the changes for JDK-8240481. >> >> ??? http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.03/ >> >> thanks, >> Calvin >> >> On 3/1/20 10:14 PM, David Holmes wrote: >>> Hi Calvin, >>> >>> On 28/02/2020 4:12 pm, Calvin Cheung wrote: >>>> Hi David, >>>> >>>> On 2/27/20 5:40 PM, David Holmes wrote: >>>>> Hi Calvin, Ioi, >>>>> >>>>> Looking good - comments below. >>>>> >>>>> A meta-question: normal application classes are rarely loaded but >>>>> not linked so I'm a little surprised this is an issue. What is the >>>>> main source of such classes - generated classes like lambda forms? >>>>> Also why do we need to link them when loading from the archive if >>>>> they were never linked when the application actually executed ?? >>>> >>>> I saw that Ioi already answered the above. >>>> >>>> I'll try to answer your questions inline below.. >>> >>> Responses inline below ... >>> >>>>> >>>>> On 28/02/2020 10:48 am, Calvin Cheung wrote: >>>>>> Hi David, Ioi, >>>>>> >>>>>> Thanks for your review and suggestions. >>>>>> >>>>>> On 2/26/20 9:46 PM, Ioi Lam wrote: >>>>>>> >>>>>>> >>>>>>> On 2/26/20 7:50 PM, David Holmes wrote: >>>>>>>> Hi Calvin, >>>>>>>> >>>>>>>> Adding core-libs-dev as you are messing with their code :) >>>>>>>> >>>>>>>> On 27/02/2020 1:19 pm, Calvin Cheung wrote: >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8232081 >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/ >>>>>>>>> >>>>>>>>> The proposed changeset for this RFE adds a >>>>>>>>> JVM_LinkClassesForCDS() function to be called from >>>>>>>>> java/lang/Shutdown to notify the JVM to link the classes >>>>>>>>> loaded by the builtin class loaders. The >>>>>>>> >>>>>>>> This would be much less disruptive if this was handled purely >>>>>>>> on the VM side once we have started shutdown. No need to make >>>>>>>> any changes to the Java side then, nor jvm.cpp. >>>>>>>> >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> To link the classes, we need to be able to run Java code -- when >>>>>>> linking a class X loaded by the app loader, X will be verified. >>>>>>> During verification of X, we may need to load additional classes >>>>>>> from the app loader, which executes Java code during its class >>>>>>> loading operations. >>>>>>> >>>>>>> We also need to handle all the exit conditions. As far as I can >>>>>>> tell, an app can exit the JVM in two ways: >>>>>>> >>>>>>> (1) Explicitly calling System.exit(). This will call >>>>>>> java.lang.Shutdown.exit() which does this: >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l163 >>>>>>> >>>>>>> >>>>>>> ??????????? beforeHalt(); // native >>>>>>> ??????????? runHooks(); >>>>>>> ??????????? halt(status); >>>>>>> >>>>>>> (2) When all non-daemon threads have died (e.g., falling out of >>>>>>> the bottom of HelloWorld.main()). There's no explicit call to >>>>>>> System.exit(), but the JVM will proactively call >>>>>>> java.lang.Shutdown.shutdown() inside >>>>>>> JavaThread::invoke_shutdown_hooks() >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/hotspot/share/runtime/thread.cpp#l4331 >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l184 >>>>>>> >>>>>>> >>>>>>> If we want to avoid modifying the Java code, I think we can >>>>>>> intercept JVM_BeforeHalt() and >>>>>>> JavaThread::invoke_shutdown_hooks(). This way we should be able >>>>>>> to handle all the classes (except those that are loaded inside >>>>>>> Shutdown.runHooks). >>>>>> >>>>>> I've implemented the above. No changes to the Java side. >>>>>> >>>>>> updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.01/ >>>>> >>>>> This looks much better to me. I wasn't sure if you were that >>>>> concerned about catching the classes loaded by the Shutdown hooks, >>>>> but it is good you are not as it seems problematic to me to >>>>> trigger class loading etc after the shutdown hooks have executed - >>>>> you may hit unexpected conditions. So this approach is good. >>>>> >>>>> A few minor comments: >>>>> >>>>> src/hotspot/share/memory/metaspaceShared.cpp >>>>> src/hotspot/share/memory/metaspaceShared.hpp >>>>> >>>>> Why the change from TRAPS to "Thread* THREAD"? >>>> I forgot why I changed it but I've changed it back and it still works. >>> >>> Ok. >>> >>>>> >>>>> --- >>>>> >>>>> src/hotspot/share/oops/instanceKlass.cpp >>>>> >>>>> I'm not clear how verify_on is used so am unsure how the >>>>> additional error state check may affect code unrelated to dynamic >>>>> dumping ?? >>>> >>>> Some of the appcds tests by design have some classes which fail >>>> verification. Without the change, the following assert would fail: >>>> >>>> void vtableEntry::verify(klassVtable* vt, outputStream* st) { >>>> ?? Klass* vtklass = vt->klass(); >>>> ?? if (vtklass->is_instance_klass() && >>>> ????? (InstanceKlass::cast(vtklass)->major_version() >= >>>> klassVtable::VTABLE_TRANSITIVE_OVERRIDE_VERSION)) { >>>> *assert*(method() != NULL, "must have set method"); >>>> ?? } >>> >>> Okay so you need to exclude for that case but ... >>> >>>> Here's the call stack during dynamic CDS dump to the above function: >>>> >>>> vtableEntry::verify(klassVtable *, outputStream *) : void >>>> ???? klassVtable::verify(outputStream *, bool) : void >>>> ???????? InstanceKlass::verify_on(outputStream *) : void >>>> ???????????? Klass::verify() : void >>>> ???????????????? ClassLoaderData::verify() : void >>>> ???????????????????? ClassLoaderDataGraph::verify() : void >>>> ???????????????????????? Universe::verify(enum VerifyOption, const >>>> char *) : void >>>> ???????????????????????????? Universe::verify(const char *) : void >>>> DynamicArchiveBuilder::verify_universe(const char *) : void >>>> DynamicArchiveBuilder::doit() : void (2 matches) >>>> VM_PopulateDynamicDumpSharedSpace::doit() : void >>>> VM_Operation::evaluate() : void >>>> >>>> The is_linked() function is implemented as: >>>> >>>> ???? bool is_linked() const?????????????????? { return _init_state >>>> >= linked; } >>>> >>>> which includes 'initialization_error'. >>> >>> ... AFAICS Universe::verify is call from a number of places, all of >>> which would reach this modified code. As that existing code has >>> included classes that are in the error state then it seems to me >>> that unless you can prove otherwise you need to keep the existing >>> code as-is for the non-CDS dump case. >>> >>>> A previous version of the changeset (including the change in >>>> question in instanceKlass.cpp) passed tier1 - 4 testing. Let me >>>> know if I should run other tests to make sure the change is good. >>> >>> There may well not be a test that covers this. >>> >>> Thanks, >>> David >>> >>>>> >>>>> Also can I suggest (as you are touching this code) to delete the >>>>> ancient comment: >>>>> >>>>> 3580???? // $$$ This used to be done only for m/s collections. >>>>> Doing it >>>>> 3581???? // always seemed a valid generalization.? (DLD -- 6/00) >>>> >>>> I'm glad that you suggested to remove the above comment. I've no >>>> clue what it means either. >>>> >>>> updated webrev: >>>> >>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.02/ >>>> >>>> thanks, >>>> Calvin >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> I also updated the test to test the shutdown hook and >>>>>> System.exit() scenarios. >>>>>> >>>>>> All appcds tests passed on my linux host. I'll run more tests >>>>>> using mach5. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Calvin >>>>>> >>>>>> >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> - Ioi >>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> MetaspaceShared::link_and_cleanup_shared_classes() has been >>>>>>>>> modified to handle both static and dynamic CDS dump. For >>>>>>>>> dynamic CDS dump, only classes loaded by the builtin class >>>>>>>>> loaders will be linked. Local performance testing using javac >>>>>>>>> on HelloWorld.java shows an improvement of >5%. >>>>>>>>> >>>>>>>>> Passed tier1 - 4 tests. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> Calvin >>>>>>>>> >>>>>>> > From Roger.Riggs at oracle.com Thu Mar 5 20:51:45 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 5 Mar 2020 15:51:45 -0500 Subject: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder Message-ID: Please review a change to the Windows ProcessImpl to ensure that the handles created for the input and output streams of a process are closed when no longer referenced. Unlike on Linux, there is no thread monitoring the process that can close the streams. The FileDescriptors are registered with the Cleaner to be closed when they are no longer referenced. A test is added that monitors the count of handles as 50 Processes are launched and exit. The test and change only affect the Windows implementation. Webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893/ Issue: ? https://bugs.openjdk.java.net/browse/JDK-8239893 Thanks, Roger From brian.burkhalter at oracle.com Thu Mar 5 21:07:36 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 5 Mar 2020 13:07:36 -0800 Subject: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder In-Reply-To: References: Message-ID: Hi Roger, > On Mar 5, 2020, at 12:51 PM, Roger Riggs wrote: > > Please review a change to the Windows ProcessImpl to ensure that the handles > created for the input and output streams of a process are closed when no longer referenced. > > Unlike on Linux, there is no thread monitoring the process that can close the streams. > The FileDescriptors are registered with the Cleaner to be closed when they are no longer referenced. > > A test is added that monitors the count of handles as 50 Processes are launched and exit. > The test and change only affect the Windows implementation. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8239893 In CheckHandles.java at line 72 there is this calculation: final long ERROR_THRESHOLD = minHandles + (minHandles / ERROR_PERCENT); // 10% increase over min to passing max Do you think it would be better as final long ERROR_THRESHOLD = minHandles + ((minHandles + ERROR_PERCENT - 1) / ERROR_PERCENT); // 10% increase over min to passing max , i.e., rounded instead of truncated? Brian From naoto.sato at oracle.com Thu Mar 5 21:14:04 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 5 Mar 2020 13:14:04 -0800 Subject: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder In-Reply-To: References: Message-ID: <45139c69-55c6-68fe-74bd-6432d2c935a4@oracle.com> Hi Roger, In the test, the error value (-1) from the native code seems silently suppressed. Should it be caught/reported in the java side? nit: copyright year in ProcessImpl.java -> 2020. Naoto On 3/5/20 12:51 PM, Roger Riggs wrote: > Please review a change to the Windows ProcessImpl to ensure that the > handles > created for the input and output streams of a process are closed when no > longer referenced. > > Unlike on Linux, there is no thread monitoring the process that can > close the streams. > The FileDescriptors are registered with the Cleaner to be closed when > they are no longer referenced. > > A test is added that monitors the count of handles as 50 Processes are > launched and exit. > The test and change only affect the Windows implementation. > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893/ > > Issue: > ? https://bugs.openjdk.java.net/browse/JDK-8239893 > > Thanks, Roger > From joe.darcy at oracle.com Thu Mar 5 21:45:49 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 5 Mar 2020 13:45:49 -0800 Subject: JDK 15 RFR of JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy Message-ID: Hello, Where such a mapping exists, it would be helpful to tie the policies represented by various RoundingMode constants to the equivalent rounding attribute defined by IEEE 754-2019, the latest version of the floating-point standard: ??? JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy ??? http://cr.openjdk.java.net/~darcy/8240624.0/ Please review the patch below; I'll update the file copyright year before pushing. Thanks, -Joe --- old/src/java.base/share/classes/java/math/RoundingMode.java 2020-03-05 13:44:23.971037000 -0800 +++ new/src/java.base/share/classes/java/math/RoundingMode.java 2020-03-05 13:44:23.647037000 -0800 @@ -87,6 +87,12 @@ * ({@link BigDecimal#ROUND_UP}, {@link BigDecimal#ROUND_DOWN}, * etc. ). * + * @apiNote + * Five of the rounding modes defined in this class correspond to + * rounding direction attributes defined in IEEE 754-2019. Where + * present, this correspondence will be noted in the documentation of + * the particular constant. + * * @see BigDecimal * @see MathContext * @author Josh Bloch @@ -130,7 +136,9 @@ * Rounding mode to round towards zero. Never increments the digit * prior to a discarded fraction (i.e., truncates). Note that this * rounding mode never increases the magnitude of the calculated value. - * + * This mode corresponds to the IEEE 754-2019 rounding + * attribute roundTowardZero. + * *

Example: * * @@ -159,6 +167,8 @@ * result is positive, behaves as for {@code RoundingMode.UP}; * if negative, behaves as for {@code RoundingMode.DOWN}. Note * that this rounding mode never decreases the calculated value. + * This mode corresponds to the IEEE 754-2019 rounding + * attribute roundTowardPositive. * *

Example: *

Rounding mode DOWN Examples
@@ -188,6 +198,8 @@ * result is positive, behave as for {@code RoundingMode.DOWN}; * if negative, behave as for {@code RoundingMode.UP}. Note that * this rounding mode never increases the calculated value. + * This mode corresponds to the IEEE 754-2019 rounding + * attribute roundTowardNegative. * *

Example: *

@@ -219,6 +231,8 @@ * fraction is ≥ 0.5; otherwise, behaves as for * {@code RoundingMode.DOWN}. Note that this is the rounding * mode commonly taught at school. + * This mode corresponds to the IEEE 754-2019 rounding + * attribute roundTiesToAway. * *

Example: *

@@ -286,6 +300,8 @@ * chiefly used in the USA. This rounding mode is analogous to * the rounding policy used for {@code float} and {@code double} * arithmetic in Java. + * This mode corresponds to the IEEE 754-2019 rounding + * attribute roundTiesToEven. * *

Example: *

From brian.burkhalter at oracle.com Thu Mar 5 21:51:39 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 5 Mar 2020 13:51:39 -0800 Subject: JDK 15 RFR of JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy In-Reply-To: References: Message-ID: Hi Joe, > On Mar 5, 2020, at 1:45 PM, Joe Darcy wrote: > > Where such a mapping exists, it would be helpful to tie the policies represented by various RoundingMode constants to the equivalent rounding attribute defined by IEEE 754-2019, the latest version of the floating-point standard: > > JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy > http://cr.openjdk.java.net/~darcy/8240624.0/ Looks fine. Do you think the IEEE 754-2019 attribute names should have some kind of formatting, e.g., @code or italics? > Please review the patch below; I'll update the file copyright year before pushing. > +1 Brian From brian.burkhalter at oracle.com Thu Mar 5 21:53:31 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 5 Mar 2020 13:53:31 -0800 Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF In-Reply-To: References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com> <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com> <14E6EF7F-C01F-4407-B865-32089266DC28@oracle.com> Message-ID: Might anyone else have any comments on this thread the original post in which was [1]. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064417.html > On Jan 31, 2020, at 12:21 PM, Brian Burkhalter wrote: > >> On Jan 31, 2020, at 12:20 PM, Alan Bateman > wrote: >> >> On 31/01/2020 20:10, Brian Burkhalter wrote: >>> : >>> OK. I?ll change /TERM/EOL/ but not post another webrev unless there are further comments. I will wait to check it in until Monday in case someone has comments. >>> >> I think it would be good to more eyes on this as LNR has a history of resisting change. > > I?ll hold off on it then for a while. > >> I think you'll need a CSR too this re-specifies when the conditions when the line number is incremented. > > Yes, I agree. From joe.darcy at oracle.com Thu Mar 5 22:43:24 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 5 Mar 2020 14:43:24 -0800 Subject: JDK 15 RFR of JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy In-Reply-To: References: Message-ID: Hi Brian, On 3/5/2020 1:51 PM, Brian Burkhalter wrote: > Hi Joe, > >> On Mar 5, 2020, at 1:45 PM, Joe Darcy > > wrote: >> >> Where such a mapping exists, it would be helpful to tie the policies >> represented by various RoundingMode constants to the equivalent >> rounding attribute defined by IEEE 754-2019, the latest version of >> the floating-point standard: >> >> ??? JDK-8240624: Note mapping of RoundingMode constants to equivalent >> IEEE 754-2019 policy >> http://cr.openjdk.java.net/~darcy/8240624.0/ >> > Looks fine. Do you think the IEEE 754-2019 attribute names should have > some kind of formatting, e.g., @code or italics? The IEEE standard uses normal next for those terms, no italics, bold, etc. ; in this context, I think preserving that convention is fine. I'll push with a slightly reworked opening API note: + * @apiNote + * Five of the rounding modes declared in this class correspond to + * rounding direction attributes defined in the IEEE Standard + * for Floating-Point Arithmetic, IEEE 754-2019. Where present, + * this correspondence will be noted in the documentation of the + * particular constant. + * Thanks, -Joe From brian.burkhalter at oracle.com Thu Mar 5 22:46:36 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 5 Mar 2020 14:46:36 -0800 Subject: JDK 15 RFR of JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy In-Reply-To: References: Message-ID: <27BA00C2-3EDD-4254-87A9-0309A15D3696@oracle.com> Hi Joe, > On Mar 5, 2020, at 2:43 PM, Joe Darcy wrote: > >> Looks fine. Do you think the IEEE 754-2019 attribute names should have some kind of formatting, e.g., @code or italics? > The IEEE standard uses normal next for those terms, no italics, bold, etc. ; in this context, I think preserving that convention is fine. > That make sense. > I'll push with a slightly reworked opening API note: > > + * @apiNote > + * Five of the rounding modes declared in this class correspond to > + * rounding direction attributes defined in the IEEE Standard > + * for Floating-Point Arithmetic, IEEE 754-2019. Where present, > + * this correspondence will be noted in the documentation of the > + * particular constant. > + * > Looks good. Brian From henry.jen at oracle.com Thu Mar 5 22:57:13 2020 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 5 Mar 2020 14:57:13 -0800 Subject: argfiles parsing broken for argfiles > 4096 bytes In-Reply-To: <6014206a3374bf18059488bbf4cfae4bd0e687c7.camel@gmx.de> References: <1768c55f6ba0722d96f2bb978c3ce3f820779cfa.camel@gmx.de> <6704dc02d2a4b8e140eb4d55cbae8204d6250fb2.camel@gmx.de> <6014206a3374bf18059488bbf4cfae4bd0e687c7.camel@gmx.de> Message-ID: <6DD2702D-76A9-477C-B0FA-990B498A3AE5@oracle.com> Thanks for the report and investigation, bug confirmed, JDK-8240629 is filed to tacking the issue. https://bugs.openjdk.java.net/browse/JDK-8240629 Cheers, Henry > On Mar 5, 2020, at 11:43 AM, Robert Stupp wrote: > > Another note: I've also seen it appending a comment-line in > http://hg.openjdk.java.net/jdk-updates/jdk11u/annotate/20e49753c388/src/java.base/share/native/libjli/args.c#l296 > with pctx->state==IN_COMMENT, but wasn't able to reconstruct the > behavior with a "clean" argfile. But that behavior was also fixed with > the condition ('&& pctx->state == IN_TOKEN') added by the patch. > > On Thu, 2020-03-05 at 20:34 +0100, Robert Stupp wrote: >> Sorry for the broken formatting... >> >> I recently came across a bug in the java executable with an argfile >> that's larger than 4096 bytes, if a 4096-byte-chunk ends in a comment >> line. >> >> The bug happens when the last character of a comment line is the >> 4096th >> byte and the trailing newline is the first byte in the next chunk. In >> that case, nextToken() in src/java.base/share/native/libjli/args.c >> calls JLI_List_addSubstring (in the if-block at the end of >> nextToken()) >> with the contents of the current comment line. The next "valid" >> option >> gets appended to that comment line and java errors out. >> >> I've added some debugging output to the last if-block and pctx-> >> state==FIND_NEXT and the the substring being added is the comment >> line. >> >> I've also tried and changed this line >> http://hg.openjdk.java.net/jdk-updates/jdk11u/annotate/20e49753c388/src/java.base/share/native/libjli/args.c#l294 >> to 'if (anchor != nextc && pctx->state == IN_TOKEN)' and the argfile >> is >> parsed correctly. >> >> Steps to reproduce: >> 1. save the attached my-argfile >> 2. run 'java @my-argfile my.className' >> 3. java errors out with >> Error: Could not find or >> load main class # >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> XX >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> -Dfoo=bar >> Caused by: java.lang.ClassNotFoundException: # >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> XX >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> -Dfoo=bar >> >> With the above change (the attached patch in argfile-parse-bug.txt), >> argfile parsing works as expected.Also updated the condition in the >> loop looking for a comment's newline, as it looks inconsistent to the >> condition in the loop for FIND_NEXT/SKIP_LEAD_WS and the condition of >> the outer for-loop. >> >> Robert >> >> >> On Thu, 2020-03-05 at 20:00 +0100, Robert Stupp wrote: >>> Hi, >> ... > From ioi.lam at oracle.com Fri Mar 6 05:16:33 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 5 Mar 2020 21:16:33 -0800 Subject: RFR(S): 8232081: Try to link all classes during dynamic CDS dump In-Reply-To: <35a07978-29f7-8e16-c50a-0c97ee575871@oracle.com> References: <9b40145a-db72-6313-3b98-5e5aea754e25@oracle.com> <1167ff6d-3997-6390-d020-d0946fad0af8@oracle.com> <3f373a33-c7ed-0237-1dd5-f8ac8e8794ee@oracle.com> <8ac4612b-fae3-bb16-f2ab-fa323c33ca51@oracle.com> <00090c43-1e0d-2b1c-d2a5-1b5f1b29199d@oracle.com> <7a54e00f-c049-a5ef-0afc-bb6c9d0f30ad@oracle.com> <5fa95d9f-47a7-c1c7-90e5-87db0173e3b7@oracle.com> <35a07978-29f7-8e16-c50a-0c97ee575871@oracle.com> Message-ID: <209d74da-fdb9-1ca1-4410-75c530cfd575@oracle.com> Hi Calvin, Looks good. In JDK-8240244, I removed "ik->loader_type() != 0" because it's unclear what it means. I replaced with a new method InstanceKlass::is_shared_unregistered_class(). I think you can use this in your patch instead of adding loader_type() back. No need for new webrev. Thanks - Ioi On 3/5/20 11:48 AM, Calvin Cheung wrote: > > On 3/5/20 9:17 AM, Ioi Lam wrote: >> Hi Calvin, >> >> Looks good overall. I just have two comment: >> >> I think this is not needed: >> >> ?306 void ConstantPool::resolve_class_constants(TRAPS) { >> ?307?? Arguments::assert_is_dumping_archive(); > I've reverted this change. >> >> because this function is used to resolve all Strings in the >> statically dumped classes to archive all the Strings. However, the >> archive heap is not supported for the dynamic archive. So I think >> it's better to avoid calling this function from >> LinkSharedClassesClosure for dynamic dump. > Now, the function will not be called with dynamic dump: > 1714???????? if (DumpSharedSpaces) { > 1715?????????? // The following function is used to resolve all > Strings in the statically > 1716?????????? // dumped classes to archive all the Strings. The > archive heap is not supported > 1717?????????? // for the dynamic archive. > 1718 ik->constants()->resolve_class_constants(THREAD); > 1719???????? } >> >> LinkSharedClassesClosure::_is_static -- maybe we can avoid adding >> this field and just check "if (DumpSharedSpaces)" instead? > > This is a good simplification. > > btw, you've removed loader_type() from instanceKlass.hpp when you > pushed the change for JDK-8240244. I've added it back as > shared_loader_type(). > > updated webrev: > > ??? http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.04/ > > thanks, > > Calvin > >> >> Thanks >> - Ioi >> >> >> >> >> >> On 3/4/20 9:13 PM, Calvin Cheung wrote: >>> Hi David, Ioi, >>> >>> Here's an updated webrev which doesn't involve changing >>> InstanceKlass::verify_on() and made use of the changes for JDK-8240481. >>> >>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.03/ >>> >>> thanks, >>> Calvin >>> >>> On 3/1/20 10:14 PM, David Holmes wrote: >>>> Hi Calvin, >>>> >>>> On 28/02/2020 4:12 pm, Calvin Cheung wrote: >>>>> Hi David, >>>>> >>>>> On 2/27/20 5:40 PM, David Holmes wrote: >>>>>> Hi Calvin, Ioi, >>>>>> >>>>>> Looking good - comments below. >>>>>> >>>>>> A meta-question: normal application classes are rarely loaded but >>>>>> not linked so I'm a little surprised this is an issue. What is >>>>>> the main source of such classes - generated classes like lambda >>>>>> forms? Also why do we need to link them when loading from the >>>>>> archive if they were never linked when the application actually >>>>>> executed ?? >>>>> >>>>> I saw that Ioi already answered the above. >>>>> >>>>> I'll try to answer your questions inline below.. >>>> >>>> Responses inline below ... >>>> >>>>>> >>>>>> On 28/02/2020 10:48 am, Calvin Cheung wrote: >>>>>>> Hi David, Ioi, >>>>>>> >>>>>>> Thanks for your review and suggestions. >>>>>>> >>>>>>> On 2/26/20 9:46 PM, Ioi Lam wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2/26/20 7:50 PM, David Holmes wrote: >>>>>>>>> Hi Calvin, >>>>>>>>> >>>>>>>>> Adding core-libs-dev as you are messing with their code :) >>>>>>>>> >>>>>>>>> On 27/02/2020 1:19 pm, Calvin Cheung wrote: >>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8232081 >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/ >>>>>>>>>> >>>>>>>>>> The proposed changeset for this RFE adds a >>>>>>>>>> JVM_LinkClassesForCDS() function to be called from >>>>>>>>>> java/lang/Shutdown to notify the JVM to link the classes >>>>>>>>>> loaded by the builtin class loaders. The >>>>>>>>> >>>>>>>>> This would be much less disruptive if this was handled purely >>>>>>>>> on the VM side once we have started shutdown. No need to make >>>>>>>>> any changes to the Java side then, nor jvm.cpp. >>>>>>>>> >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> To link the classes, we need to be able to run Java code -- >>>>>>>> when linking a class X loaded by the app loader, X will be >>>>>>>> verified. During verification of X, we may need to load >>>>>>>> additional classes from the app loader, which executes Java >>>>>>>> code during its class loading operations. >>>>>>>> >>>>>>>> We also need to handle all the exit conditions. As far as I can >>>>>>>> tell, an app can exit the JVM in two ways: >>>>>>>> >>>>>>>> (1) Explicitly calling System.exit(). This will call >>>>>>>> java.lang.Shutdown.exit() which does this: >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l163 >>>>>>>> >>>>>>>> >>>>>>>> ??????????? beforeHalt(); // native >>>>>>>> ??????????? runHooks(); >>>>>>>> ??????????? halt(status); >>>>>>>> >>>>>>>> (2) When all non-daemon threads have died (e.g., falling out of >>>>>>>> the bottom of HelloWorld.main()). There's no explicit call to >>>>>>>> System.exit(), but the JVM will proactively call >>>>>>>> java.lang.Shutdown.shutdown() inside >>>>>>>> JavaThread::invoke_shutdown_hooks() >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/hotspot/share/runtime/thread.cpp#l4331 >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l184 >>>>>>>> >>>>>>>> >>>>>>>> If we want to avoid modifying the Java code, I think we can >>>>>>>> intercept JVM_BeforeHalt() and >>>>>>>> JavaThread::invoke_shutdown_hooks(). This way we should be able >>>>>>>> to handle all the classes (except those that are loaded inside >>>>>>>> Shutdown.runHooks). >>>>>>> >>>>>>> I've implemented the above. No changes to the Java side. >>>>>>> >>>>>>> updated webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.01/ >>>>>> >>>>>> This looks much better to me. I wasn't sure if you were that >>>>>> concerned about catching the classes loaded by the Shutdown >>>>>> hooks, but it is good you are not as it seems problematic to me >>>>>> to trigger class loading etc after the shutdown hooks have >>>>>> executed - you may hit unexpected conditions. So this approach is >>>>>> good. >>>>>> >>>>>> A few minor comments: >>>>>> >>>>>> src/hotspot/share/memory/metaspaceShared.cpp >>>>>> src/hotspot/share/memory/metaspaceShared.hpp >>>>>> >>>>>> Why the change from TRAPS to "Thread* THREAD"? >>>>> I forgot why I changed it but I've changed it back and it still >>>>> works. >>>> >>>> Ok. >>>> >>>>>> >>>>>> --- >>>>>> >>>>>> src/hotspot/share/oops/instanceKlass.cpp >>>>>> >>>>>> I'm not clear how verify_on is used so am unsure how the >>>>>> additional error state check may affect code unrelated to dynamic >>>>>> dumping ?? >>>>> >>>>> Some of the appcds tests by design have some classes which fail >>>>> verification. Without the change, the following assert would fail: >>>>> >>>>> void vtableEntry::verify(klassVtable* vt, outputStream* st) { >>>>> ?? Klass* vtklass = vt->klass(); >>>>> ?? if (vtklass->is_instance_klass() && >>>>> ????? (InstanceKlass::cast(vtklass)->major_version() >= >>>>> klassVtable::VTABLE_TRANSITIVE_OVERRIDE_VERSION)) { >>>>> *assert*(method() != NULL, "must have set method"); >>>>> ?? } >>>> >>>> Okay so you need to exclude for that case but ... >>>> >>>>> Here's the call stack during dynamic CDS dump to the above function: >>>>> >>>>> vtableEntry::verify(klassVtable *, outputStream *) : void >>>>> ???? klassVtable::verify(outputStream *, bool) : void >>>>> ???????? InstanceKlass::verify_on(outputStream *) : void >>>>> ???????????? Klass::verify() : void >>>>> ???????????????? ClassLoaderData::verify() : void >>>>> ???????????????????? ClassLoaderDataGraph::verify() : void >>>>> ???????????????????????? Universe::verify(enum VerifyOption, const >>>>> char *) : void >>>>> ???????????????????????????? Universe::verify(const char *) : void >>>>> DynamicArchiveBuilder::verify_universe(const char *) : void >>>>> DynamicArchiveBuilder::doit() : void (2 matches) >>>>> VM_PopulateDynamicDumpSharedSpace::doit() : void >>>>> VM_Operation::evaluate() : void >>>>> >>>>> The is_linked() function is implemented as: >>>>> >>>>> ???? bool is_linked() const?????????????????? { return _init_state >>>>> >= linked; } >>>>> >>>>> which includes 'initialization_error'. >>>> >>>> ... AFAICS Universe::verify is call from a number of places, all of >>>> which would reach this modified code. As that existing code has >>>> included classes that are in the error state then it seems to me >>>> that unless you can prove otherwise you need to keep the existing >>>> code as-is for the non-CDS dump case. >>>> >>>>> A previous version of the changeset (including the change in >>>>> question in instanceKlass.cpp) passed tier1 - 4 testing. Let me >>>>> know if I should run other tests to make sure the change is good. >>>> >>>> There may well not be a test that covers this. >>>> >>>> Thanks, >>>> David >>>> >>>>>> >>>>>> Also can I suggest (as you are touching this code) to delete the >>>>>> ancient comment: >>>>>> >>>>>> 3580???? // $$$ This used to be done only for m/s collections. >>>>>> Doing it >>>>>> 3581???? // always seemed a valid generalization.? (DLD -- 6/00) >>>>> >>>>> I'm glad that you suggested to remove the above comment. I've no >>>>> clue what it means either. >>>>> >>>>> updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.02/ >>>>> >>>>> thanks, >>>>> Calvin >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> I also updated the test to test the shutdown hook and >>>>>>> System.exit() scenarios. >>>>>>> >>>>>>> All appcds tests passed on my linux host. I'll run more tests >>>>>>> using mach5. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Calvin >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> - Ioi >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> MetaspaceShared::link_and_cleanup_shared_classes() has been >>>>>>>>>> modified to handle both static and dynamic CDS dump. For >>>>>>>>>> dynamic CDS dump, only classes loaded by the builtin class >>>>>>>>>> loaders will be linked. Local performance testing using javac >>>>>>>>>> on HelloWorld.java shows an improvement of >5%. >>>>>>>>>> >>>>>>>>>> Passed tier1 - 4 tests. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> Calvin >>>>>>>>>> >>>>>>>> >> From christoph.langer at sap.com Fri Mar 6 06:36:20 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Mar 2020 06:36:20 +0000 Subject: RFR 8240524: Removed warnings from test classes In-Reply-To: References: Message-ID: Hi Vipin, this all looks correct to me. When changing the copyright headers, you have to keep the first (initial) year and only update the second year. If this doesn?t exist, you?ll have to add it, e.g. Copyright (c) 1999, Oracle -> Copyright (c) 1999, 2020, Oracle I can fix that for you though, when sponsoring, no need for new webrev. Can I have a second review, please? Thanks Christoph From: Vipin Sharma Sent: Donnerstag, 5. M?rz 2020 18:27 To: Langer, Christoph ; core-libs-dev at openjdk.java.net Subject: RFR 8240524: Removed warnings from test classes Hi All, Please review patch to remove warnings from test classes. Bug : https://bugs.openjdk.java.net/browse/JDK-8240524 Webrev : http://cr.openjdk.java.net/~clanger/webrevs/8240524.0/ Change description: Class: test/jdk/java/lang/Boolean/GetBoolean.java Fixed following warning: 1. "Exception 'java.lang.Exception' is never thrown in the method? Class: test/jdk/java/lang/Boolean/MakeBooleanComparable.java Fixed following warnings: 1. Explicit type argument Boolean can be replaced with <> 2. C-style array declaration of parameter 'args' Class: test/jdk/java/lang/Boolean/ParseBoolean.java Fixed following warning: 1. Exception 'java.lang.Exception' is never thrown in the method Regards, Vipin From vyommani at gmail.com Fri Mar 6 08:24:21 2020 From: vyommani at gmail.com (Vyom Tiwari) Date: Fri, 6 Mar 2020 13:54:21 +0530 Subject: RFR 8240524: Removed warnings from test classes In-Reply-To: References: Message-ID: Hi Vipin, Test code changes looks good to me as well except copyright changes, which will be fix at the time of pushing the code by Christoph. Thanks, Vyom On Fri, Mar 6, 2020 at 12:06 PM Langer, Christoph wrote: > Hi Vipin, > > this all looks correct to me. > > When changing the copyright headers, you have to keep the first (initial) > year and only update the second year. If this doesn?t exist, you?ll have to > add it, e.g. > Copyright (c) 1999, Oracle -> Copyright (c) 1999, 2020, Oracle > > I can fix that for you though, when sponsoring, no need for new webrev. > > Can I have a second review, please? > > Thanks > Christoph > > > > From: Vipin Sharma > Sent: Donnerstag, 5. M?rz 2020 18:27 > To: Langer, Christoph ; > core-libs-dev at openjdk.java.net > Subject: RFR 8240524: Removed warnings from test classes > > Hi All, > > Please review patch to remove warnings from test classes. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8240524 > Webrev : http://cr.openjdk.java.net/~clanger/webrevs/8240524.0/ > > > Change description: > > Class: test/jdk/java/lang/Boolean/GetBoolean.java > Fixed following warning: > 1. "Exception 'java.lang.Exception' is never thrown in the method? > > Class: test/jdk/java/lang/Boolean/MakeBooleanComparable.java > Fixed following warnings: > 1. Explicit type argument Boolean can be replaced with <> > 2. C-style array declaration of parameter 'args' > > Class: test/jdk/java/lang/Boolean/ParseBoolean.java > Fixed following warning: > 1. Exception 'java.lang.Exception' is never thrown in the method > > > Regards, > Vipin > -- Thanks, Vyom From sgehwolf at redhat.com Fri Mar 6 14:07:04 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 06 Mar 2020 15:07:04 +0100 Subject: [8u] PING: RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. In-Reply-To: References: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com> <3adc99dd5410882edcf129859ddfb7b0648c941d.camel@redhat.com> <71d543639ca7396711a8c04e78aa10ce5823c43f.camel@redhat.com> Message-ID: <3d08d884893db8c271890d9e97607df3eb896a8b.camel@redhat.com> Hi Andrew, On Tue, 2020-02-18 at 10:58 +0000, Andrew Hughes wrote: > On 11/10/2019 15:54, Severin Gehwolf wrote: > > On Fri, 2019-10-11 at 16:47 +0200, Mario Torre wrote: > > > Hi Severin, > > > > > > The patch looks good to me. > > > > Thanks for the review, Mario! > > > > Cheers, > > Severin > > > > > On Fri, Sep 27, 2019 at 10:38 AM Severin Gehwolf wrote: > > > > Hi! > > > > > > > > I'd appreciate a review of this one. Thanks in advance! See below. > > > > > > > > On Tue, 2019-09-03 at 17:50 +0200, Severin Gehwolf wrote: > > > > > On Mon, 2019-08-26 at 17:54 +0200, Severin Gehwolf wrote: > > > > > > Hi, > > > > > > > > > > > > Please review this 8u backport. The OpenJDK 11u patch does not apply > > > > > > cleanly after path-reshuffeling due to a) test and code for jaxp are > > > > > > split in JDK 8 b) Some rejects in comments - copyright and last > > > > > > modified date. I've omitted rejected comments. I can manually add them > > > > > > if that's preferred. See below. > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213734 > > > > > > webrevs: > > > > > > jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/ > > > > > > jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/01/webrev/ > > > > > > > > > > > > Testing: tier1 on Linux x86_64. javax/xml/jaxp tests. New test on > > > > > > Windows without the fix fails and passes with it. > > > > > > > > > > > > Thanks to Simon Tooke who helped testing this patch on Windows. > > > > > > > > > > > > Rejects: > > > > > > $ cat src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java.rej > > > > > > --- XMLEntityManager.java > > > > > > +++ XMLEntityManager.java > > > > > > @@ -1,5 +1,5 @@ > > > > > > /* > > > > > > - * Copyright (c) 2009, 2017, Oracle and/or its affiliates. All rights reserved. > > > > > > + * Copyright (c) 2009, 2018, Oracle and/or its affiliates. All rights reserved. > > > > > > */ > > > > > > /* > > > > > > * Licensed to the Apache Software Foundation (ASF) under one or more > > > > > > @@ -89,7 +89,7 @@ > > > > > > * @author K.Venugopal SUN Microsystems > > > > > > * @author Neeraj Bajaj SUN Microsystems > > > > > > * @author Sunitha Reddy SUN Microsystems > > > > > > - * @LastModified: Oct 2017 > > > > > > + * @LastModified: Nov 2018 > > > > > > */ > > > > > > public class XMLEntityManager implements XMLComponent, XMLEntityResolver { > > > > > > > > > > > > > > > > Gentle reminder. > > > > > > > > Anyone? It's been a month :( > > > > > > > > FWIW, I've updated XMLEntityManager to include the copyright update > > > > upper bound to 2018. The @LastModified lines don't exist in JDK 8u, so > > > > I've omitted that. Latest webrevs: > > > > > > > > webrevs: > > > > jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/ > > > > jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/02/webrev/ > > > > > > > > Thanks, > > > > Severin > > > > > > The copyright header was going to be my one comment about the JAXP > patch, so good to see it fixed in the second revision. The @LastModified > lines were added by "8193568: @LastModified tag in license header", an > odd fix which is apparently not even viewable. Maybe someone will end up > having to backport it just because it becomes such a pain :( > > With the JDK side, you don't really explain why it was necessary to > convert the test from a TestNG one. Could you elaborate please? That was a long time ago. I don't quite remember, but it appears to have been a test infra issue. For example BasePolicy doesn't seem to be in 8. It came with JDK-8067170 which is a huge patch not really suitable to backport. Is that explanation sufficient? Thanks, Severin From matthias.baesken at sap.com Fri Mar 6 14:52:11 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 6 Mar 2020 14:52:11 +0000 Subject: PING: RFR(s): 8240189: [TESTBUG] Some cgroup tests are failing after JDK-8231111 In-Reply-To: <737b4f5966247977a3259bde33628d42c771394c.camel@redhat.com> References: <650F46E1-75E5-4FA3-AF6C-451431CE0ABE@oracle.com> <1625d0c224747641b553831bf4be7e7afefd3c8d.camel@redhat.com> <737b4f5966247977a3259bde33628d42c771394c.camel@redhat.com> Message-ID: Hi Severin, looks good to me too . Best regards, Matthias > Hi, > > I still need a *R*eview for this. Any takers? > > Thanks, > Severin > > On Fri, 2020-02-28 at 14:52 +0100, Severin Gehwolf wrote: > > Hi Bob, > > > > On Thu, 2020-02-27 at 15:04 -0500, Bob Vandette wrote: > > > The updates look fine to me. > > > > Thanks for the review! > > > > > Have you scanned through all tests looking for ?.length? and [0] to > > > see if we have any more cases that need updating? > > > > I have now and haven't found any places where it's incorrect. There are > > legit cases which still remain after this patch. > > > > Thanks, > > Severin > > > > > Bob. > > > > > > > > > > On Feb 27, 2020, at 2:31 PM, Severin Gehwolf > > > > wrote: > > > > > > > > Hi, > > > > > > > > Could somebody please review those test fixes for the Metrics > > > > platform > > > > tests? Some code paths are apparently not being executed on > > > > "common" > > > > platforms which didn't make those issues show up earlier :-/ I've > > > > missed to update some hard-coded values to account for changes done > > > > via > > > > JDK-8231111. Matthias Baesken from SAP was kind enough to run this > > > > through their testing and no more issues show up after this. Much > > > > appreciated, Matthias! > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8240189 > > > > webrev: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8240189/01/webrev/ > > > > > > > > Testing: Docker tests on Linux x86_64 cgroups v1 and Linux cgroups > > > > v2 > > > > (no change). Additional testing done by SAP. All seems to look > > > > good. > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Severin > > > > From sgehwolf at redhat.com Fri Mar 6 15:01:27 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 06 Mar 2020 16:01:27 +0100 Subject: PING: RFR(s): 8240189: [TESTBUG] Some cgroup tests are failing after JDK-8231111 In-Reply-To: References: <650F46E1-75E5-4FA3-AF6C-451431CE0ABE@oracle.com> <1625d0c224747641b553831bf4be7e7afefd3c8d.camel@redhat.com> <737b4f5966247977a3259bde33628d42c771394c.camel@redhat.com> Message-ID: <6449b11305c12c0efab858220a20709039b88904.camel@redhat.com> On Fri, 2020-03-06 at 14:52 +0000, Baesken, Matthias wrote: > Hi Severin, looks good to me too . Thanks for the review! Cheers, Severin > Best regards, Matthias > > > > > Hi, > > > > I still need a *R*eview for this. Any takers? > > > > Thanks, > > Severin > > > > On Fri, 2020-02-28 at 14:52 +0100, Severin Gehwolf wrote: > > > Hi Bob, > > > > > > On Thu, 2020-02-27 at 15:04 -0500, Bob Vandette wrote: > > > > The updates look fine to me. > > > > > > Thanks for the review! > > > > > > > Have you scanned through all tests looking for ?.length? and [0] to > > > > see if we have any more cases that need updating? > > > > > > I have now and haven't found any places where it's incorrect. There are > > > legit cases which still remain after this patch. > > > > > > Thanks, > > > Severin > > > > > > > Bob. > > > > > > > > > > > > > On Feb 27, 2020, at 2:31 PM, Severin Gehwolf > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > Could somebody please review those test fixes for the Metrics > > > > > platform > > > > > tests? Some code paths are apparently not being executed on > > > > > "common" > > > > > platforms which didn't make those issues show up earlier :-/ I've > > > > > missed to update some hard-coded values to account for changes done > > > > > via > > > > > JDK-8231111. Matthias Baesken from SAP was kind enough to run this > > > > > through their testing and no more issues show up after this. Much > > > > > appreciated, Matthias! > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8240189 > > > > > webrev: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8240189/01/webrev/ > > > > > Testing: Docker tests on Linux x86_64 cgroups v1 and Linux cgroups > > > > > v2 > > > > > (no change). Additional testing done by SAP. All seems to look > > > > > good. > > > > > > > > > > Thoughts? > > > > > > > > > > Thanks, > > > > > Severin > > > > > From chiroito107 at gmail.com Fri Mar 6 15:25:26 2020 From: chiroito107 at gmail.com (Chihiro Ito) Date: Sat, 7 Mar 2020 00:25:26 +0900 Subject: PING: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: References: Message-ID: Hi, I tried to correct this problem. Could you review this fix, please? According to the RFC 4122, UUID has a fixed format. I tried to raise an exception if a string was specified that is not suitable for this format. Also, is there anything else I should be aware of with this bug? Webrev : http://cr.openjdk.java.net/~cito/JDK-8216407/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8216407 Regards, Chihiro 2020?3?3?(?) 0:39 Chihiro Ito : > > Hi, > > I tried to correct this problem. > > Could you review this fix, please? > > According to the RFC 4122, UUID has a fixed format. I tried to raise an exception if a string was specified that is not suitable for this format. Also, is there anything else I should be aware of with this bug? > > Webrev : http://cr.openjdk.java.net/~cito/JDK-8216407/webrev.00/ > JBS : https://bugs.openjdk.java.net/browse/JDK-8216407 > > Regards, > Chihiro From Roger.Riggs at oracle.com Fri Mar 6 16:16:17 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 6 Mar 2020 11:16:17 -0500 Subject: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder In-Reply-To: References: Message-ID: <57fe39f8-817d-3278-b904-d9c83aea03f6@oracle.com> Hi Brian, Updated webrev: http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893-1/index.html The threshold is a pretty loose target. Given the original error that leaked a handle for every process started, it just needs to detect a growing number of handles in use.? But for the sake of accuracy and avoiding someone copying buggy code, its fixed. Thanks, Roger On 3/5/20 4:07 PM, Brian Burkhalter wrote: > Hi Roger, > >> On Mar 5, 2020, at 12:51 PM, Roger Riggs > > wrote: >> >> Please review a change to the Windows ProcessImpl to ensure that the >> handles >> created for the input and output streams of a process are closed when >> no longer referenced. >> >> Unlike on Linux, there is no thread monitoring the process that can >> close the streams. >> The FileDescriptors are registered with the Cleaner to be closed when >> they are no longer referenced. >> >> A test is added that monitors the count of handles as 50 Processes >> are launched and exit. >> The test and change only affect the Windows implementation. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8239893 > > In CheckHandles.java at line 72 there is this calculation: > final long ERROR_THRESHOLD = minHandles + (minHandles / > ERROR_PERCENT); // 10% increase over min to passing max > Do you think it would be better as > > final long ERROR_THRESHOLD = minHandles + ((minHandles + ERROR_PERCENT > - 1) / ERROR_PERCENT); // 10% increase over min to passing max > > , i.e., rounded instead of truncated? > > Brian From Roger.Riggs at oracle.com Fri Mar 6 16:17:32 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 6 Mar 2020 11:17:32 -0500 Subject: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder In-Reply-To: <45139c69-55c6-68fe-74bd-6432d2c935a4@oracle.com> References: <45139c69-55c6-68fe-74bd-6432d2c935a4@oracle.com> Message-ID: <39912e57-b739-c54e-d856-fe8422ab4820@oracle.com> Hi Naoto, Updated webrev: http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893-1/index.html I don't think getting handle count of your own process can ever fail. But in the abundance of caution, added a check and failure. Copyright updated. Thanks, Roger Corrected copyright On 3/5/20 4:14 PM, naoto.sato at oracle.com wrote: > Hi Roger, > > In the test, the error value (-1) from the native code seems silently > suppressed. Should it be caught/reported in the java side? > > nit: copyright year in ProcessImpl.java -> 2020. > > Naoto > > On 3/5/20 12:51 PM, Roger Riggs wrote: >> Please review a change to the Windows ProcessImpl to ensure that the >> handles >> created for the input and output streams of a process are closed when >> no longer referenced. >> >> Unlike on Linux, there is no thread monitoring the process that can >> close the streams. >> The FileDescriptors are registered with the Cleaner to be closed when >> they are no longer referenced. >> >> A test is added that monitors the count of handles as 50 Processes >> are launched and exit. >> The test and change only affect the Windows implementation. >> >> Webrev: >> ?? http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893/ >> >> Issue: >> ?? https://bugs.openjdk.java.net/browse/JDK-8239893 >> >> Thanks, Roger >> From brian.burkhalter at oracle.com Fri Mar 6 16:22:30 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 6 Mar 2020 08:22:30 -0800 Subject: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder In-Reply-To: <57fe39f8-817d-3278-b904-d9c83aea03f6@oracle.com> References: <57fe39f8-817d-3278-b904-d9c83aea03f6@oracle.com> Message-ID: Hi Roger, Looks good! Brian > On Mar 6, 2020, at 8:16 AM, Roger Riggs wrote: > > Updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893-1/index.html > > The threshold is a pretty loose target. > Given the original error that leaked a handle for every process started, it just needs to detect a growing number of handles in use. But for the sake of accuracy and avoiding someone copying buggy code, its fixed. From calvin.cheung at oracle.com Fri Mar 6 16:44:21 2020 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 6 Mar 2020 08:44:21 -0800 Subject: RFR(S): 8232081: Try to link all classes during dynamic CDS dump In-Reply-To: <209d74da-fdb9-1ca1-4410-75c530cfd575@oracle.com> References: <9b40145a-db72-6313-3b98-5e5aea754e25@oracle.com> <1167ff6d-3997-6390-d020-d0946fad0af8@oracle.com> <3f373a33-c7ed-0237-1dd5-f8ac8e8794ee@oracle.com> <8ac4612b-fae3-bb16-f2ab-fa323c33ca51@oracle.com> <00090c43-1e0d-2b1c-d2a5-1b5f1b29199d@oracle.com> <7a54e00f-c049-a5ef-0afc-bb6c9d0f30ad@oracle.com> <5fa95d9f-47a7-c1c7-90e5-87db0173e3b7@oracle.com> <35a07978-29f7-8e16-c50a-0c97ee575871@oracle.com> <209d74da-fdb9-1ca1-4410-75c530cfd575@oracle.com> Message-ID: <916938b1-b7f2-22da-786f-f1a772984d80@oracle.com> Hi Ioi, On 3/5/20 9:16 PM, Ioi Lam wrote: > Hi Calvin, > > Looks good. Thanks for taking another look. > > In JDK-8240244, I removed "ik->loader_type() != 0" because it's > unclear what it means. I replaced with a new method > InstanceKlass::is_shared_unregistered_class(). I think you can use > this in your patch instead of adding loader_type() back. I'll make the change and do more testing before push. thanks, Calvin > > No need for new webrev. > > Thanks > - Ioi > > > On 3/5/20 11:48 AM, Calvin Cheung wrote: >> >> On 3/5/20 9:17 AM, Ioi Lam wrote: >>> Hi Calvin, >>> >>> Looks good overall. I just have two comment: >>> >>> I think this is not needed: >>> >>> ?306 void ConstantPool::resolve_class_constants(TRAPS) { >>> ?307?? Arguments::assert_is_dumping_archive(); >> I've reverted this change. >>> >>> because this function is used to resolve all Strings in the >>> statically dumped classes to archive all the Strings. However, the >>> archive heap is not supported for the dynamic archive. So I think >>> it's better to avoid calling this function from >>> LinkSharedClassesClosure for dynamic dump. >> Now, the function will not be called with dynamic dump: >> 1714???????? if (DumpSharedSpaces) { >> 1715?????????? // The following function is used to resolve all >> Strings in the statically >> 1716?????????? // dumped classes to archive all the Strings. The >> archive heap is not supported >> 1717?????????? // for the dynamic archive. >> 1718 ik->constants()->resolve_class_constants(THREAD); >> 1719???????? } >>> >>> LinkSharedClassesClosure::_is_static -- maybe we can avoid adding >>> this field and just check "if (DumpSharedSpaces)" instead? >> >> This is a good simplification. >> >> btw, you've removed loader_type() from instanceKlass.hpp when you >> pushed the change for JDK-8240244. I've added it back as >> shared_loader_type(). >> >> updated webrev: >> >> ??? http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.04/ >> >> thanks, >> >> Calvin >> >>> >>> Thanks >>> - Ioi >>> >>> >>> >>> >>> >>> On 3/4/20 9:13 PM, Calvin Cheung wrote: >>>> Hi David, Ioi, >>>> >>>> Here's an updated webrev which doesn't involve changing >>>> InstanceKlass::verify_on() and made use of the changes for >>>> JDK-8240481. >>>> >>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.03/ >>>> >>>> thanks, >>>> Calvin >>>> >>>> On 3/1/20 10:14 PM, David Holmes wrote: >>>>> Hi Calvin, >>>>> >>>>> On 28/02/2020 4:12 pm, Calvin Cheung wrote: >>>>>> Hi David, >>>>>> >>>>>> On 2/27/20 5:40 PM, David Holmes wrote: >>>>>>> Hi Calvin, Ioi, >>>>>>> >>>>>>> Looking good - comments below. >>>>>>> >>>>>>> A meta-question: normal application classes are rarely loaded >>>>>>> but not linked so I'm a little surprised this is an issue. What >>>>>>> is the main source of such classes - generated classes like >>>>>>> lambda forms? Also why do we need to link them when loading from >>>>>>> the archive if they were never linked when the application >>>>>>> actually executed ?? >>>>>> >>>>>> I saw that Ioi already answered the above. >>>>>> >>>>>> I'll try to answer your questions inline below.. >>>>> >>>>> Responses inline below ... >>>>> >>>>>>> >>>>>>> On 28/02/2020 10:48 am, Calvin Cheung wrote: >>>>>>>> Hi David, Ioi, >>>>>>>> >>>>>>>> Thanks for your review and suggestions. >>>>>>>> >>>>>>>> On 2/26/20 9:46 PM, Ioi Lam wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/26/20 7:50 PM, David Holmes wrote: >>>>>>>>>> Hi Calvin, >>>>>>>>>> >>>>>>>>>> Adding core-libs-dev as you are messing with their code :) >>>>>>>>>> >>>>>>>>>> On 27/02/2020 1:19 pm, Calvin Cheung wrote: >>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8232081 >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The proposed changeset for this RFE adds a >>>>>>>>>>> JVM_LinkClassesForCDS() function to be called from >>>>>>>>>>> java/lang/Shutdown to notify the JVM to link the classes >>>>>>>>>>> loaded by the builtin class loaders. The >>>>>>>>>> >>>>>>>>>> This would be much less disruptive if this was handled purely >>>>>>>>>> on the VM side once we have started shutdown. No need to make >>>>>>>>>> any changes to the Java side then, nor jvm.cpp. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> To link the classes, we need to be able to run Java code -- >>>>>>>>> when linking a class X loaded by the app loader, X will be >>>>>>>>> verified. During verification of X, we may need to load >>>>>>>>> additional classes from the app loader, which executes Java >>>>>>>>> code during its class loading operations. >>>>>>>>> >>>>>>>>> We also need to handle all the exit conditions. As far as I >>>>>>>>> can tell, an app can exit the JVM in two ways: >>>>>>>>> >>>>>>>>> (1) Explicitly calling System.exit(). This will call >>>>>>>>> java.lang.Shutdown.exit() which does this: >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l163 >>>>>>>>> >>>>>>>>> >>>>>>>>> ??????????? beforeHalt(); // native >>>>>>>>> ??????????? runHooks(); >>>>>>>>> ??????????? halt(status); >>>>>>>>> >>>>>>>>> (2) When all non-daemon threads have died (e.g., falling out >>>>>>>>> of the bottom of HelloWorld.main()). There's no explicit call >>>>>>>>> to System.exit(), but the JVM will proactively call >>>>>>>>> java.lang.Shutdown.shutdown() inside >>>>>>>>> JavaThread::invoke_shutdown_hooks() >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/hotspot/share/runtime/thread.cpp#l4331 >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/0edc7fd0d7a3/src/java.base/share/classes/java/lang/Shutdown.java#l184 >>>>>>>>> >>>>>>>>> >>>>>>>>> If we want to avoid modifying the Java code, I think we can >>>>>>>>> intercept JVM_BeforeHalt() and >>>>>>>>> JavaThread::invoke_shutdown_hooks(). This way we should be >>>>>>>>> able to handle all the classes (except those that are loaded >>>>>>>>> inside Shutdown.runHooks). >>>>>>>> >>>>>>>> I've implemented the above. No changes to the Java side. >>>>>>>> >>>>>>>> updated webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.01/ >>>>>>> >>>>>>> This looks much better to me. I wasn't sure if you were that >>>>>>> concerned about catching the classes loaded by the Shutdown >>>>>>> hooks, but it is good you are not as it seems problematic to me >>>>>>> to trigger class loading etc after the shutdown hooks have >>>>>>> executed - you may hit unexpected conditions. So this approach >>>>>>> is good. >>>>>>> >>>>>>> A few minor comments: >>>>>>> >>>>>>> src/hotspot/share/memory/metaspaceShared.cpp >>>>>>> src/hotspot/share/memory/metaspaceShared.hpp >>>>>>> >>>>>>> Why the change from TRAPS to "Thread* THREAD"? >>>>>> I forgot why I changed it but I've changed it back and it still >>>>>> works. >>>>> >>>>> Ok. >>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/hotspot/share/oops/instanceKlass.cpp >>>>>>> >>>>>>> I'm not clear how verify_on is used so am unsure how the >>>>>>> additional error state check may affect code unrelated to >>>>>>> dynamic dumping ?? >>>>>> >>>>>> Some of the appcds tests by design have some classes which fail >>>>>> verification. Without the change, the following assert would fail: >>>>>> >>>>>> void vtableEntry::verify(klassVtable* vt, outputStream* st) { >>>>>> ?? Klass* vtklass = vt->klass(); >>>>>> ?? if (vtklass->is_instance_klass() && >>>>>> ????? (InstanceKlass::cast(vtklass)->major_version() >= >>>>>> klassVtable::VTABLE_TRANSITIVE_OVERRIDE_VERSION)) { >>>>>> *assert*(method() != NULL, "must have set method"); >>>>>> ?? } >>>>> >>>>> Okay so you need to exclude for that case but ... >>>>> >>>>>> Here's the call stack during dynamic CDS dump to the above function: >>>>>> >>>>>> vtableEntry::verify(klassVtable *, outputStream *) : void >>>>>> ???? klassVtable::verify(outputStream *, bool) : void >>>>>> ???????? InstanceKlass::verify_on(outputStream *) : void >>>>>> ???????????? Klass::verify() : void >>>>>> ???????????????? ClassLoaderData::verify() : void >>>>>> ???????????????????? ClassLoaderDataGraph::verify() : void >>>>>> ???????????????????????? Universe::verify(enum VerifyOption, >>>>>> const char *) : void >>>>>> ???????????????????????????? Universe::verify(const char *) : void >>>>>> DynamicArchiveBuilder::verify_universe(const char *) : void >>>>>> DynamicArchiveBuilder::doit() : void (2 matches) >>>>>> VM_PopulateDynamicDumpSharedSpace::doit() : void >>>>>> VM_Operation::evaluate() : void >>>>>> >>>>>> The is_linked() function is implemented as: >>>>>> >>>>>> ???? bool is_linked() const?????????????????? { return >>>>>> _init_state >= linked; } >>>>>> >>>>>> which includes 'initialization_error'. >>>>> >>>>> ... AFAICS Universe::verify is call from a number of places, all >>>>> of which would reach this modified code. As that existing code has >>>>> included classes that are in the error state then it seems to me >>>>> that unless you can prove otherwise you need to keep the existing >>>>> code as-is for the non-CDS dump case. >>>>> >>>>>> A previous version of the changeset (including the change in >>>>>> question in instanceKlass.cpp) passed tier1 - 4 testing. Let me >>>>>> know if I should run other tests to make sure the change is good. >>>>> >>>>> There may well not be a test that covers this. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>>> >>>>>>> Also can I suggest (as you are touching this code) to delete the >>>>>>> ancient comment: >>>>>>> >>>>>>> 3580???? // $$$ This used to be done only for m/s collections. >>>>>>> Doing it >>>>>>> 3581???? // always seemed a valid generalization. (DLD -- 6/00) >>>>>> >>>>>> I'm glad that you suggested to remove the above comment. I've no >>>>>> clue what it means either. >>>>>> >>>>>> updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.02/ >>>>>> >>>>>> thanks, >>>>>> Calvin >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> I also updated the test to test the shutdown hook and >>>>>>>> System.exit() scenarios. >>>>>>>> >>>>>>>> All appcds tests passed on my linux host. I'll run more tests >>>>>>>> using mach5. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Calvin >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> - Ioi >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> MetaspaceShared::link_and_cleanup_shared_classes() has been >>>>>>>>>>> modified to handle both static and dynamic CDS dump. For >>>>>>>>>>> dynamic CDS dump, only classes loaded by the builtin class >>>>>>>>>>> loaders will be linked. Local performance testing using >>>>>>>>>>> javac on HelloWorld.java shows an improvement of >5%. >>>>>>>>>>> >>>>>>>>>>> Passed tier1 - 4 tests. >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> >>>>>>>>>>> Calvin >>>>>>>>>>> >>>>>>>>> >>> > From naoto.sato at oracle.com Fri Mar 6 17:14:36 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 6 Mar 2020 09:14:36 -0800 Subject: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder In-Reply-To: <39912e57-b739-c54e-d856-fe8422ab4820@oracle.com> References: <45139c69-55c6-68fe-74bd-6432d2c935a4@oracle.com> <39912e57-b739-c54e-d856-fe8422ab4820@oracle.com> Message-ID: Looks good. Thanks for the update. Naoto On 3/6/20 8:17 AM, Roger Riggs wrote: > Hi Naoto, > > Updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893-1/index.html > > I don't think getting handle count of your own process can ever fail. > But in the abundance of caution, added a check and failure. > > Copyright updated. > > Thanks, Roger > > > Corrected copyright > > On 3/5/20 4:14 PM, naoto.sato at oracle.com wrote: >> Hi Roger, >> >> In the test, the error value (-1) from the native code seems silently >> suppressed. Should it be caught/reported in the java side? >> >> nit: copyright year in ProcessImpl.java -> 2020. >> >> Naoto >> >> On 3/5/20 12:51 PM, Roger Riggs wrote: >>> Please review a change to the Windows ProcessImpl to ensure that the >>> handles >>> created for the input and output streams of a process are closed when >>> no longer referenced. >>> >>> Unlike on Linux, there is no thread monitoring the process that can >>> close the streams. >>> The FileDescriptors are registered with the Cleaner to be closed when >>> they are no longer referenced. >>> >>> A test is added that monitors the count of handles as 50 Processes >>> are launched and exit. >>> The test and change only affect the Windows implementation. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8239893 >>> >>> Thanks, Roger >>> > From joe.darcy at oracle.com Fri Mar 6 18:07:40 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 6 Mar 2020 10:07:40 -0800 Subject: PING: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: References: Message-ID: <0d71a07a-45da-58bc-036b-d044fabee94b@oracle.com> Hello Chihiro, Note that as the proposed change affects behavioral compatibility, it will need to have CSR review (https://wiki.openjdk.java.net/display/csr/Main) in addition to code review. Reviewers might find it helpful to have a written categorization of the strings this change rejects that are now accepted. Thanks, -Joe On 3/6/2020 7:25 AM, Chihiro Ito wrote: > Hi, > > I tried to correct this problem. > > Could you review this fix, please? > > According to the RFC 4122, UUID has a fixed format. I tried to raise > an exception if a string was specified that is not suitable for this > format. Also, is there anything else I should be aware of with this > bug? > > Webrev : http://cr.openjdk.java.net/~cito/JDK-8216407/webrev.00/ > JBS : https://bugs.openjdk.java.net/browse/JDK-8216407 > > Regards, > Chihiro > > 2020?3?3?(?) 0:39 Chihiro Ito : >> Hi, >> >> I tried to correct this problem. >> >> Could you review this fix, please? >> >> According to the RFC 4122, UUID has a fixed format. I tried to raise an exception if a string was specified that is not suitable for this format. Also, is there anything else I should be aware of with this bug? >> >> Webrev : http://cr.openjdk.java.net/~cito/JDK-8216407/webrev.00/ >> JBS : https://bugs.openjdk.java.net/browse/JDK-8216407 >> >> Regards, >> Chihiro From Roger.Riggs at oracle.com Fri Mar 6 18:15:28 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 6 Mar 2020 13:15:28 -0500 Subject: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: References: Message-ID: <4c366dd4-5d10-b218-b30d-c59d5aa72c35@oracle.com> Hi? Chihiro, et.al., Thanks for taking a look at this issue,? however... There has been a long history of concerns[1] about breaking existing applications that depend on the loose parsing of UUIDs.? Throwing an exception where it did not previously is an incompatible change. The crucial concern about performance parsing conforming strings has been addressed by: 8196334 Optimize UUID#fromString I propose to close these as WILL-NOT-FIX: and hope that the next several times it gets reported they will be closed as duplicates. 8216407 java.util.UUID.fromString accepts input that does not match expected format 8165199 UUID.fromString accepts wrong placements of the dashes Any other suggestions welcome. Thanks, Roger [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html On 3/2/20 10:39 AM, Chihiro Ito wrote: > Hi, > > I tried to correct this problem. > > Could you review this fix, please? > > According to the RFC 4122, UUID has a fixed format. I tried to raise an > exception if a string was specified that is not suitable for this > format. Also, is there anything else I should be aware of with this bug? > > Webrev : http://cr.openjdk.java.net/~cito/JDK-8216407/webrev.00/ > JBS : https://bugs.openjdk.java.net/browse/JDK-8216407 > > Regards, > Chihiro From Roger.Riggs at oracle.com Fri Mar 6 18:49:56 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 6 Mar 2020 13:49:56 -0500 Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF In-Reply-To: References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com> <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com> <14E6EF7F-C01F-4407-B865-32089266DC28@oracle.com> Message-ID: <665e81fc-5136-2cf6-748b-6c6f448cfc16@oracle.com> :) Still looks fine. On 3/5/20 4:53 PM, Brian Burkhalter wrote: > Might anyone else have any comments on this thread the original post in which was [1]. > > Thanks, > > Brian > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064417.html > >> On Jan 31, 2020, at 12:21 PM, Brian Burkhalter wrote: >> >>> On Jan 31, 2020, at 12:20 PM, Alan Bateman > wrote: >>> >>> On 31/01/2020 20:10, Brian Burkhalter wrote: >>>> : >>>> OK. I?ll change /TERM/EOL/ but not post another webrev unless there are further comments. I will wait to check it in until Monday in case someone has comments. >>>> >>> I think it would be good to more eyes on this as LNR has a history of resisting change. >> I?ll hold off on it then for a while. >> >>> I think you'll need a CSR too this re-specifies when the conditions when the line number is incremented. >> Yes, I agree. From brian.burkhalter at oracle.com Fri Mar 6 19:13:52 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 6 Mar 2020 11:13:52 -0800 Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF In-Reply-To: <665e81fc-5136-2cf6-748b-6c6f448cfc16@oracle.com> References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com> <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com> <14E6EF7F-C01F-4407-B865-32089266DC28@oracle.com> <665e81fc-5136-2cf6-748b-6c6f448cfc16@oracle.com> Message-ID: <575CE79A-D60C-4550-B74D-EDA1FAFBAF2F@oracle.com> Thanks, Roger. I?ll let it hang until next week and then file a CSR. Brian > On Mar 6, 2020, at 10:49 AM, Roger Riggs wrote: > > :) Still looks fine. > > On 3/5/20 4:53 PM, Brian Burkhalter wrote: >> Might anyone else have any comments on this thread the original post in which was [1]. >> >> Thanks, >> >> Brian >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064417.html From henry.jen at oracle.com Fri Mar 6 22:40:27 2020 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 6 Mar 2020 14:40:27 -0800 Subject: RFR: 8240629: argfiles parsing broken for argfiles with comment cross 4096 bytes chunk In-Reply-To: <6DD2702D-76A9-477C-B0FA-990B498A3AE5@oracle.com> References: <1768c55f6ba0722d96f2bb978c3ce3f820779cfa.camel@gmx.de> <6704dc02d2a4b8e140eb4d55cbae8204d6250fb2.camel@gmx.de> <6014206a3374bf18059488bbf4cfae4bd0e687c7.camel@gmx.de> <6DD2702D-76A9-477C-B0FA-990B498A3AE5@oracle.com> Message-ID: <0BFCC490-42A0-43ED-A020-981A31867623@oracle.com> Hi, Please review the webrev[1] fix JDK-8240629 reported earlier by Robert. http://cr.openjdk.java.net/~henryjen/jdk/8240629.0/webrev/ Cheers, Henry From rafael.wth at gmail.com Sat Mar 7 01:15:11 2020 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Sat, 7 Mar 2020 02:15:11 +0100 Subject: 8202469 / 8202473: Correct type annotation resolution for class type variables In-Reply-To: References: <0aaaa441-c193-6155-4da3-5bd91888f73e@oracle.com> Message-ID: I finally found the time to look at this again, sorry for the delay. Thank you for your comments. I had the chance to better look into the problem and simplify the code a bit more and also reduced the scope of the fix to a single problem. I also added test cases that should be exhaustive for all possible scenarios and adjusted the code comment. I uploaded the adjusted patch as a webrev: http://cr.openjdk.java.net/~winterhalter/8202469/webrev.01/ Thanks, Rafael Am So., 16. Feb. 2020 um 10:51 Uhr schrieb Joel Borggr?n-Franck < joel.borggren.franck at gmail.com>: > Hi Rafael, > > Thanks for reaching out and reminding me of this! > > I managed to find some time to look into 8202469 during the weekend. By > swapping place of the TVars in the test I managed to isolate this without > depending on 8202473, take a look at my hacky copy-paste update to your > test at http://cr.openjdk.java.net/~jfranck/8202469/ . > > The comment on lines 269-276 needs to be updated. Perhaps include a table > with the start index depending of the type? Also referencing JVMLS 4.4 for > the structure of the bound might be instructive for future readers. > > My current understanding is that there are two problems with the code on > (the original) lines 277-287: > 1) Type Variables should have index 0 while getting index 1 due to lines > 279-280. > 2) Bounds that are instances of ParameterizedType always gets index 1 but > if the first bound represents a Class type the index should be 0. > > Does this make sense? > > Can you make the if-switches positive? I find my original code with the > negative tests hard to read and the update doesn't help. > > Also can you expand the test to cover the different kinds of bounds > mentioned in 4.4 and also test Type Variables on methods, I suspect javac > treats method (and constructor) tvars similarly but there have been bugs ... > > TL;DR please update the webrev with: > > - Split out test and fix for 8202469 > - More test coverage of different kinds of bounds > - Test for method tvars > - See if you can rework the logic to have (mostly) positive tests in if > switch > > Thanks again for looking into this, I'll start looking into 8202473, I > think the fix for that one opens up a bigger rework of the code which is > why I want to separate the two. > > cheers > /Joel > > On Sun, Aug 4, 2019 at 10:12 PM Rafael Winterhalter > wrote: > >> Hi, >> >> appologies for the delay, I only managed to get my patched up to webrev >> today (http://cr.openjdk.java.net/~winterhalter/). It's three patches in >> total now, for the third one I could not add a test case, it would require >> to compile an annotation property against an enumeration type and load it >> against another class where the enumeration was turned into an annotation. >> I struggled a bit with jtreg to make it work but I cannot see myself >> complete this in a meaningful amount of time. However, I hope that the >> patch and the error it solves are straightforward to see. >> >> I only submitted a patch for 8202469. 8202473 is solved by it. It's two >> bugs but they are a symptom of the same oversight. >> >> I hope this helps you to review it but let me know if you have any >> questions or if I should further adjust my patch. >> >> Best regards, Rafael >> >> Am Fr., 2. Aug. 2019 um 12:18 Uhr schrieb Rafael Winterhalter < >> rafael.wth at gmail.com>: >> >>> Thanks Daniel, >>> I did some work on Glassfish a bunch of years ago, I had no idea. >>> I will try to split up the changes (I fixed another bug in annotation >>> processing yesterday) and upload everything there. >>> Best regards, Rafael >>> >>> Am Fr., 2. Aug. 2019 um 11:59 Uhr schrieb Daniel Fuchs < >>> daniel.fuchs at oracle.com>: >>> >>>> Hi Rafael, >>>> >>>> On 02/08/2019 09:00, Joel Borggr?n-Franck wrote: >>>> > I can host webrevs for you on cr to make it easier for other >>>> reviewers, if >>>> > you also send me the patches or webrefs off-list to get around the >>>> > attachment stripping I can upload them to cr. >>>> >>>> I see that you are a JDK project author, so you already own a page >>>> on cr (http://cr.openjdk.java.net/~winterhalter/) where you can >>>> upload webrevs (e.g. using `scp` as in: >>>> $ scp -r webrev-NNNNN.01 winterhalter at cr.openjdk.java.net: ) >>>> >>>> best regards and welcome! >>>> >>>> -- daniel >>>> >>> From peter.levart at gmail.com Sun Mar 8 07:45:10 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 8 Mar 2020 08:45:10 +0100 Subject: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: <4c366dd4-5d10-b218-b30d-c59d5aa72c35@oracle.com> References: <4c366dd4-5d10-b218-b30d-c59d5aa72c35@oracle.com> Message-ID: <1f484b62-8ab9-6d1b-1f46-a33962141b92@gmail.com> Hi Roger, What about deprecating this method (not for removal at this time) and creating new method UUID.valueOf(String) or similar that would be more strict? Peter On 3/6/20 7:15 PM, Roger Riggs wrote: > Hi Chihiro, et.al., > > Thanks for taking a look at this issue,? however... > > There has been a long history of concerns[1] about breaking existing > applications > that depend on the loose parsing of UUIDs.? Throwing an exception > where it did not > previously is an incompatible change. > > The crucial concern about performance parsing conforming strings has > been addressed by: > > 8196334 Optimize UUID#fromString > > > I propose to close these as WILL-NOT-FIX: and hope that the next > several times it gets reported > they will be closed as duplicates. > > 8216407? > java.util.UUID.fromString accepts input that does not match expected > format > > 8165199 > UUID.fromString > accepts wrong placements of the dashes > > Any other suggestions welcome. > > Thanks, Roger > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html > > > On 3/2/20 10:39 AM, Chihiro Ito wrote: >> Hi, >> >> I tried to correct this problem. >> >> Could you review this fix, please? >> >> According to the RFC 4122, UUID has a fixed format. I tried to raise an >> exception if a string was specified that is not suitable for this >> format. Also, is there anything else I should be aware of with this bug? >> >> Webrev : http://cr.openjdk.java.net/~cito/JDK-8216407/webrev.00/ >> JBS : https://bugs.openjdk.java.net/browse/JDK-8216407 >> >> Regards, >> Chihiro > From peter.levart at gmail.com Sun Mar 8 08:28:26 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 8 Mar 2020 09:28:26 +0100 Subject: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: <1f484b62-8ab9-6d1b-1f46-a33962141b92@gmail.com> References: <4c366dd4-5d10-b218-b30d-c59d5aa72c35@oracle.com> <1f484b62-8ab9-6d1b-1f46-a33962141b92@gmail.com> Message-ID: <3f46be6b-fad5-4a85-1985-84d9dc8107de@gmail.com> On 3/8/20 8:45 AM, Peter Levart wrote: > Hi Roger, > > What about deprecating this method (not for removal at this time) and > creating new method UUID.valueOf(String) or similar that would be more > strict? ... since Andriy Plokhotnyuk and Claes Redestad have already done all the coding (nice work!) while optimizing the UUID.fromString method in [1], it is just a matter of wiring up the code to new public method like in [2] for example. The question is only whether this is a desirable addition. I think it is. I can imagine bugs are a possible outcome when a programmer doesn't realize that different String values can successfully map to a single UUID value. Regards, Peter [1] https://bugs.openjdk.java.net/browse/JDK-8196334 [2] http://cr.openjdk.java.net/~plevart/jdk-dev/8216407_UUID.valueOf/webrev.01/ > > Peter > > On 3/6/20 7:15 PM, Roger Riggs wrote: >> Hi Chihiro, et.al., >> >> Thanks for taking a look at this issue,? however... >> >> There has been a long history of concerns[1] about breaking existing >> applications >> that depend on the loose parsing of UUIDs.? Throwing an exception >> where it did not >> previously is an incompatible change. >> >> The crucial concern about performance parsing conforming strings has >> been addressed by: >> >> 8196334 Optimize UUID#fromString >> >> >> I propose to close these as WILL-NOT-FIX: and hope that the next >> several times it gets reported >> they will be closed as duplicates. >> >> 8216407 >> java.util.UUID.fromString accepts input that does not match expected >> format >> >> 8165199 >> UUID.fromString >> accepts wrong placements of the dashes >> >> Any other suggestions welcome. >> >> Thanks, Roger >> >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html >> >> >> On 3/2/20 10:39 AM, Chihiro Ito wrote: >>> Hi, >>> >>> I tried to correct this problem. >>> >>> Could you review this fix, please? >>> >>> According to the RFC 4122, UUID has a fixed format. I tried to raise an >>> exception if a string was specified that is not suitable for this >>> format. Also, is there anything else I should be aware of with this >>> bug? >>> >>> Webrev : http://cr.openjdk.java.net/~cito/JDK-8216407/webrev.00/ >>> JBS : https://bugs.openjdk.java.net/browse/JDK-8216407 >>> >>> Regards, >>> Chihiro >> > From peter.levart at gmail.com Sun Mar 8 08:46:06 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 8 Mar 2020 09:46:06 +0100 Subject: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: <3f46be6b-fad5-4a85-1985-84d9dc8107de@gmail.com> References: <4c366dd4-5d10-b218-b30d-c59d5aa72c35@oracle.com> <1f484b62-8ab9-6d1b-1f46-a33962141b92@gmail.com> <3f46be6b-fad5-4a85-1985-84d9dc8107de@gmail.com> Message-ID: On 3/8/20 9:28 AM, Peter Levart wrote: > I can imagine bugs are a possible outcome when a programmer doesn't > realize that different String values can successfully map to a single > UUID value. Well, this is still true even with the strict method (since 'a'...'f' is equivalent to 'A'...'F' in parsing the Hex nibbles). So this argument doesn't stand. Well then perhaps this addition is not worth it. Regards, Peter From Alan.Bateman at oracle.com Sun Mar 8 09:54:32 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 8 Mar 2020 09:54:32 +0000 Subject: RFR: 8240629: argfiles parsing broken for argfiles with comment cross 4096 bytes chunk In-Reply-To: <0BFCC490-42A0-43ED-A020-981A31867623@oracle.com> References: <1768c55f6ba0722d96f2bb978c3ce3f820779cfa.camel@gmx.de> <6704dc02d2a4b8e140eb4d55cbae8204d6250fb2.camel@gmx.de> <6014206a3374bf18059488bbf4cfae4bd0e687c7.camel@gmx.de> <6DD2702D-76A9-477C-B0FA-990B498A3AE5@oracle.com> <0BFCC490-42A0-43ED-A020-981A31867623@oracle.com> Message-ID: <4b87ff4e-be27-ee00-655a-441e181eb6a4@oracle.com> On 06/03/2020 22:40, Henry Jen wrote: > Hi, > > Please review the webrev[1] fix JDK-8240629 reported earlier by Robert. > > http://cr.openjdk.java.net/~henryjen/jdk/8240629.0/webrev/ > The changes and test look okay. -Alan From peter.levart at gmail.com Sun Mar 8 11:46:22 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 8 Mar 2020 12:46:22 +0100 Subject: RFR: 8196334: Optimize UUID#fromString In-Reply-To: <3c03d7bb-f0c8-ec44-b52c-75887986904d@oracle.com> References: <4e866637-0ad8-1999-d70a-3635d7ec0f0f@oracle.com> <8f515c5c-c3a5-fda5-2753-e10fedc2a6c4@oracle.com> <412177f3-9496-a331-1e98-cffbb3fba562@oracle.com> <5bc56926-32eb-28a9-1e54-3b8946051f7c@oracle.com> <3784805a-c75d-5f2f-10b1-7eb8e2aa7411@oracle.com> <6c4445da-1e3f-007d-d83c-013b703653d2@oracle.com> <3c03d7bb-f0c8-ec44-b52c-75887986904d@oracle.com> Message-ID: <1128e71b-29e4-d60a-c100-8b64a578fa79@gmail.com> Hi, When I noticed this optimization, I had some ideas how to push this even further, but only now had some time to try them out. Here are some incremental improvements [1] to the already brilliant idea with the following JMH results (the baseline is JDK build with patch for 8196334 already applied): Benchmark???????????????????? (size)?? Mode? Cnt?? Score?? Error Units UUIDBench.uuidFromString?????? 20000? thrpt??? 5? 37.344 ? 0.257 ops/us UUIDBench.uuidFromStringAlt1?? 20000? thrpt??? 5? 29.069 ? 0.137 ops/us UUIDBench.uuidFromStringAlt2?? 20000? thrpt??? 5? 27.308 ? 0.204 ops/us UUIDBench.uuidFromStringAlt3?? 20000? thrpt??? 5? 23.195 ? 0.885 ops/us As can be seen, the trick was to eliminate branches (alt1, alt2) and to reduce the number of operations (shifts) in alt3. One last trick in alt3 was to use the array length in a check that is then fused with array index bounds check (I think) so that we get one of them for free. What do you think? Is this good enough to warrant another change? As you can see, I haven't prepared the patch yet,? just benchmark. Regards, Peter [1] http://cr.openjdk.java.net/~plevart/jdk-dev/8196334_UUID.fromString/UUIDBench.java On 3/2/20 8:26 AM, Claes Redestad wrote: > On 2020-03-02 08:14, Alan Bateman wrote: >>> >>> http://cr.openjdk.java.net/~redestad/8196334/open.02/ >> Looks good. > > Thanks - pushed! > > /Claes From peter.levart at gmail.com Sun Mar 8 11:59:08 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 8 Mar 2020 12:59:08 +0100 Subject: RFR: 8196334: Optimize UUID#fromString In-Reply-To: <1128e71b-29e4-d60a-c100-8b64a578fa79@gmail.com> References: <4e866637-0ad8-1999-d70a-3635d7ec0f0f@oracle.com> <8f515c5c-c3a5-fda5-2753-e10fedc2a6c4@oracle.com> <412177f3-9496-a331-1e98-cffbb3fba562@oracle.com> <5bc56926-32eb-28a9-1e54-3b8946051f7c@oracle.com> <3784805a-c75d-5f2f-10b1-7eb8e2aa7411@oracle.com> <6c4445da-1e3f-007d-d83c-013b703653d2@oracle.com> <3c03d7bb-f0c8-ec44-b52c-75887986904d@oracle.com> <1128e71b-29e4-d60a-c100-8b64a578fa79@gmail.com> Message-ID: <8068a860-c8f2-5510-a8c6-2402d0afce41@gmail.com> Sorry, bash this. I just noticed that the units used in benchmark are ops/us and that the best performing code is the one which is in place now. I usually use ns/op as a unit in JMH benchmarks, so this led me to false belief that alternatives are better performing where in fact are worse. Sorry for noise. Regards, Peter On 3/8/20 12:46 PM, Peter Levart wrote: > Hi, > > When I noticed this optimization, I had some ideas how to push this > even further, but only now had some time to try them out. > > Here are some incremental improvements [1] to the already brilliant > idea with the following JMH results (the baseline is JDK build with > patch for 8196334 already applied): > > Benchmark???????????????????? (size)?? Mode? Cnt?? Score?? Error Units > UUIDBench.uuidFromString?????? 20000? thrpt??? 5? 37.344 ? 0.257 ops/us > UUIDBench.uuidFromStringAlt1?? 20000? thrpt??? 5? 29.069 ? 0.137 ops/us > UUIDBench.uuidFromStringAlt2?? 20000? thrpt??? 5? 27.308 ? 0.204 ops/us > UUIDBench.uuidFromStringAlt3?? 20000? thrpt??? 5? 23.195 ? 0.885 ops/us > > As can be seen, the trick was to eliminate branches (alt1, alt2) and > to reduce the number of operations (shifts) in alt3. One last trick in > alt3 was to use the array length in a check that is then fused with > array index bounds check (I think) so that we get one of them for free. > > What do you think? Is this good enough to warrant another change? As > you can see, I haven't prepared the patch yet,? just benchmark. > > Regards, Peter > > [1] > http://cr.openjdk.java.net/~plevart/jdk-dev/8196334_UUID.fromString/UUIDBench.java > > > On 3/2/20 8:26 AM, Claes Redestad wrote: >> On 2020-03-02 08:14, Alan Bateman wrote: >>>> >>>> http://cr.openjdk.java.net/~redestad/8196334/open.02/ >>> Looks good. >> >> Thanks - pushed! >> >> /Claes > From Alan.Bateman at oracle.com Sun Mar 8 13:53:31 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 8 Mar 2020 13:53:31 +0000 Subject: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: <4c366dd4-5d10-b218-b30d-c59d5aa72c35@oracle.com> References: <4c366dd4-5d10-b218-b30d-c59d5aa72c35@oracle.com> Message-ID: <678539ae-a275-6280-4508-cb4dfffd9b2c@oracle.com> On 06/03/2020 18:15, Roger Riggs wrote: > Hi Chihiro, et.al., > > Thanks for taking a look at this issue,? however... > > There has been a long history of concerns[1] about breaking existing > applications > that depend on the loose parsing of UUIDs.? Throwing an exception > where it did not > previously is an incompatible change. > > The crucial concern about performance parsing conforming strings has > been addressed by: > > 8196334 Optimize UUID#fromString > > > I propose to close these as WILL-NOT-FIX: and hope that the next > several times it gets reported > they will be closed as duplicates. > > 8216407? > java.util.UUID.fromString accepts input that does not match expected > format > > 8165199 > UUID.fromString > accepts wrong placements of the dashes As you say, any tightening up of the validation after 15+ years will create a potential compatibility issue and might not be worth it. Maybe we could re-purpose JDK-8216407 to clarifying the javadoc instead? That would at least help with these bug reports when people are surprise that fromString doesn't fail. -Alan From claes.redestad at oracle.com Sun Mar 8 14:05:43 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 8 Mar 2020 15:05:43 +0100 Subject: RFR: 8196334: Optimize UUID#fromString In-Reply-To: <8068a860-c8f2-5510-a8c6-2402d0afce41@gmail.com> References: <4e866637-0ad8-1999-d70a-3635d7ec0f0f@oracle.com> <8f515c5c-c3a5-fda5-2753-e10fedc2a6c4@oracle.com> <412177f3-9496-a331-1e98-cffbb3fba562@oracle.com> <5bc56926-32eb-28a9-1e54-3b8946051f7c@oracle.com> <3784805a-c75d-5f2f-10b1-7eb8e2aa7411@oracle.com> <6c4445da-1e3f-007d-d83c-013b703653d2@oracle.com> <3c03d7bb-f0c8-ec44-b52c-75887986904d@oracle.com> <1128e71b-29e4-d60a-c100-8b64a578fa79@gmail.com> <8068a860-c8f2-5510-a8c6-2402d0afce41@gmail.com> Message-ID: Hi Peter, sorry about defaulting to throughput measurement - while average time has its advantages (especially on nanobenchmarks), most benchmarks are intuitively "higher is better", so I lean that way by old habit. Thanks for trying out your ideas, though! It's important we try out and report the result of reasonable alternatives, even when they fall short. I've done a number of experiments here that I should have probably made a note of somewhere... Thanks! /Claes On 2020-03-08 12:59, Peter Levart wrote: > Sorry, bash this. > > I just noticed that the units used in benchmark are ops/us and that the > best performing code is the one which is in place now. > > I usually use ns/op as a unit in JMH benchmarks, so this led me to false > belief that alternatives are better performing where in fact are worse. > > Sorry for noise. > > Regards, Peter > > > On 3/8/20 12:46 PM, Peter Levart wrote: >> Hi, >> >> When I noticed this optimization, I had some ideas how to push this >> even further, but only now had some time to try them out. >> >> Here are some incremental improvements [1] to the already brilliant >> idea with the following JMH results (the baseline is JDK build with >> patch for 8196334 already applied): >> >> Benchmark???????????????????? (size)?? Mode? Cnt?? Score?? Error Units >> UUIDBench.uuidFromString?????? 20000? thrpt??? 5? 37.344 ? 0.257 ops/us >> UUIDBench.uuidFromStringAlt1?? 20000? thrpt??? 5? 29.069 ? 0.137 ops/us >> UUIDBench.uuidFromStringAlt2?? 20000? thrpt??? 5? 27.308 ? 0.204 ops/us >> UUIDBench.uuidFromStringAlt3?? 20000? thrpt??? 5? 23.195 ? 0.885 ops/us >> >> As can be seen, the trick was to eliminate branches (alt1, alt2) and >> to reduce the number of operations (shifts) in alt3. One last trick in >> alt3 was to use the array length in a check that is then fused with >> array index bounds check (I think) so that we get one of them for free. >> >> What do you think? Is this good enough to warrant another change? As >> you can see, I haven't prepared the patch yet,? just benchmark. >> >> Regards, Peter >> >> [1] >> http://cr.openjdk.java.net/~plevart/jdk-dev/8196334_UUID.fromString/UUIDBench.java >> >> >> >> On 3/2/20 8:26 AM, Claes Redestad wrote: >>> On 2020-03-02 08:14, Alan Bateman wrote: >>>>> >>>>> http://cr.openjdk.java.net/~redestad/8196334/open.02/ >>>> Looks good. >>> >>> Thanks - pushed! >>> >>> /Claes >> > From Alan.Bateman at oracle.com Sun Mar 8 14:12:45 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 8 Mar 2020 14:12:45 +0000 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> Message-ID: On 05/03/2020 15:19, Denghui Dong wrote: > Hi?Alan?and?Erik, > > Sorry,?I'm?not?sure?if?I?fully?understand?what?you?mean. > For?this?feature,?I?still?think?exporting?jdk.internal.access?to?jdk.jfr?is?a?good?solutionsince?there?are > some?other?packages?has?already?exported?to?jdk.jfr?in?this?module. I think it would be cleaner to put a helper in jdk.internal.misc so that JFR has access to the counters for each of the buffer pools. That would avoid additional plumbing when you extend it to mapped buffers. As I mentioned in one of the other mails, ManagementFactoryHelper.getBufferPoolMXBeans() could be changed to use it too. From the perspective of java.base then it's a lot nicer as anyone touching the buffer code doesn't need to have to concerned with direct access from code in java.management and jdk.jfr. -Alan From denghui.ddh at alibaba-inc.com Sun Mar 8 15:42:56 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Sun, 08 Mar 2020 23:42:56 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIzODY2NTogQWRkIEpGUiBldmVudCBmb3IgZGlyZWN0IG1lbW9yeSBzdGF0?= =?UTF-8?B?aXN0aWNz?= In-Reply-To: References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> , Message-ID: Hi Alan and Erik, Thanks for the review. Webrev has been updated in http://cr.openjdk.java.net/~ddong/8238665/webrev.02/ Testing: jdk/jfr, java/lang/management/ all passed Summary: add a method in jdk.internal.misc.VM to get an unmodifiable buffer pool list. Cheers, Denghui Dong ------------------------------------------------------------------ From:Alan Bateman Send Time:2020?3?8?(???) 22:13 To:???(??) ; Erik Gahlin Cc:hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics On 05/03/2020 15:19, Denghui Dong wrote: Hi Alan and Erik, Sorry, I'm not sure if I fully understand what you mean. For this feature, I still think exporting jdk.internal.access to jdk.jfr is a good solutionsince there are some other packages has already exported to jdk.jfr in this module. I think it would be cleaner to put a helper in jdk.internal.misc so that JFR has access to the counters for each of the buffer pools. That would avoid additional plumbing when you extend it to mapped buffers. As I mentioned in one of the other mails, ManagementFactoryHelper.getBufferPoolMXBeans() could be changed to use it too. From the perspective of java.base then it's a lot nicer as anyone touching the buffer code doesn't need to have to concerned with direct access from code in java.management and jdk.jfr. -Alan From henry.jen at oracle.com Sun Mar 8 18:27:49 2020 From: henry.jen at oracle.com (Henry Jen) Date: Sun, 8 Mar 2020 11:27:49 -0700 Subject: RFR: 8240629: argfiles parsing broken for argfiles with comment cross 4096 bytes chunk In-Reply-To: <4b87ff4e-be27-ee00-655a-441e181eb6a4@oracle.com> References: <1768c55f6ba0722d96f2bb978c3ce3f820779cfa.camel@gmx.de> <6704dc02d2a4b8e140eb4d55cbae8204d6250fb2.camel@gmx.de> <6014206a3374bf18059488bbf4cfae4bd0e687c7.camel@gmx.de> <6DD2702D-76A9-477C-B0FA-990B498A3AE5@oracle.com> <0BFCC490-42A0-43ED-A020-981A31867623@oracle.com> <4b87ff4e-be27-ee00-655a-441e181eb6a4@oracle.com> Message-ID: <90E08D89-BD84-4738-9E86-B3E817E3362C@oracle.com> Thanks for the review, I updated the webrev[1] with simplified test and ensure other cases in boundary won?t be causing trouble by only take meaningful tokens. This fix is more defensive and allow anchor to be ignored when it?s meaningless. [1] http://cr.openjdk.java.net/~henryjen/jdk/8240629.1/webrev/ Cheers, Henry > On Mar 8, 2020, at 1:54 AM, Alan Bateman wrote: > > On 06/03/2020 22:40, Henry Jen wrote: >> Hi, >> >> Please review the webrev[1] fix JDK-8240629 reported earlier by Robert. >> >> http://cr.openjdk.java.net/~henryjen/jdk/8240629.0/webrev/ >> > The changes and test look okay. > > -Alan From scolebourne at joda.org Sun Mar 8 23:22:11 2020 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 8 Mar 2020 23:22:11 +0000 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: <030ee6e9-34dd-5c83-f942-96f07161aaca@oracle.com> References: <030ee6e9-34dd-5c83-f942-96f07161aaca@oracle.com> Message-ID: standardOffsets[0] == wallOffsets[0] needs to use .equals() Unrelated, there is a Javadoc/spec error at line 578 of the "new" file. It should be getValidOffsets, not getOffset. Apart from that, it looks good. thanks Stephen On Wed, 4 Mar 2020 at 19:06, wrote: > > Hi Stephen, > > Thank you for the detailed explanation and correcting the > implementation. I incorporated all the suggestions below, as well as > adding a new test for isFixedOffset() implementation (with some clean-up): > > https://cr.openjdk.java.net/~naoto/8239836/webrev.03/ > > Please take a look at it. > > Naoto > > On 3/3/20 3:30 PM, Stephen Colebourne wrote: > > I fear more changes are needed here. > > > > 1) The code is isFixedOffset() is indeed wrong, but the fix is > > insufficient. The zone is fixed if baseStandardOffset=baseWallOffset > > and all three other lists are empty. A fixed offset rule is the > > equivalent of a ZoneOffset. See ZoneId.normalized() for the code that > > assumes that. > > > > 2) The code in getOffset(Instant) is wrong, but so is the proposed > > fix. The purpose of the if statement is to optimise the following few > > lines which refer to savingsInstantTransitions and wallOffsets. The > > code does have a bug as it should return the first wall offset. > > Corrected code: > > public ZoneOffset getOffset(Instant instant) { > > if (savingsInstantTransitions.length == 0) { > > return wallOffsets[0]; > > } > > With the correct definition of isFixedOffset() it becomes apparent > > that this if statement is in fact not related to the fixed offset. > > > > Currently this test case fails (a zone in DST for all eternity): > > ZoneRules rules = ZoneRules.of( > > ZoneOffset.ofHours(1), > > ZoneOffset.ofHours(2), > > Collections.emptyList(), > > Collections.emptyList(), > > Collections.emptyList()); > > assertEquals(rules.getStandardOffset(Instant.EPOCH), > > ZoneOffset.ofHours(1)); > > assertEquals(rules.getOffset(Instant.EPOCH), ZoneOffset.ofHours(2)); > > > > 3) The code in getStandardOffset(Instant) also has an error as it > > checks the wrong array. It should check standardTransitions as that is > > what is used in the following few lines. Corrected code: > > public ZoneOffset getStandardOffset(Instant instant) { > > if (standardTransitions.length == 0) { > > return standardOffsets[0]; > > } > > > > 4) The code in getOffsetInfo(LocalDateTime dt) has a similar fault. > > Since it protects savingsLocalTransitions, it should return > > wallOffsets[0]. > > > > 5) The code in getDaylightSavings(Instant instant) has an optimising > > if statement that should refer to isFixedOffset(). > > > > 6) Also, in the test. > > assertTrue(!rules.isFixedOffset()); > > should be > > assertFalse(rules.isFixedOffset()); > > > > The class has worked so far as every normal case has > > baseStandardOffset = baseWallOffset, even though it is conceptually > > valid for this not to be true. > > > > Stephen > > > > > > > > > > On Thu, 27 Feb 2020 at 20:42, wrote: > >> > >> Hello, > >> > >> Please review the fix to the following issue: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8239836 > >> > >> The proposed changeset is located at: > >> > >> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ > >> > >> It turned out that 'transitionList' is not necessarily a superset of > >> 'standardOffsetTransitionList', as in some occasions where a standard > >> offset change and a savings change happen at the same time (canceling > >> each other), resulting in no wall time transition. This means that the > >> "rules" in the sample code is a valid ZoneRules instance. > >> > >> However, there is an assumption in ZoneRules where no (wall time) > >> transition means the fixed offset zone. With that assumption, the > >> example rule is considered a fixed offset zone which is not correct. So > >> the fix proposed here is not to throw an IAE but to recognize the rule > >> as a valid, non-fixed offset ZoneRules instance. > >> > >> Naoto > >> > >> From naoto.sato at oracle.com Mon Mar 9 03:05:04 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Sun, 8 Mar 2020 20:05:04 -0700 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: References: <030ee6e9-34dd-5c83-f942-96f07161aaca@oracle.com> Message-ID: <5fd1e013-e516-05d6-bf35-dbf29d572a42@oracle.com> Thanks, Stephen. Updated the webrev for those two suggestions: http://cr.openjdk.java.net/~naoto/8239836/webrev.04/ Naoto On 3/8/20 4:22 PM, Stephen Colebourne wrote: > standardOffsets[0] == wallOffsets[0] needs to use .equals() > > Unrelated, there is a Javadoc/spec error at line 578 of the "new" > file. It should be getValidOffsets, not getOffset. > > Apart from that, it looks good. > > thanks > Stephen > > > On Wed, 4 Mar 2020 at 19:06, wrote: >> >> Hi Stephen, >> >> Thank you for the detailed explanation and correcting the >> implementation. I incorporated all the suggestions below, as well as >> adding a new test for isFixedOffset() implementation (with some clean-up): >> >> https://cr.openjdk.java.net/~naoto/8239836/webrev.03/ >> >> Please take a look at it. >> >> Naoto >> >> On 3/3/20 3:30 PM, Stephen Colebourne wrote: >>> I fear more changes are needed here. >>> >>> 1) The code is isFixedOffset() is indeed wrong, but the fix is >>> insufficient. The zone is fixed if baseStandardOffset=baseWallOffset >>> and all three other lists are empty. A fixed offset rule is the >>> equivalent of a ZoneOffset. See ZoneId.normalized() for the code that >>> assumes that. >>> >>> 2) The code in getOffset(Instant) is wrong, but so is the proposed >>> fix. The purpose of the if statement is to optimise the following few >>> lines which refer to savingsInstantTransitions and wallOffsets. The >>> code does have a bug as it should return the first wall offset. >>> Corrected code: >>> public ZoneOffset getOffset(Instant instant) { >>> if (savingsInstantTransitions.length == 0) { >>> return wallOffsets[0]; >>> } >>> With the correct definition of isFixedOffset() it becomes apparent >>> that this if statement is in fact not related to the fixed offset. >>> >>> Currently this test case fails (a zone in DST for all eternity): >>> ZoneRules rules = ZoneRules.of( >>> ZoneOffset.ofHours(1), >>> ZoneOffset.ofHours(2), >>> Collections.emptyList(), >>> Collections.emptyList(), >>> Collections.emptyList()); >>> assertEquals(rules.getStandardOffset(Instant.EPOCH), >>> ZoneOffset.ofHours(1)); >>> assertEquals(rules.getOffset(Instant.EPOCH), ZoneOffset.ofHours(2)); >>> >>> 3) The code in getStandardOffset(Instant) also has an error as it >>> checks the wrong array. It should check standardTransitions as that is >>> what is used in the following few lines. Corrected code: >>> public ZoneOffset getStandardOffset(Instant instant) { >>> if (standardTransitions.length == 0) { >>> return standardOffsets[0]; >>> } >>> >>> 4) The code in getOffsetInfo(LocalDateTime dt) has a similar fault. >>> Since it protects savingsLocalTransitions, it should return >>> wallOffsets[0]. >>> >>> 5) The code in getDaylightSavings(Instant instant) has an optimising >>> if statement that should refer to isFixedOffset(). >>> >>> 6) Also, in the test. >>> assertTrue(!rules.isFixedOffset()); >>> should be >>> assertFalse(rules.isFixedOffset()); >>> >>> The class has worked so far as every normal case has >>> baseStandardOffset = baseWallOffset, even though it is conceptually >>> valid for this not to be true. >>> >>> Stephen >>> >>> >>> >>> >>> On Thu, 27 Feb 2020 at 20:42, wrote: >>>> >>>> Hello, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8239836 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ >>>> >>>> It turned out that 'transitionList' is not necessarily a superset of >>>> 'standardOffsetTransitionList', as in some occasions where a standard >>>> offset change and a savings change happen at the same time (canceling >>>> each other), resulting in no wall time transition. This means that the >>>> "rules" in the sample code is a valid ZoneRules instance. >>>> >>>> However, there is an assumption in ZoneRules where no (wall time) >>>> transition means the fixed offset zone. With that assumption, the >>>> example rule is considered a fixed offset zone which is not correct. So >>>> the fix proposed here is not to throw an IAE but to recognize the rule >>>> as a valid, non-fixed offset ZoneRules instance. >>>> >>>> Naoto >>>> >>>> From mandy.chung at oracle.com Mon Mar 9 03:56:23 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 8 Mar 2020 20:56:23 -0700 Subject: RFR: 8240629: argfiles parsing broken for argfiles with comment cross 4096 bytes chunk In-Reply-To: <90E08D89-BD84-4738-9E86-B3E817E3362C@oracle.com> References: <1768c55f6ba0722d96f2bb978c3ce3f820779cfa.camel@gmx.de> <6704dc02d2a4b8e140eb4d55cbae8204d6250fb2.camel@gmx.de> <6014206a3374bf18059488bbf4cfae4bd0e687c7.camel@gmx.de> <6DD2702D-76A9-477C-B0FA-990B498A3AE5@oracle.com> <0BFCC490-42A0-43ED-A020-981A31867623@oracle.com> <4b87ff4e-be27-ee00-655a-441e181eb6a4@oracle.com> <90E08D89-BD84-4738-9E86-B3E817E3362C@oracle.com> Message-ID: <138c770b-469b-e0c7-1083-555518394926@oracle.com> On 3/8/20 11:27 AM, Henry Jen wrote: > Thanks for the review, I updated the webrev[1] with simplified test and ensure other cases in boundary won?t be causing trouble by only take meaningful tokens. > > This fix is more defensive and allow anchor to be ignored when it?s meaningless. > > [1] http://cr.openjdk.java.net/~henryjen/jdk/8240629.1/webrev/ This patch looks okay. Mandy From scolebourne at joda.org Mon Mar 9 08:44:54 2020 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 9 Mar 2020 08:44:54 +0000 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: <5fd1e013-e516-05d6-bf35-dbf29d572a42@oracle.com> References: <030ee6e9-34dd-5c83-f942-96f07161aaca@oracle.com> <5fd1e013-e516-05d6-bf35-dbf29d572a42@oracle.com> Message-ID: Fine by me, but I'm not an OpenJDK Reviewer Stephen On Mon, 9 Mar 2020 at 03:05, wrote: > > Thanks, Stephen. > > Updated the webrev for those two suggestions: > > http://cr.openjdk.java.net/~naoto/8239836/webrev.04/ > > Naoto > > On 3/8/20 4:22 PM, Stephen Colebourne wrote: > > standardOffsets[0] == wallOffsets[0] needs to use .equals() > > > > Unrelated, there is a Javadoc/spec error at line 578 of the "new" > > file. It should be getValidOffsets, not getOffset. > > > > Apart from that, it looks good. > > > > thanks > > Stephen > > > > > > On Wed, 4 Mar 2020 at 19:06, wrote: > >> > >> Hi Stephen, > >> > >> Thank you for the detailed explanation and correcting the > >> implementation. I incorporated all the suggestions below, as well as > >> adding a new test for isFixedOffset() implementation (with some clean-up): > >> > >> https://cr.openjdk.java.net/~naoto/8239836/webrev.03/ > >> > >> Please take a look at it. > >> > >> Naoto > >> > >> On 3/3/20 3:30 PM, Stephen Colebourne wrote: > >>> I fear more changes are needed here. > >>> > >>> 1) The code is isFixedOffset() is indeed wrong, but the fix is > >>> insufficient. The zone is fixed if baseStandardOffset=baseWallOffset > >>> and all three other lists are empty. A fixed offset rule is the > >>> equivalent of a ZoneOffset. See ZoneId.normalized() for the code that > >>> assumes that. > >>> > >>> 2) The code in getOffset(Instant) is wrong, but so is the proposed > >>> fix. The purpose of the if statement is to optimise the following few > >>> lines which refer to savingsInstantTransitions and wallOffsets. The > >>> code does have a bug as it should return the first wall offset. > >>> Corrected code: > >>> public ZoneOffset getOffset(Instant instant) { > >>> if (savingsInstantTransitions.length == 0) { > >>> return wallOffsets[0]; > >>> } > >>> With the correct definition of isFixedOffset() it becomes apparent > >>> that this if statement is in fact not related to the fixed offset. > >>> > >>> Currently this test case fails (a zone in DST for all eternity): > >>> ZoneRules rules = ZoneRules.of( > >>> ZoneOffset.ofHours(1), > >>> ZoneOffset.ofHours(2), > >>> Collections.emptyList(), > >>> Collections.emptyList(), > >>> Collections.emptyList()); > >>> assertEquals(rules.getStandardOffset(Instant.EPOCH), > >>> ZoneOffset.ofHours(1)); > >>> assertEquals(rules.getOffset(Instant.EPOCH), ZoneOffset.ofHours(2)); > >>> > >>> 3) The code in getStandardOffset(Instant) also has an error as it > >>> checks the wrong array. It should check standardTransitions as that is > >>> what is used in the following few lines. Corrected code: > >>> public ZoneOffset getStandardOffset(Instant instant) { > >>> if (standardTransitions.length == 0) { > >>> return standardOffsets[0]; > >>> } > >>> > >>> 4) The code in getOffsetInfo(LocalDateTime dt) has a similar fault. > >>> Since it protects savingsLocalTransitions, it should return > >>> wallOffsets[0]. > >>> > >>> 5) The code in getDaylightSavings(Instant instant) has an optimising > >>> if statement that should refer to isFixedOffset(). > >>> > >>> 6) Also, in the test. > >>> assertTrue(!rules.isFixedOffset()); > >>> should be > >>> assertFalse(rules.isFixedOffset()); > >>> > >>> The class has worked so far as every normal case has > >>> baseStandardOffset = baseWallOffset, even though it is conceptually > >>> valid for this not to be true. > >>> > >>> Stephen > >>> > >>> > >>> > >>> > >>> On Thu, 27 Feb 2020 at 20:42, wrote: > >>>> > >>>> Hello, > >>>> > >>>> Please review the fix to the following issue: > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8239836 > >>>> > >>>> The proposed changeset is located at: > >>>> > >>>> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ > >>>> > >>>> It turned out that 'transitionList' is not necessarily a superset of > >>>> 'standardOffsetTransitionList', as in some occasions where a standard > >>>> offset change and a savings change happen at the same time (canceling > >>>> each other), resulting in no wall time transition. This means that the > >>>> "rules" in the sample code is a valid ZoneRules instance. > >>>> > >>>> However, there is an assumption in ZoneRules where no (wall time) > >>>> transition means the fixed offset zone. With that assumption, the > >>>> example rule is considered a fixed offset zone which is not correct. So > >>>> the fix proposed here is not to throw an IAE but to recognize the rule > >>>> as a valid, non-fixed offset ZoneRules instance. > >>>> > >>>> Naoto > >>>> > >>>> From suenaga at oss.nttdata.com Mon Mar 9 10:50:05 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 9 Mar 2020 19:50:05 +0900 Subject: RFR: 8240725: Some functions might not work with CJK character Message-ID: Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8240725 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.00/ We found the issue that HotSpot does not start when it is deployed on the path which contains CJK character(s), and it has been fixed in JDK-8240197. On the review of JDK-8240197 [1], we concern similar issue might occur in other place, and I found potentially problem in below: - ZFILE_Open() @ zip_util.c - JDK_Canonicalize() @ canonicalize_md.c (for Windows) - create_unc_path() @ java_md.c (for Windows) - Platform::MultibyteStringToWideString() @ WindowsPlatform.cpp This change passed tests on submit repo (mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139). Thanks, Yasumasa [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html From Roger.Riggs at oracle.com Mon Mar 9 14:01:02 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 9 Mar 2020 10:01:02 -0400 Subject: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: <678539ae-a275-6280-4508-cb4dfffd9b2c@oracle.com> References: <4c366dd4-5d10-b218-b30d-c59d5aa72c35@oracle.com> <678539ae-a275-6280-4508-cb4dfffd9b2c@oracle.com> Message-ID: <4282b1ba-2995-0562-5328-7d82fd048672@oracle.com> Hi, Updating the spec to match the implementation is a good idea. Whether adding a new method is worthwhile depends on whether *any* non-conforming UUID has been actually been seen.? Humans don't type UUID's so if there are non-conforming ones out there, they have been generated by some other framework or library. Thanks, Roger On 3/8/20 9:53 AM, Alan Bateman wrote: > On 06/03/2020 18:15, Roger Riggs wrote: >> Hi Chihiro, et.al., >> >> Thanks for taking a look at this issue,? however... >> >> There has been a long history of concerns[1] about breaking existing >> applications >> that depend on the loose parsing of UUIDs.? Throwing an exception >> where it did not >> previously is an incompatible change. >> >> The crucial concern about performance parsing conforming strings has >> been addressed by: >> >> 8196334 Optimize UUID#fromString >> >> >> I propose to close these as WILL-NOT-FIX: and hope that the next >> several times it gets reported >> they will be closed as duplicates. >> >> 8216407 >> java.util.UUID.fromString accepts input that does not match expected >> format >> >> 8165199 >> UUID.fromString >> accepts wrong placements of the dashes > As you say, any tightening up of the validation after 15+ years will > create a potential compatibility issue and might not be worth it. > Maybe we could re-purpose JDK-8216407 to clarifying the javadoc > instead? That would at least help with these bug reports when people > are surprise that fromString doesn't fail. > > -Alan From huizhe.wang at oracle.com Mon Mar 9 16:05:46 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 9 Mar 2020 09:05:46 -0700 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: References: <030ee6e9-34dd-5c83-f942-96f07161aaca@oracle.com> <5fd1e013-e516-05d6-bf35-dbf29d572a42@oracle.com> Message-ID: The changes look good to me. Best, Joe On 3/9/20 1:44 AM, Stephen Colebourne wrote: > Fine by me, but I'm not an OpenJDK Reviewer > Stephen > > On Mon, 9 Mar 2020 at 03:05, wrote: >> Thanks, Stephen. >> >> Updated the webrev for those two suggestions: >> >> http://cr.openjdk.java.net/~naoto/8239836/webrev.04/ >> >> Naoto >> >> On 3/8/20 4:22 PM, Stephen Colebourne wrote: >>> standardOffsets[0] == wallOffsets[0] needs to use .equals() >>> >>> Unrelated, there is a Javadoc/spec error at line 578 of the "new" >>> file. It should be getValidOffsets, not getOffset. >>> >>> Apart from that, it looks good. >>> >>> thanks >>> Stephen >>> >>> >>> On Wed, 4 Mar 2020 at 19:06, wrote: >>>> Hi Stephen, >>>> >>>> Thank you for the detailed explanation and correcting the >>>> implementation. I incorporated all the suggestions below, as well as >>>> adding a new test for isFixedOffset() implementation (with some clean-up): >>>> >>>> https://cr.openjdk.java.net/~naoto/8239836/webrev.03/ >>>> >>>> Please take a look at it. >>>> >>>> Naoto >>>> >>>> On 3/3/20 3:30 PM, Stephen Colebourne wrote: >>>>> I fear more changes are needed here. >>>>> >>>>> 1) The code is isFixedOffset() is indeed wrong, but the fix is >>>>> insufficient. The zone is fixed if baseStandardOffset=baseWallOffset >>>>> and all three other lists are empty. A fixed offset rule is the >>>>> equivalent of a ZoneOffset. See ZoneId.normalized() for the code that >>>>> assumes that. >>>>> >>>>> 2) The code in getOffset(Instant) is wrong, but so is the proposed >>>>> fix. The purpose of the if statement is to optimise the following few >>>>> lines which refer to savingsInstantTransitions and wallOffsets. The >>>>> code does have a bug as it should return the first wall offset. >>>>> Corrected code: >>>>> public ZoneOffset getOffset(Instant instant) { >>>>> if (savingsInstantTransitions.length == 0) { >>>>> return wallOffsets[0]; >>>>> } >>>>> With the correct definition of isFixedOffset() it becomes apparent >>>>> that this if statement is in fact not related to the fixed offset. >>>>> >>>>> Currently this test case fails (a zone in DST for all eternity): >>>>> ZoneRules rules = ZoneRules.of( >>>>> ZoneOffset.ofHours(1), >>>>> ZoneOffset.ofHours(2), >>>>> Collections.emptyList(), >>>>> Collections.emptyList(), >>>>> Collections.emptyList()); >>>>> assertEquals(rules.getStandardOffset(Instant.EPOCH), >>>>> ZoneOffset.ofHours(1)); >>>>> assertEquals(rules.getOffset(Instant.EPOCH), ZoneOffset.ofHours(2)); >>>>> >>>>> 3) The code in getStandardOffset(Instant) also has an error as it >>>>> checks the wrong array. It should check standardTransitions as that is >>>>> what is used in the following few lines. Corrected code: >>>>> public ZoneOffset getStandardOffset(Instant instant) { >>>>> if (standardTransitions.length == 0) { >>>>> return standardOffsets[0]; >>>>> } >>>>> >>>>> 4) The code in getOffsetInfo(LocalDateTime dt) has a similar fault. >>>>> Since it protects savingsLocalTransitions, it should return >>>>> wallOffsets[0]. >>>>> >>>>> 5) The code in getDaylightSavings(Instant instant) has an optimising >>>>> if statement that should refer to isFixedOffset(). >>>>> >>>>> 6) Also, in the test. >>>>> assertTrue(!rules.isFixedOffset()); >>>>> should be >>>>> assertFalse(rules.isFixedOffset()); >>>>> >>>>> The class has worked so far as every normal case has >>>>> baseStandardOffset = baseWallOffset, even though it is conceptually >>>>> valid for this not to be true. >>>>> >>>>> Stephen >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, 27 Feb 2020 at 20:42, wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the fix to the following issue: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8239836 >>>>>> >>>>>> The proposed changeset is located at: >>>>>> >>>>>> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ >>>>>> >>>>>> It turned out that 'transitionList' is not necessarily a superset of >>>>>> 'standardOffsetTransitionList', as in some occasions where a standard >>>>>> offset change and a savings change happen at the same time (canceling >>>>>> each other), resulting in no wall time transition. This means that the >>>>>> "rules" in the sample code is a valid ZoneRules instance. >>>>>> >>>>>> However, there is an assumption in ZoneRules where no (wall time) >>>>>> transition means the fixed offset zone. With that assumption, the >>>>>> example rule is considered a fixed offset zone which is not correct. So >>>>>> the fix proposed here is not to throw an IAE but to recognize the rule >>>>>> as a valid, non-fixed offset ZoneRules instance. >>>>>> >>>>>> Naoto >>>>>> >>>>>> From mandy.chung at oracle.com Mon Mar 9 16:37:10 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Mar 2020 09:37:10 -0700 Subject: JDK14 spec query : MethodHandles:dropLookupMode(int) In-Reply-To: References: Message-ID: <0168f9ad-6968-185e-50e5-ffe609a6be32@oracle.com> I have bcc'ed jdk-dev and add core-libs-dev mailing list where this thread should be discussed. The spec says: "When dropping|PACKAGE|then the resulting lookup will not have|PACKAGE|or|PRIVATE|access.When dropping|MODULE|then the resulting lookup will not have|MODULE|,|PACKAGE|, or|PRIVATE|access. If|PUBLIC|is dropped then the resulting lookup has no access." @throws IAE if modeToDrop is a valid mode. I found the spec is quite clear that there is no condition to require the modeToDrop must exist. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8226916 On 3/9/20 3:06 AM, Andrew Leonard wrote: > Thank you Mandy for raising the bug, I have one more query please, we > may want to add to the bug that I am not sure about: > *testDropLookupMode*() in > test/jdk/java/lang/invoke/modules/m3/jdk/test/ModuleAccessTest.java: > > ?public void testDropLookupMode() throws Exception { > ? ? ? ?Lookup lookup = MethodHandles.privateLookupIn(m5.type1, m4.lookup); > ? ? ? ?assertTrue((lookup.lookupModes() & MODULE) == 0); <--- MODULE > doesn't exist > ? ? ? ?... > ? ? ? ?Lookup lookup3 = lookup.dropLookupMode(MODULE); > ---> assertTrue(lookup3.lookupModes() == (lookup.lookupModes() & > ~(PROTECTED|PRIVATE|PACKAGE))); > > > Based on the expected result above, does it mean PRIVATE, PACKAGE > should be dropped whether > or not MODULE exists in the access mode (PROTECTED is dropped by > default) ? > If so, the document should be updated to explicitly clarify the > exception case? > > Thanks, > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From naoto.sato at oracle.com Mon Mar 9 17:24:01 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 9 Mar 2020 10:24:01 -0700 Subject: RFR: 8240725: Some functions might not work with CJK character In-Reply-To: References: Message-ID: <1bbe9067-b3f6-9b4a-774d-313d4cb6fab4@oracle.com> Hi Suenaga-san, I think the return value from the second MultiByteToWideChar invocation should be examined (non-zero), and if it was not successful, appropriate action should be taken. Naoto On 3/9/20 3:50 AM, Yasumasa Suenaga wrote: > Hi all, > > Please review this change: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8240725 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.00/ > > We found the issue that HotSpot does not start when it is deployed on > the path which contains CJK character(s), and it has been fixed in > JDK-8240197. > > On the review of JDK-8240197 [1], we concern similar issue might occur > in other place, and I found potentially problem in below: > > - ZFILE_Open() @ zip_util.c > - JDK_Canonicalize() @ canonicalize_md.c (for Windows) > - create_unc_path() @ java_md.c (for Windows) > - Platform::MultibyteStringToWideString() @ WindowsPlatform.cpp > > This change passed tests on submit repo > (mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139). > > > Thanks, > > Yasumasa > > > [1] > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html > From takiguc at linux.vnet.ibm.com Mon Mar 9 17:37:49 2020 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 10 Mar 2020 02:37:49 +0900 Subject: RFR 8232161: Align some one-way conversion in MS950 charset with Windows In-Reply-To: <7173239a-e06c-5c9e-7c54-5fe373aa0b41@oracle.com> References: <29c29ad7-a953-97a3-11eb-87ab612a323f@oracle.com> <7173239a-e06c-5c9e-7c54-5fe373aa0b41@oracle.com> Message-ID: <331363c7e1efadd3049e5090cf2a3d49@linux.vnet.ibm.com> Hello Naoto. I appreciate your comments. I modified TestMS950.java testcase. I think it's easy to read. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8232161 Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.03/ Thanks, Ichiroh Takiguchi On 2020-03-05 04:31, naoto.sato at oracle.com wrote: > On 3/4/20 9:18 AM, Ichiroh Takiguchi wrote: >> Hello Naoto. >> >> I appreciate your comments. >> >> I applied following changes: >> * MS950.nr and TestMS950.java data were sorted by Unicode order >> * Added some comments into TestMS950.java >> * Change comment on MS950.map >> >> Could you review the fix ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161 >> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.02/ > > I'd expect the sort order to be aligned with other *.nr files, i.e., > sorted by the source byte sequence. Same for the test case > (TestMS950.java) and the comment in MS950.map. > > As to the test comment, how about adding something below to @summary > line? > > "Those test data confirm the preferred b2c irreversible mappings > defined in MS950.nr file." > > Naoto > >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2020-03-03 10:31, naoto.sato at oracle.com wrote: >>> Hi Takiguchi-san, >>> >>> A few comments: >>> >>> - I'd recommend sorting the entries in MS950.nr and test data in >>> TestMS950.java for readability. >>> >>> - Add some comment about the objective in the test. It'd be hard for >>> engineers who have no previous knowledge to these bytes. >>> >>> Naoto >>> >>> >>> >>> On 3/2/20 9:33 AM, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> Could you review the fix ? >>>> >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.01/ >>>> >>>> CSR 8233385 [1] was approved. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233385 >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. From chris.hegarty at oracle.com Mon Mar 9 17:45:06 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 9 Mar 2020 17:45:06 +0000 Subject: JDK14 spec query : MethodHandles:dropLookupMode(int) In-Reply-To: <0168f9ad-6968-185e-50e5-ffe609a6be32@oracle.com> References: <0168f9ad-6968-185e-50e5-ffe609a6be32@oracle.com> Message-ID: <455B9B4C-7E81-4745-9E78-7E38E905EBAA@oracle.com> Mandy, > On 9 Mar 2020, at 16:37, Mandy Chung wrote: > > I have bcc'ed jdk-dev and add core-libs-dev mailing list where this thread should be discussed. > > The spec says: > > "When dropping PACKAGE then the resulting lookup will not have PACKAGE or PRIVATE access. When dropping MODULE then the resulting lookup will not have MODULE, PACKAGE, or PRIVATE access. If PUBLIC is dropped then the resulting lookup has no access." > > @throws IAE if modeToDrop is a valid mode. > > I found the spec is quite clear that there is no condition to require the modeToDrop must exist. Sure, I guess it somewhat depends on how you see 8240242 [1] turning out. 8240242 clearly describes a similar(ish) issue where dropping PUBLIC, when it is not currently held, has no effect, i.e. it does not result in ?no access? - this is either a bug in the implementation, or a bug/clarification in the spec. If the latter, then there are some scenarios where the outcome of passing a mode to dropLookupMode will have some dependency on the actual held modes. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8240242 From naoto.sato at oracle.com Mon Mar 9 17:49:10 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 9 Mar 2020 10:49:10 -0700 Subject: RFR 8232161: Align some one-way conversion in MS950 charset with Windows In-Reply-To: <331363c7e1efadd3049e5090cf2a3d49@linux.vnet.ibm.com> References: <29c29ad7-a953-97a3-11eb-87ab612a323f@oracle.com> <7173239a-e06c-5c9e-7c54-5fe373aa0b41@oracle.com> <331363c7e1efadd3049e5090cf2a3d49@linux.vnet.ibm.com> Message-ID: <3036fd70-14a2-c922-c6ee-3c2b58a43bcb@oracle.com> Looks good to me. Thanks for the update. Naoto On 3/9/20 10:37 AM, Ichiroh Takiguchi wrote: > Hello Naoto. > > I appreciate your comments. > I modified TestMS950.java testcase. > I think it's easy to read. > > Could you review the fix again ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161 > Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.03/ > > Thanks, > Ichiroh Takiguchi > > On 2020-03-05 04:31, naoto.sato at oracle.com wrote: >> On 3/4/20 9:18 AM, Ichiroh Takiguchi wrote: >>> Hello Naoto. >>> >>> I appreciate your comments. >>> >>> I applied following changes: >>> * MS950.nr and TestMS950.java data were sorted by Unicode order >>> * Added some comments into TestMS950.java >>> * Change comment on MS950.map >>> >>> Could you review the fix ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.02/ >> >> I'd expect the sort order to be aligned with other *.nr files, i.e., >> sorted by the source byte sequence. Same for the test case >> (TestMS950.java) and the comment in MS950.map. >> >> As to the test comment, how about adding something below to @summary >> line? >> >> "Those test data confirm the preferred b2c irreversible mappings >> defined in MS950.nr file." >> >> Naoto >> >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2020-03-03 10:31, naoto.sato at oracle.com wrote: >>>> Hi Takiguchi-san, >>>> >>>> A few comments: >>>> >>>> - I'd recommend sorting the entries in MS950.nr and test data in >>>> TestMS950.java for readability. >>>> >>>> - Add some comment about the objective in the test. It'd be hard for >>>> engineers who have no previous knowledge to these bytes. >>>> >>>> Naoto >>>> >>>> >>>> >>>> On 3/2/20 9:33 AM, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> >>>>> Could you review the fix ? >>>>> >>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.01/ >>>>> >>>>> CSR 8233385 [1] was approved. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233385 >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. From mandy.chung at oracle.com Mon Mar 9 18:55:37 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Mar 2020 11:55:37 -0700 Subject: JDK14 spec query : MethodHandles:dropLookupMode(int) In-Reply-To: <455B9B4C-7E81-4745-9E78-7E38E905EBAA@oracle.com> References: <0168f9ad-6968-185e-50e5-ffe609a6be32@oracle.com> <455B9B4C-7E81-4745-9E78-7E38E905EBAA@oracle.com> Message-ID: On 3/9/20 10:45 AM, Chris Hegarty wrote: > Sure, I guess it somewhat depends on how you see 8240242 [1] turning > out. 8240242 clearly describes a similar(ish) issue where dropping > PUBLIC, when it is not currently held, has no effect, i.e. it does not > result in ?no access? - this is either a bug in the implementation, or > a bug/clarification in the spec. If the latter, then there are some > scenarios where the outcome of passing a mode to dropLookupMode will > have some dependency on the actual held modes. The confusion here is the public lookup with UNCONDITIONAL mode. In JDK 9, a public lookup has PUBLIC and UNCONDITIONAL modes set whereas in 14 JDK-8226916 revises public lookup objects with only UNCONDITIONAL bit set. Here is the spec clarification I am thinking of that may explain why the focus is not whether MODULE bit is set or not. @@ -1524,14 +1524,20 @@ ????????? * Creates a lookup on the same lookup class which this lookup object ????????? * finds members, but with a lookup mode that has lost the given lookup mode. ????????? * The lookup mode to drop is one of {@link #PUBLIC PUBLIC}, {@link #MODULE -???????? * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED} or {@link #PRIVATE PRIVATE}. -???????? * {@link #PROTECTED PROTECTED} is always -???????? * dropped and so the resulting lookup mode will never have this access capability. -???????? * When dropping {@code PACKAGE} then the resulting lookup will not have {@code PACKAGE} -???????? * or {@code PRIVATE} access. When dropping {@code MODULE} then the resulting lookup will -???????? * not have {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. If {@code PUBLIC} -???????? * is dropped then the resulting lookup has no access. If {@code UNCONDITIONAL} -???????? * is dropped then the resulting lookup has no access. +???????? * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED}, +???????? * {@link #PRIVATE PRIVATE}, or {@code UNCONDITIONAL}. +???????? * If this lookup has at least {@code PUBLIC} mode then +???????? * {@link #PROTECTED PROTECTED} is always dropped and so the resulting lookup +???????? * mode will never have this access capability.? When dropping {@code PACKAGE} +???????? * then the resulting lookup will not have {@code PACKAGE} or {@code PRIVATE} access. +???????? * When dropping {@code MODULE} then the resulting lookup will not have +???????? * {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. +???????? * When dropping {@code PUBLIC} then the result lookup has no access. +???????? * +???????? *

If this lookup has {@code UNCONDITIONAL} mode, this lookup is a +???????? * {@linkplain MethodHandles#publicLookup() public lookup} and it has no +???????? * other mode set.? When dropping {@code UNCONDITIONAL} on a public lookup +???????? * then the resulting lookup has has no access. ????????? * Is this clearer? Mandy From Roger.Riggs at oracle.com Mon Mar 9 20:06:46 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 9 Mar 2020 16:06:46 -0400 Subject: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity In-Reply-To: References: <030ee6e9-34dd-5c83-f942-96f07161aaca@oracle.com> <5fd1e013-e516-05d6-bf35-dbf29d572a42@oracle.com> Message-ID: <0957507c-2aba-7536-c6e2-9182d5b6c367@oracle.com> +1 On 3/9/20 12:05 PM, Joe Wang wrote: > The changes look good to me. > > Best, > Joe > > On 3/9/20 1:44 AM, Stephen Colebourne wrote: >> Fine by me, but I'm not an OpenJDK Reviewer >> Stephen >> >> On Mon, 9 Mar 2020 at 03:05, wrote: >>> Thanks, Stephen. >>> >>> Updated the webrev for those two suggestions: >>> >>> http://cr.openjdk.java.net/~naoto/8239836/webrev.04/ >>> >>> Naoto >>> >>> On 3/8/20 4:22 PM, Stephen Colebourne wrote: >>>> ?? standardOffsets[0] == wallOffsets[0] needs to use .equals() >>>> >>>> Unrelated, there is a Javadoc/spec error at line 578 of the "new" >>>> file. It should be getValidOffsets, not getOffset. >>>> >>>> Apart from that, it looks good. >>>> >>>> thanks >>>> Stephen >>>> >>>> >>>> On Wed, 4 Mar 2020 at 19:06, wrote: >>>>> Hi Stephen, >>>>> >>>>> Thank you for the detailed explanation and correcting the >>>>> implementation. I incorporated all the suggestions below, as well as >>>>> adding a new test for isFixedOffset() implementation (with some >>>>> clean-up): >>>>> >>>>> https://cr.openjdk.java.net/~naoto/8239836/webrev.03/ >>>>> >>>>> Please take a look at it. >>>>> >>>>> Naoto >>>>> >>>>> On 3/3/20 3:30 PM, Stephen Colebourne wrote: >>>>>> I fear more changes are needed here. >>>>>> >>>>>> 1) The code is isFixedOffset() is indeed wrong, but the fix is >>>>>> insufficient. The zone is fixed if baseStandardOffset=baseWallOffset >>>>>> and all three other lists are empty. A fixed offset rule is the >>>>>> equivalent of a ZoneOffset. See ZoneId.normalized() for the code >>>>>> that >>>>>> assumes that. >>>>>> >>>>>> 2) The code in getOffset(Instant) is wrong, but so is the proposed >>>>>> fix. The purpose of the if statement is to optimise the following >>>>>> few >>>>>> lines which refer to savingsInstantTransitions and wallOffsets. The >>>>>> code does have a bug as it should return the first wall offset. >>>>>> Corrected code: >>>>>> ???? public ZoneOffset getOffset(Instant instant) { >>>>>> ?????? if (savingsInstantTransitions.length == 0) { >>>>>> ???????? return wallOffsets[0]; >>>>>> ?????? } >>>>>> With the correct definition of isFixedOffset() it becomes apparent >>>>>> that this if statement is in fact not related to the fixed offset. >>>>>> >>>>>> Currently this test case fails (a zone in DST for all eternity): >>>>>> ?????????? ZoneRules rules = ZoneRules.of( >>>>>> ?????????????????? ZoneOffset.ofHours(1), >>>>>> ?????????????????? ZoneOffset.ofHours(2), >>>>>> ?????????????????? Collections.emptyList(), >>>>>> ?????????????????? Collections.emptyList(), >>>>>> ?????????????????? Collections.emptyList()); >>>>>> assertEquals(rules.getStandardOffset(Instant.EPOCH), >>>>>> ZoneOffset.ofHours(1)); >>>>>> ?????????? assertEquals(rules.getOffset(Instant.EPOCH), >>>>>> ZoneOffset.ofHours(2)); >>>>>> >>>>>> 3) The code in getStandardOffset(Instant) also has an error as it >>>>>> checks the wrong array. It should check standardTransitions as >>>>>> that is >>>>>> what is used in the following few lines. Corrected code: >>>>>> ???? public ZoneOffset getStandardOffset(Instant instant) { >>>>>> ?????? if (standardTransitions.length == 0) { >>>>>> ???????? return standardOffsets[0]; >>>>>> ?????? } >>>>>> >>>>>> 4) The code in getOffsetInfo(LocalDateTime dt) has a similar fault. >>>>>> Since it protects savingsLocalTransitions, it should return >>>>>> wallOffsets[0]. >>>>>> >>>>>> 5) The code in getDaylightSavings(Instant instant) has an optimising >>>>>> if statement that should refer to isFixedOffset(). >>>>>> >>>>>> 6) Also, in the test. >>>>>> ??? assertTrue(!rules.isFixedOffset()); >>>>>> should be >>>>>> ??? assertFalse(rules.isFixedOffset()); >>>>>> >>>>>> The class has worked so far as every normal case has >>>>>> baseStandardOffset = baseWallOffset, even though it is conceptually >>>>>> valid for this not to be true. >>>>>> >>>>>> Stephen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, 27 Feb 2020 at 20:42, wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review the fix to the following issue: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8239836 >>>>>>> >>>>>>> The proposed changeset is located at: >>>>>>> >>>>>>> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/ >>>>>>> >>>>>>> It turned out that 'transitionList' is not necessarily a >>>>>>> superset of >>>>>>> 'standardOffsetTransitionList', as in some occasions where a >>>>>>> standard >>>>>>> offset change and a savings change happen at the same time >>>>>>> (canceling >>>>>>> each other), resulting in no wall time transition. This means >>>>>>> that the >>>>>>> "rules" in the sample code is a valid ZoneRules instance. >>>>>>> >>>>>>> However, there is an assumption in ZoneRules where no (wall time) >>>>>>> transition means the fixed offset zone. With that assumption, the >>>>>>> example rule is considered a fixed offset zone which is not >>>>>>> correct. So >>>>>>> the fix proposed here is not to throw an IAE but to recognize >>>>>>> the rule >>>>>>> as a valid, non-fixed offset ZoneRules instance. >>>>>>> >>>>>>> Naoto >>>>>>> >>>>>>> > From mandy.chung at oracle.com Mon Mar 9 21:00:57 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Mar 2020 14:00:57 -0700 Subject: CSR review for 8238358: Implementation of JEP 371: Hidden Classes Message-ID: <88406fa9-e363-d514-35c8-3c1829b9f60c@oracle.com> Please review the CSR proposed for JEP 371 Hidden Classes [1]. CSR: ? https://bugs.openjdk.java.net/browse/JDK-8238359 javadoc/specdiff: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ JVMS 5.4.4 change: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf A brief summary of the changes: 1. A new Lookup::defineHiddenClass method is the API to create a hidden class. 2. A new Lookup.ClassOption enum class defines NESTMATE and WEAK option that ?? can be specified when creating a hidden class. 3. A new Class::isHiddenClass method tests if a class is a hidden class. 4. Field::setXXX method will throw IAE on a final field of a hidden class ?? regardless of the value of the accessible flag. 5. Class::getNestMembers is updated not to throw any exception when it fails ?? to validate the nest membership.? Instead this method will return all ?? members that are listed in `NestMembers` attribute if present and ?? determined to have the same nest host as this class. We uncovered a bug in Lookup::defineClass spec throws LinkageError and intends to have the newly created class linked.? However, the implementation in 14 does not link the class.? A separate CSR proposes to update the implementation to match the spec - please also review: ?? https://bugs.openjdk.java.net/browse/JDK-8240338 This is tracked as a separate JBS issue JDK-8238195 that is fixed in this patch. The code review will be posted separately. Thanks Mandy [1] https://openjdk.java.net/jeps/371 [2] JDK-8230502 Add support in JVM TI and JDI for hidden classes [3] JDK-8219607 Add support in Graal and AOT for hidden and weak class [4] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006872.html From mandy.chung at oracle.com Mon Mar 9 23:33:23 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Mar 2020 16:33:23 -0700 Subject: Review Request JDK-8228336: Refactor native library loading implementation Message-ID: <00d2029d-ae16-6a9b-5942-cd67aba7c141@oracle.com> This patch refactors the native library loading implementation out of ClassLoader and move them to jdk.internal.loader package. This introduces a new NativeLibraries abstraction which loads and registers the loaded native libraries.? Previously it was maintained in a nativeLibrary map in each ClassLoader instance and one systemNativeLibraries for the null loader case.? With this change, each ClassLoader and BootLoader have its own NativeLibraries instead. NativeLibraries.java and NativeLibraries.c are mostly refactored from the existing code.? Only minor cleanups are applied. This refactoring enables Panama LookupLibrary to further experiment and allow loading of a native library without the restriction that a native library can only be loaded by one class loader.? The restriction is important for System::loadLibrary in loading JNI libraries that implements JNI native methods and so remain unchanged. This patch follows up the change introduced by JDK-8227587 which adds BootLoader::loadLibrary.? It should belong a helper classes instead of BootLoader and this helper method is to avoid doPrivileged call if no security manager is installed for startup performance improvement.?? Several `privilegedXXX` methods were added for the same purpose for example sun.security.action.GetPropertyAction::privilegedGetProperty and privilegedGetProperties.? So I think sun.security.action.LoadLibraryAction is a proper place. Webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8228336/webrev.00/ Thanks Mandy From maurizio.cimadamore at oracle.com Mon Mar 9 23:44:37 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 9 Mar 2020 23:44:37 +0000 Subject: Review Request JDK-8228336: Refactor native library loading implementation In-Reply-To: <00d2029d-ae16-6a9b-5942-cd67aba7c141@oracle.com> References: <00d2029d-ae16-6a9b-5942-cd67aba7c141@oracle.com> Message-ID: Thanks Mandy, this refactoring would indeed enable Panama library loading to get rid of classloader-related restriction which are JNI-based and have little to do with the way Panama does things. I'm looking forward to be able to use something like this from my side of the fence :-) Cheers Maurizio On 09/03/2020 23:33, Mandy Chung wrote: > This refactoring enables Panama LookupLibrary to further experiment > and allow loading of a native library without the restriction that a > native library can only be loaded by one class loader.? The > restriction is important for System::loadLibrary in loading JNI > libraries that implements JNI native methods and so remain unchanged. From suenaga at oss.nttdata.com Tue Mar 10 00:12:17 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 10 Mar 2020 09:12:17 +0900 Subject: RFR: 8240725: Some functions might not work with CJK character In-Reply-To: <1bbe9067-b3f6-9b4a-774d-313d4cb6fab4@oracle.com> References: <1bbe9067-b3f6-9b4a-774d-313d4cb6fab4@oracle.com> Message-ID: <3a8570ba-db32-fbbc-9292-8df41047a44d@oss.nttdata.com> Hi Sato-san, Thanks for your comment! I updated webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.01/ Yasumasa On 2020/03/10 2:24, naoto.sato at oracle.com wrote: > Hi Suenaga-san, > > I think the return value from the second MultiByteToWideChar invocation should be examined (non-zero), and if it was not successful, appropriate action should be taken. > > Naoto > > On 3/9/20 3:50 AM, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8240725 >> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.00/ >> >> We found the issue that HotSpot does not start when it is deployed on the path which contains CJK character(s), and it has been fixed in JDK-8240197. >> >> On the review of JDK-8240197 [1], we concern similar issue might occur in other place, and I found potentially problem in below: >> >> - ZFILE_Open() @ zip_util.c >> - JDK_Canonicalize() @ canonicalize_md.c (for Windows) >> - create_unc_path() @ java_md.c (for Windows) >> - Platform::MultibyteStringToWideString() @ WindowsPlatform.cpp >> >> This change passed tests on submit repo (mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139). >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html From david.holmes at oracle.com Tue Mar 10 02:41:26 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2020 12:41:26 +1000 Subject: Review Request JDK-8228336: Refactor native library loading implementation In-Reply-To: <00d2029d-ae16-6a9b-5942-cd67aba7c141@oracle.com> References: <00d2029d-ae16-6a9b-5942-cd67aba7c141@oracle.com> Message-ID: Hi Mandy, On 10/03/2020 9:33 am, Mandy Chung wrote: > This patch refactors the native library loading implementation out of > ClassLoader and move them to jdk.internal.loader package. This > introduces a new NativeLibraries abstraction which loads and registers > the loaded native libraries.? Previously it was maintained in a > nativeLibrary map in each ClassLoader instance and one > systemNativeLibraries for the null loader case.? With this change, each > ClassLoader and BootLoader have its own NativeLibraries instead. > > NativeLibraries.java and NativeLibraries.c are mostly refactored from > the existing code.? Only minor cleanups are applied. > > This refactoring enables Panama LookupLibrary to further experiment and > allow loading of a native library without the restriction that a native > library can only be loaded by one class loader.? The restriction is > important for System::loadLibrary in loading JNI libraries that > implements JNI native methods and so remain unchanged. > > This patch follows up the change introduced by JDK-8227587 which adds > BootLoader::loadLibrary.? It should belong a helper classes instead of > BootLoader and this helper method is to avoid doPrivileged call if no > security manager is installed for startup performance improvement. > Several `privilegedXXX` methods were added for the same purpose for > example sun.security.action.GetPropertyAction::privilegedGetProperty and > privilegedGetProperties.? So I think > sun.security.action.LoadLibraryAction is a proper place. That's a core-libs decision but I'm not sure that's a namespace we want to increase usage of. > Webrev: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8228336/webrev.00/ Overall refactoring looks okay to me. A couple of minor things I noticed: src/java.base/share/classes/java/lang/ClassLoader.java ! " in java.library.path: " + StaticProperty.sunBootLibraryPath()); s/java/sun.boot/ src/java.base/share/classes/java/lang/Runtime.java I don't see the point in changing load0 and loadLibrary0 to return NativeLibrary when it is unused. Is this to allow for direct use of these methods in the future? Thanks, David ----- > Thanks > Mandy From suenaga at oss.nttdata.com Tue Mar 10 02:52:15 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 10 Mar 2020 11:52:15 +0900 Subject: RFR: 8240725: Some functions might not work with CJK character In-Reply-To: <3a8570ba-db32-fbbc-9292-8df41047a44d@oss.nttdata.com> References: <1bbe9067-b3f6-9b4a-774d-313d4cb6fab4@oracle.com> <3a8570ba-db32-fbbc-9292-8df41047a44d@oss.nttdata.com> Message-ID: <30180dfd-f255-5f07-36e0-6d251d0f8c31@oss.nttdata.com> I forgot to free buffer if MultiByteToWideChar() failed in zip_util.c . So I updated webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.02/ Yasumasa On 2020/03/10 9:12, Yasumasa Suenaga wrote: > Hi Sato-san, > > Thanks for your comment! > > I updated webrev. Could you review again? > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.01/ > > > Yasumasa > > > On 2020/03/10 2:24, naoto.sato at oracle.com wrote: >> Hi Suenaga-san, >> >> I think the return value from the second MultiByteToWideChar invocation should be examined (non-zero), and if it was not successful, appropriate action should be taken. >> >> Naoto >> >> On 3/9/20 3:50 AM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change: >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8240725 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.00/ >>> >>> We found the issue that HotSpot does not start when it is deployed on the path which contains CJK character(s), and it has been fixed in JDK-8240197. >>> >>> On the review of JDK-8240197 [1], we concern similar issue might occur in other place, and I found potentially problem in below: >>> >>> - ZFILE_Open() @ zip_util.c >>> - JDK_Canonicalize() @ canonicalize_md.c (for Windows) >>> - create_unc_path() @ java_md.c (for Windows) >>> - Platform::MultibyteStringToWideString() @ WindowsPlatform.cpp >>> >>> This change passed tests on submit repo (mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139). >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html From felix.yang at huawei.com Tue Mar 10 02:54:54 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 10 Mar 2020 02:54:54 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds Message-ID: Hi, We found module-info.class in java.base.jmod is not always consistent across different builds. The ModuleHashes attribute in this module-info.class is not reproducible between builds. Patch fixes the issue by using TreeMap instead of HashMap when computing ModuleHashes. Bug: https://bugs.openjdk.java.net/browse/JDK-8240734 Webrev: http://cr.openjdk.java.net/~fyang/8240734/webrev.00/ Passed tier1 test. Please review. Thanks, Felix From ecki at zusammenkunft.net Tue Mar 10 03:47:29 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 10 Mar 2020 03:47:29 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: References: Message-ID: Hello, I wonder why there are two times the same logic in internal public static methods. Maybe that could be consolidated as well? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Yangfei (Felix) Gesendet: Tuesday, March 10, 2020 3:54:54 AM An: core-libs-dev at openjdk.java.net Betreff: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds Hi, We found module-info.class in java.base.jmod is not always consistent across different builds. The ModuleHashes attribute in this module-info.class is not reproducible between builds. Patch fixes the issue by using TreeMap instead of HashMap when computing ModuleHashes. Bug: https://bugs.openjdk.java.net/browse/JDK-8240734 Webrev: http://cr.openjdk.java.net/~fyang/8240734/webrev.00/ Passed tier1 test. Please review. Thanks, Felix From mandy.chung at oracle.com Tue Mar 10 04:53:32 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Mar 2020 21:53:32 -0700 Subject: Review Request JDK-8228336: Refactor native library loading implementation In-Reply-To: References: <00d2029d-ae16-6a9b-5942-cd67aba7c141@oracle.com> Message-ID: <1030f82a-6d7d-daa1-788f-f39848a5022b@oracle.com> Hi David, On 3/9/20 7:41 PM, David Holmes wrote: > That's a core-libs decision but I'm not sure that's a namespace we > want to increase usage of. > I'm open to other suggestion.? This helper method avoids the call to doPrivileged when security manager is enabled and I think it's okay to add this helper method in sun.security.action package. >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8228336/webrev.00/ > > Overall refactoring looks okay to me. A couple of minor things I noticed: > > src/java.base/share/classes/java/lang/ClassLoader.java > > !???????????????????? " in java.library.path: " + > StaticProperty.sunBootLibraryPath()); > s/java/sun.boot/ > Thanks for catching this. > src/java.base/share/classes/java/lang/Runtime.java > > I don't see the point in changing load0 and loadLibrary0 to return > NativeLibrary when it is unused. Is this to allow for direct use of > these methods in the future? > It was leftover from my early prototype.?? It's not intended to change.? I have fixed it. This new webrev includes the above minor fixes and a few windows/solaris specific files I missed from webrev.00: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8228336/webrev.01/index.html Thanks Mandy From david.holmes at oracle.com Tue Mar 10 06:11:16 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2020 16:11:16 +1000 Subject: Review Request JDK-8228336: Refactor native library loading implementation In-Reply-To: <1030f82a-6d7d-daa1-788f-f39848a5022b@oracle.com> References: <00d2029d-ae16-6a9b-5942-cd67aba7c141@oracle.com> <1030f82a-6d7d-daa1-788f-f39848a5022b@oracle.com> Message-ID: Hi Mandy, Updates seem fine to me. Thanks, David On 10/03/2020 2:53 pm, Mandy Chung wrote: > Hi David, > > On 3/9/20 7:41 PM, David Holmes wrote: >> That's a core-libs decision but I'm not sure that's a namespace we >> want to increase usage of. >> > > I'm open to other suggestion.? This helper method avoids the call to > doPrivileged when security manager is enabled and I think it's okay to > add this helper method in sun.security.action package. > >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8228336/webrev.00/ >> >> Overall refactoring looks okay to me. A couple of minor things I noticed: >> >> src/java.base/share/classes/java/lang/ClassLoader.java >> >> !???????????????????? " in java.library.path: " + >> StaticProperty.sunBootLibraryPath()); >> s/java/sun.boot/ >> > > Thanks for catching this. > >> src/java.base/share/classes/java/lang/Runtime.java >> >> I don't see the point in changing load0 and loadLibrary0 to return >> NativeLibrary when it is unused. Is this to allow for direct use of >> these methods in the future? >> > > It was leftover from my early prototype.?? It's not intended to change. > I have fixed it. > > This new webrev includes the above minor fixes and a few windows/solaris > specific files I missed from webrev.00: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8228336/webrev.01/index.html > > Thanks > Mandy From philipp.kunz at paratix.ch Tue Mar 10 07:11:37 2020 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Tue, 10 Mar 2020 08:11:37 +0100 Subject: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes In-Reply-To: References: <44EE1961-6729-4F96-8885-439FED393A81@oracle.com> Message-ID: <026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch> Hi Naoto and everyone, When I tried the regular expression approach you proposed which really looks delightful, ValueUtf8Coding test ran into a timeout, which is why I changed Pattern and Grapheme classes to start the loop in nextBoundary to start at the offset off rather than at the beginning of the character sequence src rendering isBoundary redundant. The changes to Pattern and Grapheme relate only by means of performance and could otherwise be applied seperately as well. I admit I'm not too confident and familiar with the regex parts of the openjdk and would welcome not only thorough review as usual but also any other feedback or thought shared about the matter. Then I started to wonder about an issue of copy paste between Grapheme and GraphemeTest already out of date and also about some comments in RegExTest and if no more matches shouldn't also be asserted, which also could possibly be changed in a different change but still relate to the actual changes to certain extent. I could not find a way to access UCD_FILES which has no or is in the default package. What about passing the name and the value parameters of Manifest.printLine72 to it as separate parameters? Because names cannot exceed 70 bytes and the allowed characters are limited to ones that are represented with one byte each in UTF-8 the name can/could always be printed without a line break. I don't know if Manifest.println72 can be removed or has to be retained and deprecated for compatibility. See attached patch. Looking forward to receiving any kind of feedback and regards,Philipp On Tue, 2020-02-11 at 14:20 -0800, naoto.sato at oracle.com wrote: > Hi, > Can the code in Manifest.java be simplified using regex? E.g., > var gc = > Pattern.compile("\\X");gc.matcher(line).results() .map(MatchResul > t::group) .forEach( // print till 72 bytes in UTF-8 ); > Just a thought. If BreakIterator is preferred, it should take > Locale.US as an argument to the factory method, so that it would > produce the same result no matter what the default locale is. > Naoto > On 2/10/20 1:22 PM, Lance Andersen wrote: > > Hi all, > > Here is a webrev for the patch that Philipp is proposing which will > > make it easier to review: > > http://cr.openjdk.java.net/~lancea/6202130/webrev.00 < > > http://cr.openjdk.java.net/~lancea/6202130/webrev.00> > > > On Dec 26, 2019, at 11:50 AM, Philipp Kunz < > > > philipp.kunz at paratix.ch> wrote: > > > Hi,The specification says, a line break in a manifest can occur > > > beforeorafter a Unicode character encoded in UTF-8. > > > > ...> value: SPACE *otherchar newline > > > *continuation> continuation: SPACE > > > *othercharnewline> ...> otherchar: any UTF-8 > > > character except NUL, CRand LFThe current implementation breaks > > > manifest lines at 72 bytes regardlessofhow the bytes around the > > > break are part of a sequence of bytesencoding acharacter. Code > > > points may use up to four bytes when encodedin UTF-8.Manifests > > > with line breaks inside of sequences of bytesencoding > > > Unicodecharacters in UTF-8 with more than one bytes not onlyare > > > invalid UTF-8but also look ugly in text editors.For example, > > > amanifest could look like this:import > > > java.util.jar.Manifest;import > > > java.util.jar.Attributes;importstatic > > > java.util.jar.Attributes.Name;public class CharacterBrokenDemo1 > > > { public static void main(String[]args) throws > > > Exception{ Manifest mf = newManifest(); Attributes > > > attrs > > > =mf.getMainAttributes(); attrs.put(Name.MANIFEST_VERSION," > > > 1.0"); attrs.put(new Name("Some- > > > Key"), "Somelanguages have decorated characters, > > > " + "forexample: espa?ol"); // > > > or"espa\u00D1ol" mf.write(System.out); }}Above code > > > produces a result as follows with some unexpected > > > questionmarkswhere the encoding is invalid: > > > > Manifest-Version: 1.0> Some-Key: Some languages have > > > > decorated > > > characters, for example: espa?> ?olThis is of course an > > > example written with actual question marks to geta validtext for > > > this message. The trick here is that "Some-Key" to"example > > > :espa"amounts to exactly one byte less encoded in UTF-8 thanwould > > > fit on one linewith the 72 byte limit so that the > > > subsequentcharacter encoded with two bytesgets broken inside of > > > the sequence oftwo bytes for this character across acontinuation > > > line break.When decoding the resulting bytes from UTF-8 as one > > > whole string, thetwoquestion marks will not fit together again > > > even if the line breakwith thecontinuation space is removed. > > > However, Manifest::read removesthe continuationline breaks ("\r\n > > > ") before decoding the manifestheader value from UTF-8 andhence > > > can reproduce the original value.Characters encoded in UTF-8 can > > > not only span up to four bytes for onecodepoint each, there are > > > also combining characters or classes thereofor > > > combiningdiacritical marks or whatever the appropriate term > > > couldbe, that combine morethan one code point into what is > > > usuallyexperienced and referred to as acharacter.The term > > > character really gets ambiguous at this point. I wouldn't > > > knowwhatthe specification actually refers to with that term > > > "character". Sorather thandiving in too much specification or any > > > sorts of theory,let's look at anotherexample:import > > > java.util.jar.Manifest;import > > > java.util.jar.Attributes;importstatic > > > java.util.jar.Attributes.Name;public class DemoCharacterBroken2 > > > { public static void main(String[]args) throws > > > Exception{ Manifest mf = newManifest(); Attributes > > > attrs > > > =mf.getMainAttributes(); attrs.put(Name.MANIFEST_VERSION," > > > 1.0"); attrs.put(new Name("Some-Key"), " ".repeat(53) > > > +"Angstro\u0308m"); mf.write(System.out); }}which > > > produces console output as follows: > > > > Manifest-Version: 1.0> Some- > > > Key: Angstro > > > >?m(In case this does not display well, the diaeresis is on the m > > > on thelast line)When the whole Manifest is decoded from UTF-8 as > > > one big single stringandcontinuation line breaks are not removed > > > until after UTF-8 decodingthe wholemanifest, the diaeresis > > > (umlaut, two points above, u0308)apparently kind ofjumps onto the > > > following letter m because somehow itcannot be combined withthe > > > preceding space. The UTF-8 decoder (all ofmy editors I tried, not > > > onlyEclipse and its console view, also less,gedit, cat and > > > terminal) somehowtries to fix that but the diaeresis maynot > > > necessarily jump back on the "o"where it originally belonged > > > byremoving the continuation line break ("\r\n ")after UTF-8 > > > decoding hastaken place, at least that did not work for me.Hence, > > > ideally combining diacritical marks should better not beseparated > > > fromwhatever they combine with when breaking manifest linesonto a > > > continuationline. Such combinations, however, seem to beunlimited > > > in terms of number ofcode points combining into the > > > same"experienced" character. I was able tofind combinations that > > > not onlyexceed the limit of 72 bytes per line but alsoexceed the > > > line buffersize of 512 bytes in Manifest::read. These may be > > > ratheruncommon butstill possible to my own surprise.Next > > > consideration would then be to remove that limit of 512 bytes > > > permanifestline but exceeding it would make such manifests > > > incompatiblewith previousManifest::read implementations and is > > > not really animmediately availableoption at the moment.As a > > > compromise, those characters including combining diacritical > > > markswhichcombine only so many code points as that their binarily > > > encodedform in UTF-8remains within a limit of 71 bytes can be > > > written withoutan interruptingcontinuation line break, which > > > applies to most cases,but not all. I guess thisshould suit > > > practically and realistically tobe expected values well.Another > > > possibility would be to allow for characters that arecombinations > > > ofmultiple Unicode code points to be kept together intheir > > > encoded form in UTF-8up to 512 bytes line length limit > > > whenreading minus a space and a line breakamounting to 509 bytes, > > > but thatwould still not make manifests be representedas valid > > > Unicode in allcorner cases and I guess would not probably make a > > > realimprovement inpractice over a limit of 71 bytes.Attached is a > > > patch that tries to implement what was described aboveusing > > > aBreakIterator. While it works from a functional point of > > > view,this might beless desirable performance-wise. Alternatively > > > could beconsidered to do withoutthe BreakIterator and only keep > > > Unicode codepoints together by not placingline breaks before a > > > continuation byte,which however would not addresscombining > > > diacritical marks as in thesecond example above.The jar file > > > specification does not explicitly state that manifestshould > > > bevalid UTF-8, and they were not always, but it also does > > > notstate otherwise,leaving an impression that manifests could > > > be(mis)taken for UTF-8 encodedstrings, which they also are in > > > many ormost cases and which has been confusedmany times. At the > > > moment, theonly case where a valid manifest is not also avalid > > > UTF-8 encodedstring is when a sequence of bytes encoding the > > > samecharacter happensto be interrupted with a continuation line > > > break. To the bestof myknowledge, all other valid manifests are > > > also valid UTF-8 encodedstrings.It would be nice, if manifests > > > could be viewed and manipulated with allUnicodecapable editors > > > and not only be parsed correctly withManifest::read.Any opinions? > > > Would someone sponsor this patch?Regards,Philipp > > > https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#specificationhttps://bugs.openjdk.java.net/browse/JDK-6202130https://bugs.openjdk.java.net/browse/JDK-6443578https://github.com/gradle/gradle/issues/5225https://bugs.openjdk.java.net/browse/JDK-8202525https://en.wikipedia.org/wiki/Combining_character > > > > > > <6202130-manifestutf8linebreak.patch> > > > > < > > http://oracle.com/us/design/oracle-email-sig-198324.gif> < > > http://oracle.com/us/design/oracle-email-sig-198324.gif> < > > http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance > > Andersen| Principal Member of Technical Staff | +1.781.442.2037Oracle Java Engineering1 Network DriveBurlington, MA 01803Lance.Andersen at oracle.com > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 20200310-bug6202130-manifestutf8-nextboundaryoffset.patch Type: text/x-patch Size: 79777 bytes Desc: not available URL: From Alan.Bateman at oracle.com Tue Mar 10 07:52:36 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Mar 2020 07:52:36 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: References: Message-ID: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> On 10/03/2020 02:54, Yangfei (Felix) wrote: > Hi, > > We found module-info.class in java.base.jmod is not always consistent across different builds. > The ModuleHashes attribute in this module-info.class is not reproducible between builds. > Patch fixes the issue by using TreeMap instead of HashMap when computing ModuleHashes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8240734 > Webrev: http://cr.openjdk.java.net/~fyang/8240734/webrev.00/ > This looks okay (and to Bernd question, this is used at link time). I think we need to extend the test coverage for reproducible builds, the existing JLinkReproducibleTest.java would ideally have caught the difference due to the random ordering of hashes. -Alan. From chris.hegarty at oracle.com Tue Mar 10 11:28:00 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 10 Mar 2020 11:28:00 +0000 Subject: JDK14 spec query : MethodHandles:dropLookupMode(int) In-Reply-To: References: <0168f9ad-6968-185e-50e5-ffe609a6be32@oracle.com> <455B9B4C-7E81-4745-9E78-7E38E905EBAA@oracle.com> Message-ID: Mandy, > On 9 Mar 2020, at 18:55, Mandy Chung wrote: > > ... > > Here is the spec clarification I am thinking of that may explain why the focus is not whether MODULE bit is set or not. > > @@ -1524,14 +1524,20 @@ > * Creates a lookup on the same lookup class which this lookup object > * finds members, but with a lookup mode that has lost the given lookup mode. > * The lookup mode to drop is one of {@link #PUBLIC PUBLIC}, {@link #MODULE > - * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED} or {@link #PRIVATE PRIVATE}. > - * {@link #PROTECTED PROTECTED} is always > - * dropped and so the resulting lookup mode will never have this access capability. > - * When dropping {@code PACKAGE} then the resulting lookup will not have {@code PACKAGE} > - * or {@code PRIVATE} access. When dropping {@code MODULE} then the resulting lookup will > - * not have {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. If {@code PUBLIC} > - * is dropped then the resulting lookup has no access. If {@code UNCONDITIONAL} > - * is dropped then the resulting lookup has no access. > + * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED}, > + * {@link #PRIVATE PRIVATE}, or {@code UNCONDITIONAL}. All six lookup modes are enumerated. Good. > + * If this lookup has at least {@code PUBLIC} mode then > + * {@link #PROTECTED PROTECTED} is always dropped and so the resulting lookup > + * mode will never have this access capability. When dropping {@code PACKAGE} > + * then the resulting lookup will not have {@code PACKAGE} or {@code PRIVATE} access. > + * When dropping {@code MODULE} then the resulting lookup will not have > + * {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. > + * When dropping {@code PUBLIC} then the result lookup has no access. I?m afraid this is still a little confusing to me ( but that could be just me! ). > + *

If this lookup has {@code UNCONDITIONAL} mode, this lookup is a > + * {@linkplain MethodHandles#publicLookup() public lookup} and it has no > + * other mode set. When dropping {@code UNCONDITIONAL} on a public lookup > + * then the resulting lookup has has no access. The public lookup scenario is very clear. Just an idea; now that you have this new UNCONDITIONAL paragraph, it could be simpler to reorder things a little to build upon it. For example: /** * Creates a lookup on the same lookup class which this lookup object * finds members, but with a lookup mode that has lost the given lookup mode. * The lookup mode to drop is one of {@link #PUBLIC PUBLIC}, {@link #MODULE * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED}, * {@link #PRIVATE PRIVATE}, or {@code UNCONDITIONAL}. * *

If this lookup has {@code UNCONDITIONAL} mode, this lookup is a * {@linkplain MethodHandles#publicLookup() public lookup} and it has no * other mode set. When dropping {@code UNCONDITIONAL} on a public lookup * then the resulting lookup has has no access. * *

If this lookup is not a public lookup, then the following * applies regardless of the actual lookup modes held. * The {@link #PROTECTED PROTECTED} mode is always dropped and so the resulting lookup * mode will never have this access capability. When dropping {@code PACKAGE} * then the resulting lookup will not have {@code PACKAGE} or {@code PRIVATE} access. * When dropping {@code MODULE} then the resulting lookup will not have * {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. * When dropping {@code PUBLIC} then the result lookup has no access. * ... -Chris. From martinrb at google.com Tue Mar 10 15:10:33 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Mar 2020 08:10:33 -0700 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> References: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> Message-ID: Aside: if all you want to do is make a use of HashMap more reproducible, the standard reaction is s/HashMap/LinkedHashMap/g On Tue, Mar 10, 2020 at 12:53 AM Alan Bateman wrote: > On 10/03/2020 02:54, Yangfei (Felix) wrote: > > Hi, > > > > We found module-info.class in java.base.jmod is not always consistent > across different builds. > > The ModuleHashes attribute in this module-info.class is not > reproducible between builds. > > Patch fixes the issue by using TreeMap instead of HashMap when > computing ModuleHashes. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8240734 > > Webrev: http://cr.openjdk.java.net/~fyang/8240734/webrev.00/ > > > This looks okay (and to Bernd question, this is used at link time). I > think we need to extend the test coverage for reproducible builds, the > existing JLinkReproducibleTest.java would ideally have caught the > difference due to the random ordering of hashes. > > -Alan. > > From naoto.sato at oracle.com Tue Mar 10 17:08:13 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 10 Mar 2020 10:08:13 -0700 Subject: RFR: 8240725: Some functions might not work with CJK character In-Reply-To: <30180dfd-f255-5f07-36e0-6d251d0f8c31@oss.nttdata.com> References: <1bbe9067-b3f6-9b4a-774d-313d4cb6fab4@oracle.com> <3a8570ba-db32-fbbc-9292-8df41047a44d@oss.nttdata.com> <30180dfd-f255-5f07-36e0-6d251d0f8c31@oss.nttdata.com> Message-ID: Hi Suenaga-san, Thank you for the update. I think your changes to the return values of MultiByteToWideChar look good. Then I noticed (should have noticed in the first place, sorry) that the error handling in canonicalize_md.c is incorrect (unrelated to your change). All error cases "goto finish" which would end up "free(NULL)" in some cases, e.g., line 340 (in the new file) should not end up calling "free(wresult)" and "free(wpath)" java_md.c - "convert_to_unicode()" has different indentation than others (2 spaces which should be 4). - Should "wpath" be set to NULL before returning EINVAL at line 524? I don't know the contract of "create_unc_path", but the caller would receive a garbage pointer as a return value. Nit: please add "noreg-hard" tag to the JIRA issue. Naoto On 3/9/20 7:52 PM, Yasumasa Suenaga wrote: > I forgot to free buffer if MultiByteToWideChar() failed in zip_util.c . > So I updated webrev: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.02/ > > > Yasumasa > > > On 2020/03/10 9:12, Yasumasa Suenaga wrote: >> Hi Sato-san, >> >> Thanks for your comment! >> >> I updated webrev. Could you review again? >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.01/ >> >> >> Yasumasa >> >> >> On 2020/03/10 2:24, naoto.sato at oracle.com wrote: >>> Hi Suenaga-san, >>> >>> I think the return value from the second MultiByteToWideChar >>> invocation should be examined (non-zero), and if it was not >>> successful, appropriate action should be taken. >>> >>> Naoto >>> >>> On 3/9/20 3:50 AM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this change: >>>> >>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8240725 >>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.00/ >>>> >>>> We found the issue that HotSpot does not start when it is deployed >>>> on the path which contains CJK character(s), and it has been fixed >>>> in JDK-8240197. >>>> >>>> On the review of JDK-8240197 [1], we concern similar issue might >>>> occur in other place, and I found potentially problem in below: >>>> >>>> - ZFILE_Open() @ zip_util.c >>>> - JDK_Canonicalize() @ canonicalize_md.c (for Windows) >>>> - create_unc_path() @ java_md.c (for Windows) >>>> - Platform::MultibyteStringToWideString() @ WindowsPlatform.cpp >>>> >>>> This change passed tests on submit repo >>>> (mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139). >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html >>>> From Alan.Bateman at oracle.com Tue Mar 10 17:25:24 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Mar 2020 17:25:24 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: References: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> Message-ID: <37bbecb2-0724-11c2-5367-0e73876c6472@oracle.com> On 10/03/2020 15:10, Martin Buchholz wrote: > Aside: if all you want to do is make a use of HashMap more > reproducible, the standard reaction is s/HashMap/LinkedHashMap/g Yes, if the insertion order is reproducible. We've had several issues with trying to get to reproducible builds, I suspect this one was missed because the tests aren't using --keep-packaged-modules so there isn't JMOD files in the run-time images. -Alan From naoto.sato at oracle.com Tue Mar 10 17:45:00 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 10 Mar 2020 10:45:00 -0700 Subject: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes In-Reply-To: <026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch> References: <44EE1961-6729-4F96-8885-439FED393A81@oracle.com> <026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch> Message-ID: Hi Philipp, The reason that the current implementation of Grapheme boundary check does it is that, some rules require information before the boundary, i.e. the rule GB12 in Unicode Segmentation [1] reads: "do not break between regional indicator (RI) symbols if there is an odd number of RI characters *before* the break point." Of course this itself can be improved, but I am not so keen on modifying Grapheme/Pattern code at this time, so using BreakIterator (with Locale.US) is more preferred solution to me. Naoto [1] https://unicode.org/reports/tr29/ On 3/10/20 12:11 AM, Philipp Kunz wrote: > Hi Naoto and everyone, > > When I tried the regular expression approach you proposed which really > looks delightful, ValueUtf8Coding test ran into a timeout, which is why > I changed Pattern and Grapheme classes to start the loop in nextBoundary > to start at the offset off rather than at the beginning of the character > sequence src rendering isBoundary redundant. The changes to Pattern and > Grapheme relate only by means of performance and could otherwise be > applied seperately as well. I admit I'm not too confident and familiar > with the regex parts of the openjdk and would welcome not only thorough > review as usual but also any other feedback or thought?shared about the > matter. > > Then I started to wonder about an issue of copy paste between Grapheme > and GraphemeTest already out of date and also about some comments in > RegExTest and if no more matches shouldn't also be asserted, which also > could possibly be changed in a different change but still relate to the > actual changes to certain extent. I could not find a way to access > UCD_FILES which has no or is in the default package. > > What about passing the name and the value parameters of > Manifest.printLine72 to it as separate parameters? Because names cannot > exceed 70 bytes and the allowed characters are limited to ones that are > represented with one byte each in UTF-8 the name can/could always be > printed without a line break. I don't know if Manifest.println72 can be > removed or has to be retained and deprecated for compatibility. > > See attached patch. > > Looking forward to receiving any kind of feedback and regards, > Philipp > > > > > > On Tue, 2020-02-11 at 14:20 -0800, naoto.sato at oracle.com wrote: >> Hi, >> >> Can the code in Manifest.java be simplified using regex? E.g., >> >> var gc = Pattern.compile("\\X"); >> gc.matcher(line).results() >> .map(MatchResult::group) >> .forEach( >> // print till 72 bytes in UTF-8 >> ); >> >> Just a thought. If BreakIterator is preferred, it should take Locale.US >> as an argument to the factory method, so that it would produce the same >> result no matter what the default locale is. >> >> Naoto >> >> On 2/10/20 1:22 PM, Lance Andersen wrote: >>> Hi all, >>> >>> Here is a webrev for the patch that Philipp is proposing which will make it easier to review: >>> http://cr.openjdk.java.net/~lancea/6202130/webrev.00 >>> < >>> http://cr.openjdk.java.net/~lancea/6202130/webrev.00 >>> > >>> >>>> On Dec 26, 2019, at 11:50 AM, Philipp Kunz < >>>> philipp.kunz at paratix.ch >>>> >>>> > wrote: >>>> >>>> Hi, >>>> The specification says, a line break in a manifest can occur beforeor >>>> after a Unicode character encoded in UTF-8. >>>>> ...> value: SPACE *otherchar newline >>>> *continuation> continuation: SPACE *otherchar >>>> newline> ...> otherchar: any UTF-8 character except NUL, CR >>>> and LF >>>> The current implementation breaks manifest lines at 72 bytes regardless >>>> ofhow the bytes around the break are part of a sequence of bytes >>>> encoding acharacter. Code points may use up to four bytes when encoded >>>> in UTF-8.Manifests with line breaks inside of sequences of bytes >>>> encoding Unicodecharacters in UTF-8 with more than one bytes not only >>>> are invalid UTF-8but also look ugly in text editors.For example, a >>>> manifest could look like this: >>>> import java.util.jar.Manifest;import java.util.jar.Attributes;import >>>> static java.util.jar.Attributes.Name; >>>> public class CharacterBrokenDemo1 { public static void main(String[] >>>> args) throws Exception{ Manifest mf = new >>>> Manifest(); Attributes attrs = >>>> mf.getMainAttributes(); attrs.put(Name.MANIFEST_VERSION, >>>> "1.0"); attrs.put(new Name("Some-Key"), "Some >>>> languages have decorated characters, " + "for >>>> example: espa?ol"); // or >>>> "espa\u00D1ol" mf.write(System.out); }} >>>> Above code produces a result as follows with some unexpected question >>>> markswhere the encoding is invalid: >>>>> Manifest-Version: 1.0> Some-Key: Some languages have decorated >>>> characters, for example: espa?> ?ol >>>> This is of course an example written with actual question marks to get >>>> a validtext for this message. The trick here is that "Some-Key" to >>>> "example :espa"amounts to exactly one byte less encoded in UTF-8 than >>>> would fit on one linewith the 72 byte limit so that the subsequent >>>> character encoded with two bytesgets broken inside of the sequence of >>>> two bytes for this character across acontinuation line break. >>>> When decoding the resulting bytes from UTF-8 as one whole string, the >>>> twoquestion marks will not fit together again even if the line break >>>> with thecontinuation space is removed. However, Manifest::read removes >>>> the continuationline breaks ("\r\n ") before decoding the manifest >>>> header value from UTF-8 andhence can reproduce the original value. >>>> Characters encoded in UTF-8 can not only span up to four bytes for one >>>> codepoint each, there are also combining characters or classes thereof >>>> or combiningdiacritical marks or whatever the appropriate term could >>>> be, that combine morethan one code point into what is usually >>>> experienced and referred to as acharacter. >>>> The term character really gets ambiguous at this point. I wouldn't know >>>> whatthe specification actually refers to with that term "character". So >>>> rather thandiving in too much specification or any sorts of theory, >>>> let's look at anotherexample: >>>> import java.util.jar.Manifest;import java.util.jar.Attributes;import >>>> static java.util.jar.Attributes.Name; >>>> public class DemoCharacterBroken2 { public static void main(String[] >>>> args) throws Exception{ Manifest mf = new >>>> Manifest(); Attributes attrs = >>>> mf.getMainAttributes(); attrs.put(Name.MANIFEST_VERSION, >>>> "1.0"); attrs.put(new Name("Some-Key"), " ".repeat(53) + >>>> "Angstro\u0308m"); mf.write(System.out); }} >>>> which produces console output as follows: >>>>> Manifest-Version: 1.0> Some- >>>> Key: Angstro> >>>> ?m >>>> (In case this does not display well, the diaeresis is on the m on the >>>> last line) >>>> When the whole Manifest is decoded from UTF-8 as one big single string >>>> andcontinuation line breaks are not removed until after UTF-8 decoding >>>> the wholemanifest, the diaeresis (umlaut, two points above, u0308) >>>> apparently kind ofjumps onto the following letter m because somehow it >>>> cannot be combined withthe preceding space. The UTF-8 decoder (all of >>>> my editors I tried, not onlyEclipse and its console view, also less, >>>> gedit, cat and terminal) somehowtries to fix that but the diaeresis may >>>> not necessarily jump back on the "o"where it originally belonged by >>>> removing the continuation line break ("\r\n ")after UTF-8 decoding has >>>> taken place, at least that did not work for me. >>>> Hence, ideally combining diacritical marks should better not be >>>> separated fromwhatever they combine with when breaking manifest lines >>>> onto a continuationline. Such combinations, however, seem to be >>>> unlimited in terms of number ofcode points combining into the same >>>> "experienced" character. I was able tofind combinations that not only >>>> exceed the limit of 72 bytes per line but alsoexceed the line buffer >>>> size of 512 bytes in Manifest::read. These may be ratheruncommon but >>>> still possible to my own surprise. >>>> Next consideration would then be to remove that limit of 512 bytes per >>>> manifestline but exceeding it would make such manifests incompatible >>>> with previousManifest::read implementations and is not really an >>>> immediately availableoption at the moment. >>>> As a compromise, those characters including combining diacritical marks >>>> whichcombine only so many code points as that their binarily encoded >>>> form in UTF-8remains within a limit of 71 bytes can be written without >>>> an interruptingcontinuation line break, which applies to most cases, >>>> but not all. I guess thisshould suit practically and realistically to >>>> be expected values well. >>>> Another possibility would be to allow for characters that are >>>> combinations ofmultiple Unicode code points to be kept together in >>>> their encoded form in UTF-8up to 512 bytes line length limit when >>>> reading minus a space and a line breakamounting to 509 bytes, but that >>>> would still not make manifests be representedas valid Unicode in all >>>> corner cases and I guess would not probably make a realimprovement in >>>> practice over a limit of 71 bytes. >>>> Attached is a patch that tries to implement what was described above >>>> using aBreakIterator. While it works from a functional point of view, >>>> this might beless desirable performance-wise. Alternatively could be >>>> considered to do withoutthe BreakIterator and only keep Unicode code >>>> points together by not placingline breaks before a continuation byte, >>>> which however would not addresscombining diacritical marks as in the >>>> second example above. >>>> The jar file specification does not explicitly state that manifest >>>> should bevalid UTF-8, and they were not always, but it also does not >>>> state otherwise,leaving an impression that manifests could be >>>> (mis)taken for UTF-8 encodedstrings, which they also are in many or >>>> most cases and which has been confusedmany times. At the moment, the >>>> only case where a valid manifest is not also avalid UTF-8 encoded >>>> string is when a sequence of bytes encoding the samecharacter happens >>>> to be interrupted with a continuation line break. To the bestof my >>>> knowledge, all other valid manifests are also valid UTF-8 encoded >>>> strings. >>>> It would be nice, if manifests could be viewed and manipulated with all >>>> Unicodecapable editors and not only be parsed correctly with >>>> Manifest::read. >>>> Any opinions? Would someone sponsor this patch? >>>> Regards,Philipp >>>> >>>> https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#specificationhttps://bugs.openjdk.java.net/browse/JDK-6202130https://bugs.openjdk.java.net/browse/JDK-6443578https://github.com/gradle/gradle/issues/5225https://bugs.openjdk.java.net/browse/JDK-8202525https://en.wikipedia.org/wiki/Combining_character >>>> >>>> >>>> <6202130-manifestutf8linebreak.patch> >>> >>> < >>> http://oracle.com/us/design/oracle-email-sig-198324.gif >>> > >>> < >>> http://oracle.com/us/design/oracle-email-sig-198324.gif >>> > < >>> http://oracle.com/us/design/oracle-email-sig-198324.gif >>> > >>> < >>> http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance >>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >> Lance.Andersen at oracle.com >>> >>> > >>> >>> >>> From mandy.chung at oracle.com Tue Mar 10 18:27:52 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 Mar 2020 18:27:52 +0000 (UTC) Subject: Review Request: JDK-8240242: improve the javadoc for Lookup::dropLookupModes w.r.t. dropping UNCONDITIONAL Message-ID: Hi Chris, Below is the revised patch per your suggestion.? I made some minor fixes in the method name shown in the "Access modes" section as well. Mandy diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java @@ -740,11 +740,11 @@ ????? * The table below shows the access modes of a {@code Lookup} produced by ????? * any of the following factory or transformation methods: ????? *

    -???? *
  • {@link #lookup() MethodHandles.lookup()}
    • -???? *
  • {@link #publicLookup() MethodHandles.publicLookup()}
    • -???? *
  • {@link #privateLookupIn(Class, Lookup) MethodHandles.privateLookupIn}
    • -???? *
  • {@link Lookup#in}
    • -???? *
  • {@link Lookup#dropLookupMode(int)}
    • +???? *
  • {@link #lookup() MethodHandles::lookup}
    • +???? *
  • {@link #publicLookup() MethodHandles::publicLookup}
    • +???? *
  • {@link #privateLookupIn(Class, Lookup) MethodHandles::privateLookupIn}
    • +???? *
  • {@link Lookup#in Lookup::in}
    • +???? *
  • {@link Lookup#dropLookupMode(int) Lookup::dropLookupMode}
    • ????? *
????? * ????? *
@@ -1524,14 +1524,22 @@ ????????? * Creates a lookup on the same lookup class which this lookup object ????????? * finds members, but with a lookup mode that has lost the given lookup mode. ????????? * The lookup mode to drop is one of {@link #PUBLIC PUBLIC}, {@link #MODULE -???????? * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED} or {@link #PRIVATE PRIVATE}. -???????? * {@link #PROTECTED PROTECTED} is always -???????? * dropped and so the resulting lookup mode will never have this access capability. -???????? * When dropping {@code PACKAGE} then the resulting lookup will not have {@code PACKAGE} -???????? * or {@code PRIVATE} access. When dropping {@code MODULE} then the resulting lookup will -???????? * not have {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. If {@code PUBLIC} -???????? * is dropped then the resulting lookup has no access. If {@code UNCONDITIONAL} -???????? * is dropped then the resulting lookup has no access. +???????? * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED}, +???????? * {@link #PRIVATE PRIVATE}, or {@link #UNCONDITIONAL UNCONDITIONAL}. +???????? * +???????? *

If this lookup is a {@linkplain MethodHandles#publicLookup() public lookup}, +???????? * this lookup has {@code UNCONDITIONAL} mode set and it has no other mode set. +???????? * When dropping {@code UNCONDITIONAL} on a public lookup then the resulting +???????? * lookup has no access. +???????? * +???????? *

If this lookup is not a public lookup, then the following applies +???????? * regardless of its {@linkplain #lookupModes() lookup modes}. +???????? * {@link #PROTECTED PROTECTED} is always dropped and so the resulting lookup +???????? * mode will never have this access capability. When dropping {@code PACKAGE} +???????? * then the resulting lookup will not have {@code PACKAGE} or {@code PRIVATE} +???????? * access. When dropping {@code MODULE} then the resulting lookup will not +???????? * have {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. +???????? * When dropping {@code PUBLIC} then the resulting lookup has no access. ????????? * ????????? * @apiNote ????????? * A lookup with {@code PACKAGE} but not {@code PRIVATE} mode can safely From martinrb at google.com Tue Mar 10 18:30:10 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Mar 2020 11:30:10 -0700 Subject: RFR: 8240725: Some functions might not work with CJK character In-Reply-To: References: <1bbe9067-b3f6-9b4a-774d-313d4cb6fab4@oracle.com> <3a8570ba-db32-fbbc-9292-8df41047a44d@oss.nttdata.com> <30180dfd-f255-5f07-36e0-6d251d0f8c31@oss.nttdata.com> Message-ID: On Tue, Mar 10, 2020 at 10:08 AM wrote: > > Then I noticed (should have noticed in the first place, sorry) that the > error handling in canonicalize_md.c is incorrect (unrelated to your > change). All error cases "goto finish" which would end up "free(NULL)" > in some cases, e.g. > FYI free(NULL) is a no-op https://pubs.opengroup.org/onlinepubs/9699919799/functions/free.html From chris.hegarty at oracle.com Tue Mar 10 19:01:09 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 10 Mar 2020 19:01:09 +0000 Subject: Review Request: JDK-8240242: improve the javadoc for Lookup::dropLookupModes w.r.t. dropping UNCONDITIONAL In-Reply-To: References: Message-ID: This looks good to me Mandy. Thanks, -Chris. > On 10 Mar 2020, at 18:27, Mandy Chung wrote: > > Hi Chris, > > Below is the revised patch per your suggestion. I made some minor fixes in the method name shown in the "Access modes" section as well. > > Mandy > > diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > @@ -740,11 +740,11 @@ > * The table below shows the access modes of a {@code Lookup} produced by > * any of the following factory or transformation methods: > *

    > - *
  • {@link #lookup() MethodHandles.lookup()}
    • > - *
  • {@link #publicLookup() MethodHandles.publicLookup()}
    • > - *
  • {@link #privateLookupIn(Class, Lookup) MethodHandles.privateLookupIn}
    • > - *
  • {@link Lookup#in}
    • > - *
  • {@link Lookup#dropLookupMode(int)}
    • > + *
  • {@link #lookup() MethodHandles::lookup}
    • > + *
  • {@link #publicLookup() MethodHandles::publicLookup}
    • > + *
  • {@link #privateLookupIn(Class, Lookup) MethodHandles::privateLookupIn}
    • > + *
  • {@link Lookup#in Lookup::in}
    • > + *
  • {@link Lookup#dropLookupMode(int) Lookup::dropLookupMode}
    • > *
> * > *
> @@ -1524,14 +1524,22 @@ > * Creates a lookup on the same lookup class which this lookup object > * finds members, but with a lookup mode that has lost the given lookup mode. > * The lookup mode to drop is one of {@link #PUBLIC PUBLIC}, {@link #MODULE > - * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED} or {@link #PRIVATE PRIVATE}. > - * {@link #PROTECTED PROTECTED} is always > - * dropped and so the resulting lookup mode will never have this access capability. > - * When dropping {@code PACKAGE} then the resulting lookup will not have {@code PACKAGE} > - * or {@code PRIVATE} access. When dropping {@code MODULE} then the resulting lookup will > - * not have {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. If {@code PUBLIC} > - * is dropped then the resulting lookup has no access. If {@code UNCONDITIONAL} > - * is dropped then the resulting lookup has no access. > + * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED}, > + * {@link #PRIVATE PRIVATE}, or {@link #UNCONDITIONAL UNCONDITIONAL}. > + * > + *

If this lookup is a {@linkplain MethodHandles#publicLookup() public lookup}, > + * this lookup has {@code UNCONDITIONAL} mode set and it has no other mode set. > + * When dropping {@code UNCONDITIONAL} on a public lookup then the resulting > + * lookup has no access. > + * > + *

If this lookup is not a public lookup, then the following applies > + * regardless of its {@linkplain #lookupModes() lookup modes}. > + * {@link #PROTECTED PROTECTED} is always dropped and so the resulting lookup > + * mode will never have this access capability. When dropping {@code PACKAGE} > + * then the resulting lookup will not have {@code PACKAGE} or {@code PRIVATE} > + * access. When dropping {@code MODULE} then the resulting lookup will not > + * have {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. > + * When dropping {@code PUBLIC} then the resulting lookup has no access. > * > * @apiNote > * A lookup with {@code PACKAGE} but not {@code PRIVATE} mode can safely From naoto.sato at oracle.com Tue Mar 10 19:16:54 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 10 Mar 2020 12:16:54 -0700 Subject: RFR: 8240725: Some functions might not work with CJK character In-Reply-To: References: <1bbe9067-b3f6-9b4a-774d-313d4cb6fab4@oracle.com> <3a8570ba-db32-fbbc-9292-8df41047a44d@oss.nttdata.com> <30180dfd-f255-5f07-36e0-6d251d0f8c31@oss.nttdata.com> Message-ID: Ah, thanks Martin. Never mind about the comment wrt free(NULL) then. Naoto On 3/10/20 11:30 AM, Martin Buchholz wrote: > > > On Tue, Mar 10, 2020 at 10:08 AM > wrote: > > > Then I noticed (should have noticed in the first place, sorry) that the > error handling in canonicalize_md.c is incorrect (unrelated to your > change). All error cases "goto finish" which would end up "free(NULL)" > in some cases, e.g. > > > FYI? free(NULL) is a no-op > https://pubs.opengroup.org/onlinepubs/9699919799/functions/free.html > From suenaga at oss.nttdata.com Wed Mar 11 00:39:55 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 11 Mar 2020 09:39:55 +0900 Subject: RFR: 8240725: Some functions might not work with CJK character In-Reply-To: References: <1bbe9067-b3f6-9b4a-774d-313d4cb6fab4@oracle.com> <3a8570ba-db32-fbbc-9292-8df41047a44d@oss.nttdata.com> <30180dfd-f255-5f07-36e0-6d251d0f8c31@oss.nttdata.com> Message-ID: Hi Sato-san, Thanks for your comment. I uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.03/ On 2020/03/11 2:08, naoto.sato at oracle.com wrote: > Hi Suenaga-san, > > Thank you for the update. I think your changes to the return values of MultiByteToWideChar look good. > > Then I noticed (should have noticed in the first place, sorry) that the error handling in canonicalize_md.c is incorrect (unrelated to your change). All error cases "goto finish" which would end up "free(NULL)" in some cases, e.g., line 340 (in the new file) should not end up calling "free(wresult)" and "free(wpath)" > > java_md.c > > - "convert_to_unicode()" has different indentation than others (2 spaces which should be 4). I fixed it. > - Should "wpath" be set to NULL before returning EINVAL at line 524? I don't know the contract of "create_unc_path", but the caller would receive a garbage pointer as a return value. create_unc_path() is static function, and it would be called by just JLI_Open(). If create_unc_path() would be failed (it means `err` is set excepting ERROR_SUCCESS), wpath would call free() when it is not NULL. Thus we should set related values as below: A: wpath = NULL, err != ERROR_SUCCESS B: wpath != NULL (not free'ed), err != ERROR_SUCCESS I implemented A in this webrev because it is simple. Thanks, Yasumasa > Nit: please add "noreg-hard" tag to the JIRA issue. > > Naoto > > > On 3/9/20 7:52 PM, Yasumasa Suenaga wrote: >> I forgot to free buffer if MultiByteToWideChar() failed in zip_util.c . >> So I updated webrev: >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.02/ >> >> >> Yasumasa >> >> >> On 2020/03/10 9:12, Yasumasa Suenaga wrote: >>> Hi Sato-san, >>> >>> Thanks for your comment! >>> >>> I updated webrev. Could you review again? >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.01/ >>> >>> >>> Yasumasa >>> >>> >>> On 2020/03/10 2:24, naoto.sato at oracle.com wrote: >>>> Hi Suenaga-san, >>>> >>>> I think the return value from the second MultiByteToWideChar invocation should be examined (non-zero), and if it was not successful, appropriate action should be taken. >>>> >>>> Naoto >>>> >>>> On 3/9/20 3:50 AM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8240725 >>>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.00/ >>>>> >>>>> We found the issue that HotSpot does not start when it is deployed on the path which contains CJK character(s), and it has been fixed in JDK-8240197. >>>>> >>>>> On the review of JDK-8240197 [1], we concern similar issue might occur in other place, and I found potentially problem in below: >>>>> >>>>> - ZFILE_Open() @ zip_util.c >>>>> - JDK_Canonicalize() @ canonicalize_md.c (for Windows) >>>>> - create_unc_path() @ java_md.c (for Windows) >>>>> - Platform::MultibyteStringToWideString() @ WindowsPlatform.cpp >>>>> >>>>> This change passed tests on submit repo (mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139). >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html From felix.yang at huawei.com Wed Mar 11 01:11:33 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 11 Mar 2020 01:11:33 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> References: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> Message-ID: > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Tuesday, March 10, 2020 3:53 PM > To: Yangfei (Felix) ; core-libs-dev at openjdk.java.net > Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible > between builds > > On 10/03/2020 02:54, Yangfei (Felix) wrote: > > Hi, > > > > We found module-info.class in java.base.jmod is not always consistent > across different builds. > > The ModuleHashes attribute in this module-info.class is not reproducible > between builds. > > Patch fixes the issue by using TreeMap instead of HashMap when > computing ModuleHashes. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8240734 > > Webrev: http://cr.openjdk.java.net/~fyang/8240734/webrev.00/ > > > This looks okay (and to Bernd question, this is used at link time). I think we need > to extend the test coverage for reproducible builds, the existing > JLinkReproducibleTest.java would ideally have caught the difference due to the > random ordering of hashes. Thanks for reviewing this. Pushed. We see two other issues which affect building reproducible jdk are resolved in 12: 1. 8214230: Classes generated by SystemModulesPlugin.java are not reproducible. 2. 8211057: Gensrc step CompileProperties generates unstable CompilerProperties output. I am inclined to backport these three to 11u so that we can get consistent 11u builds for verification. What do you think? Best regards, Felix From naoto.sato at oracle.com Wed Mar 11 03:27:12 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 10 Mar 2020 20:27:12 -0700 Subject: RFR: 8240725: Some functions might not work with CJK character In-Reply-To: References: <1bbe9067-b3f6-9b4a-774d-313d4cb6fab4@oracle.com> <3a8570ba-db32-fbbc-9292-8df41047a44d@oss.nttdata.com> <30180dfd-f255-5f07-36e0-6d251d0f8c31@oss.nttdata.com> Message-ID: <148bacd6-89c0-c518-1392-582dfef74c91@oracle.com> Looks good to me. Thanks for the fix! Naoto On 3/10/20 5:39 PM, Yasumasa Suenaga wrote: > Hi Sato-san, > > Thanks for your comment. > I uploaded new webrev: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.03/ > > On 2020/03/11 2:08, naoto.sato at oracle.com wrote: >> Hi Suenaga-san, >> >> Thank you for the update. I think your changes to the return values of >> MultiByteToWideChar look good. >> >> Then I noticed (should have noticed in the first place, sorry) that >> the error handling in canonicalize_md.c is incorrect (unrelated to >> your change). All error cases "goto finish" which would end up >> "free(NULL)" in some cases, e.g., line 340 (in the new file) should >> not end up calling "free(wresult)" and "free(wpath)" >> >> java_md.c >> >> - "convert_to_unicode()" has different indentation than others (2 >> spaces which should be 4). > > I fixed it. > > >> - Should "wpath" be set to NULL before returning EINVAL at line 524? I >> don't know the contract of "create_unc_path", but the caller would >> receive a garbage pointer as a return value. > > create_unc_path() is static function, and it would be called by just > JLI_Open(). > If create_unc_path() would be failed (it means `err` is set excepting > ERROR_SUCCESS), wpath would call free() when it is not NULL. > > Thus we should set related values as below: > > ? A: wpath = NULL, err != ERROR_SUCCESS > ? B: wpath != NULL (not free'ed), err != ERROR_SUCCESS > > I implemented A in this webrev because it is simple. > > > Thanks, > > Yasumasa > > >> Nit: please add "noreg-hard" tag to the JIRA issue. >> >> Naoto >> >> >> On 3/9/20 7:52 PM, Yasumasa Suenaga wrote: >>> I forgot to free buffer if MultiByteToWideChar() failed in zip_util.c . >>> So I updated webrev: >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.02/ >>> >>> >>> Yasumasa >>> >>> >>> On 2020/03/10 9:12, Yasumasa Suenaga wrote: >>>> Hi Sato-san, >>>> >>>> Thanks for your comment! >>>> >>>> I updated webrev. Could you review again? >>>> >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.01/ >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/03/10 2:24, naoto.sato at oracle.com wrote: >>>>> Hi Suenaga-san, >>>>> >>>>> I think the return value from the second MultiByteToWideChar >>>>> invocation should be examined (non-zero), and if it was not >>>>> successful, appropriate action should be taken. >>>>> >>>>> Naoto >>>>> >>>>> On 3/9/20 3:50 AM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this change: >>>>>> >>>>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8240725 >>>>>> ?? webrev: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.00/ >>>>>> >>>>>> We found the issue that HotSpot does not start when it is deployed >>>>>> on the path which contains CJK character(s), and it has been fixed >>>>>> in JDK-8240197. >>>>>> >>>>>> On the review of JDK-8240197 [1], we concern similar issue might >>>>>> occur in other place, and I found potentially problem in below: >>>>>> >>>>>> - ZFILE_Open() @ zip_util.c >>>>>> - JDK_Canonicalize() @ canonicalize_md.c (for Windows) >>>>>> - create_unc_path() @ java_md.c (for Windows) >>>>>> - Platform::MultibyteStringToWideString() @ WindowsPlatform.cpp >>>>>> >>>>>> This change passed tests on submit repo >>>>>> (mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139). >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html >>>>>> From suenaga at oss.nttdata.com Wed Mar 11 04:07:16 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 11 Mar 2020 13:07:16 +0900 Subject: RFR: 8240725: Some functions might not work with CJK character In-Reply-To: <148bacd6-89c0-c518-1392-582dfef74c91@oracle.com> References: <1bbe9067-b3f6-9b4a-774d-313d4cb6fab4@oracle.com> <3a8570ba-db32-fbbc-9292-8df41047a44d@oss.nttdata.com> <30180dfd-f255-5f07-36e0-6d251d0f8c31@oss.nttdata.com> <148bacd6-89c0-c518-1392-582dfef74c91@oracle.com> Message-ID: <86d6c4ef-0264-1541-7c50-7a8f8aac2022@oss.nttdata.com> Thanks Sato-san! Yasumasa On 2020/03/11 12:27, naoto.sato at oracle.com wrote: > Looks good to me. Thanks for the fix! > > Naoto > > On 3/10/20 5:39 PM, Yasumasa Suenaga wrote: >> Hi Sato-san, >> >> Thanks for your comment. >> I uploaded new webrev: >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.03/ >> >> On 2020/03/11 2:08, naoto.sato at oracle.com wrote: >>> Hi Suenaga-san, >>> >>> Thank you for the update. I think your changes to the return values of MultiByteToWideChar look good. >>> >>> Then I noticed (should have noticed in the first place, sorry) that the error handling in canonicalize_md.c is incorrect (unrelated to your change). All error cases "goto finish" which would end up "free(NULL)" in some cases, e.g., line 340 (in the new file) should not end up calling "free(wresult)" and "free(wpath)" >>> >>> java_md.c >>> >>> - "convert_to_unicode()" has different indentation than others (2 spaces which should be 4). >> >> I fixed it. >> >> >>> - Should "wpath" be set to NULL before returning EINVAL at line 524? I don't know the contract of "create_unc_path", but the caller would receive a garbage pointer as a return value. >> >> create_unc_path() is static function, and it would be called by just JLI_Open(). >> If create_unc_path() would be failed (it means `err` is set excepting ERROR_SUCCESS), wpath would call free() when it is not NULL. >> >> Thus we should set related values as below: >> >> ?? A: wpath = NULL, err != ERROR_SUCCESS >> ?? B: wpath != NULL (not free'ed), err != ERROR_SUCCESS >> >> I implemented A in this webrev because it is simple. >> >> >> Thanks, >> >> Yasumasa >> >> >>> Nit: please add "noreg-hard" tag to the JIRA issue. >>> >>> Naoto >>> >>> >>> On 3/9/20 7:52 PM, Yasumasa Suenaga wrote: >>>> I forgot to free buffer if MultiByteToWideChar() failed in zip_util.c . >>>> So I updated webrev: >>>> >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.02/ >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/03/10 9:12, Yasumasa Suenaga wrote: >>>>> Hi Sato-san, >>>>> >>>>> Thanks for your comment! >>>>> >>>>> I updated webrev. Could you review again? >>>>> >>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.01/ >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2020/03/10 2:24, naoto.sato at oracle.com wrote: >>>>>> Hi Suenaga-san, >>>>>> >>>>>> I think the return value from the second MultiByteToWideChar invocation should be examined (non-zero), and if it was not successful, appropriate action should be taken. >>>>>> >>>>>> Naoto >>>>>> >>>>>> On 3/9/20 3:50 AM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this change: >>>>>>> >>>>>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8240725 >>>>>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.00/ >>>>>>> >>>>>>> We found the issue that HotSpot does not start when it is deployed on the path which contains CJK character(s), and it has been fixed in JDK-8240197. >>>>>>> >>>>>>> On the review of JDK-8240197 [1], we concern similar issue might occur in other place, and I found potentially problem in below: >>>>>>> >>>>>>> - ZFILE_Open() @ zip_util.c >>>>>>> - JDK_Canonicalize() @ canonicalize_md.c (for Windows) >>>>>>> - create_unc_path() @ java_md.c (for Windows) >>>>>>> - Platform::MultibyteStringToWideString() @ WindowsPlatform.cpp >>>>>>> >>>>>>> This change passed tests on submit repo (mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139). >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html From philipp.kunz at paratix.ch Wed Mar 11 06:27:55 2020 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Wed, 11 Mar 2020 07:27:55 +0100 Subject: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes In-Reply-To: References: <44EE1961-6729-4F96-8885-439FED393A81@oracle.com> <026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch> Message-ID: Hi Naoto, Thank you for your reply. I fully agree to your reluctance or inhibition to change the regex part just along with the jar manifest. On the other hand, i'm quite confident that all invocations of Grapheme.nextBoundary with my previous patch start matching at the previous boundary and therefore I believe the cited requirement is met which also the existing tests confirm. Obviously, it is difficult to prove the correctness or absence of a mistake. In fact I was kind of hoping someone would get inspired who knows the area better than I do. Maybe relates to JDK-8216332 or JDK-8046101 to some extent, but I guess not exactly. Shall we file a new bug about a performance issue in regex grapheme matchers, the performance of which potentially depends more than linearly and necessarily on the total input sequence size in Grapheme.nextBoundary?Shall we file another bug about an issue of copy and paste in GraphemeTest?I am not entitled to create new bugs myself but if there were I might contribute a patch later. Regards,Philipp On Tue, 2020-03-10 at 10:45 -0700, naoto.sato at oracle.com wrote: > Hi Philipp, > The reason that the current implementation of Grapheme boundary check > does it is that, some rules require information before the boundary, > i.e. the rule GB12 in Unicode Segmentation [1] reads: > "do not break between regional indicator (RI) symbols if there is an > odd number of RI characters *before* the break point." > Of course this itself can be improved, but I am not so keen on > modifying Grapheme/Pattern code at this time, so using BreakIterator > (with Locale.US) is more preferred solution to me. > Naoto > [1] https://unicode.org/reports/tr29/ > > > On 3/10/20 12:11 AM, Philipp Kunz wrote: > > Hi Naoto and everyone, > > When I tried the regular expression approach you proposed which > > really looks delightful, ValueUtf8Coding test ran into a timeout, > > which is why I changed Pattern and Grapheme classes to start the > > loop in nextBoundary to start at the offset off rather than at the > > beginning of the character sequence src rendering isBoundary > > redundant. The changes to Pattern and Grapheme relate only by means > > of performance and could otherwise be applied seperately as well. I > > admit I'm not too confident and familiar with the regex parts of > > the openjdk and would welcome not only thorough review as usual but > > also any other feedback or thought shared about the matter. > > Then I started to wonder about an issue of copy paste between > > Grapheme and GraphemeTest already out of date and also about some > > comments in RegExTest and if no more matches shouldn't also be > > asserted, which also could possibly be changed in a different > > change but still relate to the actual changes to certain extent. I > > could not find a way to access UCD_FILES which has no or is in the > > default package. > > What about passing the name and the value parameters of > > Manifest.printLine72 to it as separate parameters? Because names > > cannot exceed 70 bytes and the allowed characters are limited to > > ones that are represented with one byte each in UTF-8 the name > > can/could always be printed without a line break. I don't know if > > Manifest.println72 can be removed or has to be retained and > > deprecated for compatibility. > > See attached patch. > > Looking forward to receiving any kind of feedback and > > regards,Philipp > > > > > > > > > > On Tue, 2020-02-11 at 14:20 -0800, naoto.sato at oracle.com wrote: > > > Hi, > > > Can the code in Manifest.java be simplified using regex? E.g., > > > var gc = > > > Pattern.compile("\\X");gc.matcher(line).results() .map(Match > > > Result::group) .forEach( // print till 72 bytes in UTF- > > > 8 ); > > > Just a thought. If BreakIterator is preferred, it should take > > > Locale.USas an argument to the factory method, so that it would > > > produce the sameresult no matter what the default locale is. > > > Naoto > > > On 2/10/20 1:22 PM, Lance Andersen wrote: > > > > Hi all, > > > > Here is a webrev for the patch that Philipp is proposing which > > > > will make it easier to review: > > > > http://cr.openjdk.java.net/~lancea/6202130/webrev.00 > > > > > > > > On Dec 26, 2019, at 11:50 AM, Philipp Kunz < > > > > > philipp.kunz at paratix.ch > > > > > > > > > > > wrote: > > > > > > > > > > Hi,The specification says, a line break in a manifest can > > > > > occur beforeorafter a Unicode character encoded in UTF-8. > > > > > > ...> value: SPACE *otherchar newline > > > > > *continuation> continuation: SPACE > > > > > *othercharnewline> ...> otherchar: any UTF-8 > > > > > character except NUL, CRand LFThe current implementation > > > > > breaks manifest lines at 72 bytes regardlessofhow the bytes > > > > > around the break are part of a sequence of bytesencoding > > > > > acharacter. Code points may use up to four bytes when > > > > > encodedin UTF-8.Manifests with line breaks inside of > > > > > sequences of bytesencoding Unicodecharacters in UTF-8 with > > > > > more than one bytes not onlyare invalid UTF-8but also look > > > > > ugly in text editors.For example, amanifest could look like > > > > > this:import java.util.jar.Manifest;import > > > > > java.util.jar.Attributes;importstatic > > > > > java.util.jar.Attributes.Name;public class > > > > > CharacterBrokenDemo1 { public static void > > > > > main(String[]args) throws Exception{ Manifest mf = > > > > > newManifest(); Attributes attrs > > > > > =mf.getMainAttributes(); attrs.put(Name.MANIFEST_VERSI > > > > > ON,"1.0"); attrs.put(new Name("Some- > > > > > Key"), "Somelanguages have decorated > > > > > characters, " + "forexample: espa?ol"); // > > > > > or"espa\u00D1ol" mf.write(System.out); }}Above code > > > > > produces a result as follows with some unexpected > > > > > questionmarkswhere the encoding is invalid: > > > > > > Manifest-Version: 1.0> Some-Key: Some languages have > > > > > > decorated > > > > > characters, for example: espa?> ?olThis is of course an > > > > > example written with actual question marks to geta validtext > > > > > for this message. The trick here is that "Some-Key" > > > > > to"example :espa"amounts to exactly one byte less encoded in > > > > > UTF-8 thanwould fit on one linewith the 72 byte limit so that > > > > > the subsequentcharacter encoded with two bytesgets broken > > > > > inside of the sequence oftwo bytes for this character across > > > > > acontinuation line break.When decoding the resulting bytes > > > > > from UTF-8 as one whole string, thetwoquestion marks will not > > > > > fit together again even if the line breakwith thecontinuation > > > > > space is removed. However, Manifest::read removesthe > > > > > continuationline breaks ("\r\n ") before decoding the > > > > > manifestheader value from UTF-8 andhence can reproduce the > > > > > original value.Characters encoded in UTF-8 can not only span > > > > > up to four bytes for onecodepoint each, there are also > > > > > combining characters or classes thereofor > > > > > combiningdiacritical marks or whatever the appropriate term > > > > > couldbe, that combine morethan one code point into what is > > > > > usuallyexperienced and referred to as acharacter.The term > > > > > character really gets ambiguous at this point. I wouldn't > > > > > knowwhatthe specification actually refers to with that term > > > > > "character". Sorather thandiving in too much specification or > > > > > any sorts of theory,let's look at anotherexample:import > > > > > java.util.jar.Manifest;import > > > > > java.util.jar.Attributes;importstatic > > > > > java.util.jar.Attributes.Name;public class > > > > > DemoCharacterBroken2 { public static void > > > > > main(String[]args) throws Exception{ Manifest mf = > > > > > newManifest(); Attributes attrs > > > > > =mf.getMainAttributes(); attrs.put(Name.MANIFEST_VERSI > > > > > ON,"1.0"); attrs.put(new Name("Some-Key"), " > > > > > ".repeat(53) > > > > > +"Angstro\u0308m"); mf.write(System.out); }}which > > > > > produces console output as follows: > > > > > > Manifest-Version: 1.0> Some- > > > > > Key: Ang > > > > > stro>?m(In case this does not display well, the diaeresis is > > > > > on the m on thelast line)When the whole Manifest is decoded > > > > > from UTF-8 as one big single stringandcontinuation line > > > > > breaks are not removed until after UTF-8 decodingthe > > > > > wholemanifest, the diaeresis (umlaut, two points above, > > > > > u0308)apparently kind ofjumps onto the following letter m > > > > > because somehow itcannot be combined withthe preceding space. > > > > > The UTF-8 decoder (all ofmy editors I tried, not onlyEclipse > > > > > and its console view, also less,gedit, cat and terminal) > > > > > somehowtries to fix that but the diaeresis maynot necessarily > > > > > jump back on the "o"where it originally belonged byremoving > > > > > the continuation line break ("\r\n ")after UTF-8 decoding > > > > > hastaken place, at least that did not work for me.Hence, > > > > > ideally combining diacritical marks should better not > > > > > beseparated fromwhatever they combine with when breaking > > > > > manifest linesonto a continuationline. Such combinations, > > > > > however, seem to beunlimited in terms of number ofcode points > > > > > combining into the same"experienced" character. I was able > > > > > tofind combinations that not onlyexceed the limit of 72 bytes > > > > > per line but alsoexceed the line buffersize of 512 bytes in > > > > > Manifest::read. These may be ratheruncommon butstill possible > > > > > to my own surprise.Next consideration would then be to remove > > > > > that limit of 512 bytes permanifestline but exceeding it > > > > > would make such manifests incompatiblewith > > > > > previousManifest::read implementations and is not really > > > > > animmediately availableoption at the moment.As a compromise, > > > > > those characters including combining diacritical > > > > > markswhichcombine only so many code points as that their > > > > > binarily encodedform in UTF-8remains within a limit of 71 > > > > > bytes can be written withoutan interruptingcontinuation line > > > > > break, which applies to most cases,but not all. I guess > > > > > thisshould suit practically and realistically tobe expected > > > > > values well.Another possibility would be to allow for > > > > > characters that arecombinations ofmultiple Unicode code > > > > > points to be kept together intheir encoded form in UTF-8up to > > > > > 512 bytes line length limit whenreading minus a space and a > > > > > line breakamounting to 509 bytes, but thatwould still not > > > > > make manifests be representedas valid Unicode in allcorner > > > > > cases and I guess would not probably make a realimprovement > > > > > inpractice over a limit of 71 bytes.Attached is a patch that > > > > > tries to implement what was described aboveusing > > > > > aBreakIterator. While it works from a functional point of > > > > > view,this might beless desirable performance-wise. > > > > > Alternatively could beconsidered to do withoutthe > > > > > BreakIterator and only keep Unicode codepoints together by > > > > > not placingline breaks before a continuation byte,which > > > > > however would not addresscombining diacritical marks as in > > > > > thesecond example above.The jar file specification does not > > > > > explicitly state that manifestshould bevalid UTF-8, and they > > > > > were not always, but it also does notstate otherwise,leaving > > > > > an impression that manifests could be(mis)taken for UTF-8 > > > > > encodedstrings, which they also are in many ormost cases and > > > > > which has been confusedmany times. At the moment, theonly > > > > > case where a valid manifest is not also avalid UTF-8 > > > > > encodedstring is when a sequence of bytes encoding the > > > > > samecharacter happensto be interrupted with a continuation > > > > > line break. To the bestof myknowledge, all other valid > > > > > manifests are also valid UTF-8 encodedstrings.It would be > > > > > nice, if manifests could be viewed and manipulated with > > > > > allUnicodecapable editors and not only be parsed correctly > > > > > withManifest::read.Any opinions? Would someone sponsor this > > > > > patch?Regards,Philipp > > > > > https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#specificationhttps://bugs.openjdk.java.net/browse/JDK-6202130https://bugs.openjdk.java.net/browse/JDK-6443578https://github.com/gradle/gradle/issues/5225https://bugs.openjdk.java.net/browse/JDK-8202525https://en.wikipedia.org/wiki/Combining_character > > > > > > > > > > > > > > > <6202130-manifestutf8linebreak.patch> > > > > > > > > > > > > > > > < > > > > http://oracle.com/us/design/oracle-email-sig-198324.gif > > > > < > > > > http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance > > > > Andersen| Principal Member of Technical Staff | > > > > +1.781.442.2037Oracle Java Engineering1 Network > > > > DriveBurlington, MA 01803Lance.Andersen at oracle.com > > > > > > > Lance.Andersen at oracle.com > > > > > > > > > > > > From Alan.Bateman at oracle.com Wed Mar 11 07:02:59 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Mar 2020 07:02:59 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: References: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> Message-ID: <729bee37-e7b1-6a09-ba42-4d55381cc1fc@oracle.com> On 11/03/2020 01:11, Yangfei (Felix) wrote: > Thanks for reviewing this. Pushed. Okay but I think we need to add a test for this. Can you look at JLinkReproducibleTest and see if it can be extended to use --keep-packaged-modules so that you have the JMOD files in the run-time image. -Alan From denghui.ddh at alibaba-inc.com Wed Mar 11 07:05:02 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 11 Mar 2020 15:05:02 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIzODY2NTogQWRkIEpGUiBldmVudCBmb3IgZGlyZWN0IG1lbW9yeSBzdGF0?= =?UTF-8?B?aXN0aWNz?= In-Reply-To: References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> , , Message-ID: <87d10ec1-bf65-4bce-b83e-e3ecf2d93a84.denghui.ddh@alibaba-inc.com> Ping. Could you review this? Thanks, Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2020?3?8?(???) 23:42 To:Erik Gahlin ; Alan Bateman Cc:hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Alan and Erik, Thanks for the review. Webrev has been updated in http://cr.openjdk.java.net/~ddong/8238665/webrev.02/ Testing: jdk/jfr, java/lang/management/ all passed Summary: add a method in jdk.internal.misc.VM to get an unmodifiable buffer pool list. Cheers, Denghui Dong ------------------------------------------------------------------ From:Alan Bateman Send Time:2020?3?8?(???) 22:13 To:???(??) ; Erik Gahlin Cc:hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics On 05/03/2020 15:19, Denghui Dong wrote: Hi Alan and Erik, Sorry, I'm not sure if I fully understand what you mean. For this feature, I still think exporting jdk.internal.access to jdk.jfr is a good solutionsince there are some other packages has already exported to jdk.jfr in this module. I think it would be cleaner to put a helper in jdk.internal.misc so that JFR has access to the counters for each of the buffer pools. That would avoid additional plumbing when you extend it to mapped buffers. As I mentioned in one of the other mails, ManagementFactoryHelper.getBufferPoolMXBeans() could be changed to use it too. From the perspective of java.base then it's a lot nicer as anyone touching the buffer code doesn't need to have to concerned with direct access from code in java.management and jdk.jfr. -Alan From felix.yang at huawei.com Wed Mar 11 07:21:15 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 11 Mar 2020 07:21:15 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: <729bee37-e7b1-6a09-ba42-4d55381cc1fc@oracle.com> References: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> <729bee37-e7b1-6a09-ba42-4d55381cc1fc@oracle.com> Message-ID: > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Wednesday, March 11, 2020 3:03 PM > To: Yangfei (Felix) ; core-libs-dev at openjdk.java.net > Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible > between builds > > On 11/03/2020 01:11, Yangfei (Felix) wrote: > > Thanks for reviewing this. Pushed. > Okay but I think we need to add a test for this. Can you look at > JLinkReproducibleTest and see if it can be extended to use > --keep-packaged-modules so that you have the JMOD files in the run-time > image. Sure. We will take a look. Thanks, Felix From adam.sotona at oracle.com Wed Mar 11 10:31:30 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Wed, 11 Mar 2020 11:31:30 +0100 Subject: RFR: 8230117 removing dead code from jar tool In-Reply-To: References: <62B599B2-5F5C-454E-823A-64AAF93D2817@oracle.com> <994D1E5F-06CA-4489-A662-F4470FD87F24@oracle.com> Message-ID: <429EFB1F-933F-4BB6-8326-F937813C3C4E@oracle.com> Hi Christoph, thank you for clarification, here it is: JBS: https://bugs.openjdk.java.net/browse/JDK-8230117 webrev: http://cr.openjdk.java.net/~asotona/8230117/webrev.00/ Mach5 Tier1, Tier2 and Tier3 tests passed. Thanks, Adam > On 1 Mar 2020, at 21:16, Langer, Christoph wrote: > > Hi Adam, Lance, > > as you've already figured out, attachments sent out to the mailing list will be removed. So it's important to generate webrevs and link to it or, for smaller patches, inline it. ?? > > Also, the RFR subject is missing a bug ID. From the URL to the webrev I take the bug ID is JDK-8230117. Going to JBS it seems that the bug is confidential. Could you please either open up the bug before pushing or alternatively, create a new, public bug to push this against? > > Thanks > Christoph > > > >> -----Original Message----- >> From: core-libs-dev On Behalf >> Of Lance Andersen >> Sent: Freitag, 28. Februar 2020 18:04 >> To: Sean Mullan >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: RFR: removing dead code from jar tool >> >> sigh it is being removed it appears by the mail server >> >> I placed a copy here: http://cr.openjdk.java.net/~lancea/JDK-8230117.patch >> >> >>> On Feb 28, 2020, at 12:00 PM, Lance Andersen >> wrote: >>> >>> Here it is again >>> >>>> On Feb 28, 2020, at 11:07 AM, Sean Mullan >> wrote: >>>> >>>> I think you forgot to attach the patch. >>>> >>>> --Sean >>>> >>>> On 2/28/20 2:28 AM, Adam Sotona wrote: >>>>> Hi, >>>>> I would like to ask for review of the attached patch removing dead code >> from jar tool >>>>> Class files sun.tools.jar.Manifest and sun.tools.jar.SignatureFile appear >> to be dead code and should be removed. >>>>> Build with the patch passes all Tier1, Tier2 and Tier3 tests. >>>>> Thank you, >>>>> Adam >>> >>> >>> >> >>> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >> >> >> >> >> Lance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> > From christoph.langer at sap.com Wed Mar 11 12:16:47 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Mar 2020 12:16:47 +0000 Subject: RFR: 8230117 removing dead code from jar tool In-Reply-To: <429EFB1F-933F-4BB6-8326-F937813C3C4E@oracle.com> References: <62B599B2-5F5C-454E-823A-64AAF93D2817@oracle.com> <994D1E5F-06CA-4489-A662-F4470FD87F24@oracle.com> <429EFB1F-933F-4BB6-8326-F937813C3C4E@oracle.com> Message-ID: Hi Adam, thanks for opening up the bug and reposting. Looks good to me ?? Cheers Christoph From: Adam Sotona Sent: Mittwoch, 11. M?rz 2020 11:32 To: Langer, Christoph Cc: Lance Andersen ; Sean Mullan ; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8230117 removing dead code from jar tool Hi Christoph, thank you for clarification, here it is: JBS: https://bugs.openjdk.java.net/browse/JDK-8230117 webrev: http://cr.openjdk.java.net/~asotona/8230117/webrev.00/ Mach5 Tier1, Tier2 and Tier3 tests passed. Thanks, Adam On 1 Mar 2020, at 21:16, Langer, Christoph > wrote: Hi Adam, Lance, as you've already figured out, attachments sent out to the mailing list will be removed. So it's important to generate webrevs and link to it or, for smaller patches, inline it. ?? Also, the RFR subject is missing a bug ID. From the URL to the webrev I take the bug ID is JDK-8230117. Going to JBS it seems that the bug is confidential. Could you please either open up the bug before pushing or alternatively, create a new, public bug to push this against? Thanks Christoph -----Original Message----- From: core-libs-dev > On Behalf Of Lance Andersen Sent: Freitag, 28. Februar 2020 18:04 To: Sean Mullan > Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: removing dead code from jar tool sigh it is being removed it appears by the mail server I placed a copy here: http://cr.openjdk.java.net/~lancea/JDK-8230117.patch On Feb 28, 2020, at 12:00 PM, Lance Andersen > wrote: Here it is again On Feb 28, 2020, at 11:07 AM, Sean Mullan > wrote: I think you forgot to attach the patch. --Sean On 2/28/20 2:28 AM, Adam Sotona wrote: Hi, I would like to ask for review of the attached patch removing dead code from jar tool Class files sun.tools.jar.Manifest and sun.tools.jar.SignatureFile appear to be dead code and should be removed. Build with the patch passes all Tier1, Tier2 and Tier3 tests. Thank you, Adam Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Lance.Andersen at oracle.com Wed Mar 11 12:19:15 2020 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Wed, 11 Mar 2020 08:19:15 -0400 Subject: RFR: 8230117 removing dead code from jar tool In-Reply-To: References: Message-ID: <2A38271F-36A9-42F6-80BB-1F042848DFE3@oracle.com> FYI I will be pushing today after one last Mach 5 run completes -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com > On Mar 11, 2020, at 8:16 AM, Langer, Christoph wrote: > > ? > Hi Adam, > > thanks for opening up the bug and reposting. Looks good to me ?? > > Cheers > Christoph > > From: Adam Sotona > Sent: Mittwoch, 11. M?rz 2020 11:32 > To: Langer, Christoph > Cc: Lance Andersen ; Sean Mullan ; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8230117 removing dead code from jar tool > > Hi Christoph, > thank you for clarification, here it is: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8230117 > webrev: http://cr.openjdk.java.net/~asotona/8230117/webrev.00/ > > Mach5 Tier1, Tier2 and Tier3 tests passed. > > Thanks, > Adam > > > On 1 Mar 2020, at 21:16, Langer, Christoph wrote: > > Hi Adam, Lance, > > as you've already figured out, attachments sent out to the mailing list will be removed. So it's important to generate webrevs and link to it or, for smaller patches, inline it. ?? > > Also, the RFR subject is missing a bug ID. From the URL to the webrev I take the bug ID is JDK-8230117. Going to JBS it seems that the bug is confidential. Could you please either open up the bug before pushing or alternatively, create a new, public bug to push this against? > > Thanks > Christoph > > > > > -----Original Message----- > From: core-libs-dev On Behalf > Of Lance Andersen > Sent: Freitag, 28. Februar 2020 18:04 > To: Sean Mullan > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR: removing dead code from jar tool > > sigh it is being removed it appears by the mail server > > I placed a copy here: http://cr.openjdk.java.net/~lancea/JDK-8230117.patch > > > > On Feb 28, 2020, at 12:00 PM, Lance Andersen > wrote: > > > Here it is again > > > On Feb 28, 2020, at 11:07 AM, Sean Mullan > wrote: > > > I think you forgot to attach the patch. > > --Sean > > On 2/28/20 2:28 AM, Adam Sotona wrote: > > Hi, > I would like to ask for review of the attached patch removing dead code > from jar tool > > Class files sun.tools.jar.Manifest and sun.tools.jar.SignatureFile appear > to be dead code and should be removed. > > Build with the patch passes all Tier1, Tier2 and Tier3 tests. > Thank you, > Adam > > > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From Alan.Bateman at oracle.com Wed Mar 11 16:10:30 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Mar 2020 16:10:30 +0000 Subject: Review Request JDK-8228336: Refactor native library loading implementation In-Reply-To: <1030f82a-6d7d-daa1-788f-f39848a5022b@oracle.com> References: <00d2029d-ae16-6a9b-5942-cd67aba7c141@oracle.com> <1030f82a-6d7d-daa1-788f-f39848a5022b@oracle.com> Message-ID: <3b892f87-625f-2c10-f56c-ec39d7877027@oracle.com> On 10/03/2020 04:53, Mandy Chung wrote: > Hi David, > > On 3/9/20 7:41 PM, David Holmes wrote: >> That's a core-libs decision but I'm not sure that's a namespace we >> want to increase usage of. >> > > I'm open to other suggestion.? This helper method avoids the call to > doPrivileged when security manager is enabled and I think it's okay to > add this helper method in sun.security.action package. BootLoader defines methods to correspond to the methods defined by ClassLoader so I don't think the loadLibrary method was too bad. Moreover it was very clear when calling BootLoader.loadLibrary that it would attempt to load it from the system path. I don't object to putting this in sun.security.action but it doesn't feel. If it is moved but I think we'll need to find better names so it's clear in the 20+ places where it used (and also avoid the temptation to use it in the modules that aren't mapped to the boot loader). -Alan From Alan.Bateman at oracle.com Wed Mar 11 16:36:35 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Mar 2020 16:36:35 +0000 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> Message-ID: <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> On 08/03/2020 15:42, Denghui Dong wrote: > Hi?Alan?and?Erik, > > Thanks for the review. > > Webrev?has?been?updated?in?http://cr.openjdk.java.net/~ddong/8238665/webrev.02/ > Can you trying moving JavaNioAccess.BufferPool to VM? I think that would help clean this up a bit and avoid having jdk.internal.access types leaking through the jdk.internal.misc.VM interface. -Alan. From naoto.sato at oracle.com Wed Mar 11 16:52:41 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 11 Mar 2020 09:52:41 -0700 Subject: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes In-Reply-To: References: <44EE1961-6729-4F96-8885-439FED393A81@oracle.com> <026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch> Message-ID: <2064fe66-d8aa-d42a-2c24-2ea2544c7cdd@oracle.com> Hi Phillip, Sure. Would you please file Grapheme related issues at bugs.java.com? This is the route for whom doesn't have JBS id to file bugs. Naoto On 3/10/20 11:27 PM, Philipp Kunz wrote: > Hi Naoto, > > Thank you for your reply. I fully agree to your reluctance or inhibition > to change the regex part just along with the jar manifest. > > On the other hand, i'm quite confident that all invocations of > Grapheme.nextBoundary with my previous patch start matching at the > previous boundary and therefore I believe the cited requirement is met > which also the existing tests confirm. Obviously, it is difficult to > prove the correctness or absence of a mistake. In fact I was kind of > hoping someone would get inspired who knows the area better than I do. > Maybe relates to JDK-8216332 or JDK-8046101 to some extent, but I guess > not exactly. > > Shall we file a new bug about a performance issue in regex grapheme > matchers, the performance of which potentially depends more than > linearly and necessarily on the total input sequence size > in?Grapheme.nextBoundary? > Shall we file another bug about an issue of copy and paste in GraphemeTest? > I am not entitled to create new bugs myself but if there were I might > contribute a patch later. > > Regards, > Philipp > > > On Tue, 2020-03-10 at 10:45 -0700, naoto.sato at oracle.com wrote: >> Hi Philipp, >> >> The reason that the current implementation of Grapheme boundary check >> does it is that, some rules require information before the boundary, >> i.e. the rule GB12 in Unicode Segmentation [1] reads: >> >> "do not break between regional indicator (RI) symbols if there is an odd >> number of RI characters *before* the break point." >> >> Of course this itself can be improved, but I am not so keen on modifying >> Grapheme/Pattern code at this time, so using BreakIterator (with >> Locale.US) is more preferred solution to me. >> >> Naoto >> >> [1] >> https://unicode.org/reports/tr29/ >> >> >> >> >> On 3/10/20 12:11 AM, Philipp Kunz wrote: >>> Hi Naoto and everyone, >>> >>> When I tried the regular expression approach you proposed which really >>> looks delightful, ValueUtf8Coding test ran into a timeout, which is why >>> I changed Pattern and Grapheme classes to start the loop in nextBoundary >>> to start at the offset off rather than at the beginning of the character >>> sequence src rendering isBoundary redundant. The changes to Pattern and >>> Grapheme relate only by means of performance and could otherwise be >>> applied seperately as well. I admit I'm not too confident and familiar >>> with the regex parts of the openjdk and would welcome not only thorough >>> review as usual but also any other feedback or thought?shared about the >>> matter. >>> >>> Then I started to wonder about an issue of copy paste between Grapheme >>> and GraphemeTest already out of date and also about some comments in >>> RegExTest and if no more matches shouldn't also be asserted, which also >>> could possibly be changed in a different change but still relate to the >>> actual changes to certain extent. I could not find a way to access >>> UCD_FILES which has no or is in the default package. >>> >>> What about passing the name and the value parameters of >>> Manifest.printLine72 to it as separate parameters? Because names cannot >>> exceed 70 bytes and the allowed characters are limited to ones that are >>> represented with one byte each in UTF-8 the name can/could always be >>> printed without a line break. I don't know if Manifest.println72 can be >>> removed or has to be retained and deprecated for compatibility. >>> >>> See attached patch. >>> >>> Looking forward to receiving any kind of feedback and regards, >>> Philipp >>> >>> >>> >>> >>> >>> On Tue, 2020-02-11 at 14:20 -0800, >>> naoto.sato at oracle.com >>> >>> wrote: >>>> Hi, >>>> >>>> Can the code in Manifest.java be simplified using regex? E.g., >>>> >>>> var gc = Pattern.compile("\\X"); >>>> gc.matcher(line).results() >>>> .map(MatchResult::group) >>>> .forEach( >>>> // print till 72 bytes in UTF-8 >>>> ); >>>> >>>> Just a thought. If BreakIterator is preferred, it should take Locale.US >>>> as an argument to the factory method, so that it would produce the same >>>> result no matter what the default locale is. >>>> >>>> Naoto >>>> >>>> On 2/10/20 1:22 PM, Lance Andersen wrote: >>>>> Hi all, >>>>> >>>>> Here is a webrev for the patch that Philipp is proposing which will make it easier to review: >>>>> http://cr.openjdk.java.net/~lancea/6202130/webrev.00 >>>>> >>>>> < >>>>> http://cr.openjdk.java.net/~lancea/6202130/webrev.00 >>>>> >>>>>> >>>>> >>>>>> On Dec 26, 2019, at 11:50 AM, Philipp Kunz < >>>>>> philipp.kunz at paratix.ch >>>>>> >>>>>> >>>>>> >>>>> philipp.kunz at paratix.ch >>>>>> >>>>>> > >>>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> The specification says, a line break in a manifest can occur beforeor >>>>>> after a Unicode character encoded in UTF-8. >>>>>>> ...> value: SPACE *otherchar newline >>>>>> *continuation> continuation: SPACE *otherchar >>>>>> newline> ...> otherchar: any UTF-8 character except NUL, CR >>>>>> and LF >>>>>> The current implementation breaks manifest lines at 72 bytes regardless >>>>>> ofhow the bytes around the break are part of a sequence of bytes >>>>>> encoding acharacter. Code points may use up to four bytes when encoded >>>>>> in UTF-8.Manifests with line breaks inside of sequences of bytes >>>>>> encoding Unicodecharacters in UTF-8 with more than one bytes not only >>>>>> are invalid UTF-8but also look ugly in text editors.For example, a >>>>>> manifest could look like this: >>>>>> import java.util.jar.Manifest;import java.util.jar.Attributes;import >>>>>> static java.util.jar.Attributes.Name; >>>>>> public class CharacterBrokenDemo1 { public static void main(String[] >>>>>> args) throws Exception{ Manifest mf = new >>>>>> Manifest(); Attributes attrs = >>>>>> mf.getMainAttributes(); attrs.put(Name.MANIFEST_VERSION, >>>>>> "1.0"); attrs.put(new Name("Some-Key"), "Some >>>>>> languages have decorated characters, " + "for >>>>>> example: espa?ol"); // or >>>>>> "espa\u00D1ol" mf.write(System.out); }} >>>>>> Above code produces a result as follows with some unexpected question >>>>>> markswhere the encoding is invalid: >>>>>>> Manifest-Version: 1.0> Some-Key: Some languages have decorated >>>>>> characters, for example: espa?> ?ol >>>>>> This is of course an example written with actual question marks to get >>>>>> a validtext for this message. The trick here is that "Some-Key" to >>>>>> "example :espa"amounts to exactly one byte less encoded in UTF-8 than >>>>>> would fit on one linewith the 72 byte limit so that the subsequent >>>>>> character encoded with two bytesgets broken inside of the sequence of >>>>>> two bytes for this character across acontinuation line break. >>>>>> When decoding the resulting bytes from UTF-8 as one whole string, the >>>>>> twoquestion marks will not fit together again even if the line break >>>>>> with thecontinuation space is removed. However, Manifest::read removes >>>>>> the continuationline breaks ("\r\n ") before decoding the manifest >>>>>> header value from UTF-8 andhence can reproduce the original value. >>>>>> Characters encoded in UTF-8 can not only span up to four bytes for one >>>>>> codepoint each, there are also combining characters or classes thereof >>>>>> or combiningdiacritical marks or whatever the appropriate term could >>>>>> be, that combine morethan one code point into what is usually >>>>>> experienced and referred to as acharacter. >>>>>> The term character really gets ambiguous at this point. I wouldn't know >>>>>> whatthe specification actually refers to with that term "character". So >>>>>> rather thandiving in too much specification or any sorts of theory, >>>>>> let's look at anotherexample: >>>>>> import java.util.jar.Manifest;import java.util.jar.Attributes;import >>>>>> static java.util.jar.Attributes.Name; >>>>>> public class DemoCharacterBroken2 { public static void main(String[] >>>>>> args) throws Exception{ Manifest mf = new >>>>>> Manifest(); Attributes attrs = >>>>>> mf.getMainAttributes(); attrs.put(Name.MANIFEST_VERSION, >>>>>> "1.0"); attrs.put(new Name("Some-Key"), " ".repeat(53) + >>>>>> "Angstro\u0308m"); mf.write(System.out); }} >>>>>> which produces console output as follows: >>>>>>> Manifest-Version: 1.0> Some- >>>>>> Key: Angstro> >>>>>> ?m >>>>>> (In case this does not display well, the diaeresis is on the m on the >>>>>> last line) >>>>>> When the whole Manifest is decoded from UTF-8 as one big single string >>>>>> andcontinuation line breaks are not removed until after UTF-8 decoding >>>>>> the wholemanifest, the diaeresis (umlaut, two points above, u0308) >>>>>> apparently kind ofjumps onto the following letter m because somehow it >>>>>> cannot be combined withthe preceding space. The UTF-8 decoder (all of >>>>>> my editors I tried, not onlyEclipse and its console view, also less, >>>>>> gedit, cat and terminal) somehowtries to fix that but the diaeresis may >>>>>> not necessarily jump back on the "o"where it originally belonged by >>>>>> removing the continuation line break ("\r\n ")after UTF-8 decoding has >>>>>> taken place, at least that did not work for me. >>>>>> Hence, ideally combining diacritical marks should better not be >>>>>> separated fromwhatever they combine with when breaking manifest lines >>>>>> onto a continuationline. Such combinations, however, seem to be >>>>>> unlimited in terms of number ofcode points combining into the same >>>>>> "experienced" character. I was able tofind combinations that not only >>>>>> exceed the limit of 72 bytes per line but alsoexceed the line buffer >>>>>> size of 512 bytes in Manifest::read. These may be ratheruncommon but >>>>>> still possible to my own surprise. >>>>>> Next consideration would then be to remove that limit of 512 bytes per >>>>>> manifestline but exceeding it would make such manifests incompatible >>>>>> with previousManifest::read implementations and is not really an >>>>>> immediately availableoption at the moment. >>>>>> As a compromise, those characters including combining diacritical marks >>>>>> whichcombine only so many code points as that their binarily encoded >>>>>> form in UTF-8remains within a limit of 71 bytes can be written without >>>>>> an interruptingcontinuation line break, which applies to most cases, >>>>>> but not all. I guess thisshould suit practically and realistically to >>>>>> be expected values well. >>>>>> Another possibility would be to allow for characters that are >>>>>> combinations ofmultiple Unicode code points to be kept together in >>>>>> their encoded form in UTF-8up to 512 bytes line length limit when >>>>>> reading minus a space and a line breakamounting to 509 bytes, but that >>>>>> would still not make manifests be representedas valid Unicode in all >>>>>> corner cases and I guess would not probably make a realimprovement in >>>>>> practice over a limit of 71 bytes. >>>>>> Attached is a patch that tries to implement what was described above >>>>>> using aBreakIterator. While it works from a functional point of view, >>>>>> this might beless desirable performance-wise. Alternatively could be >>>>>> considered to do withoutthe BreakIterator and only keep Unicode code >>>>>> points together by not placingline breaks before a continuation byte, >>>>>> which however would not addresscombining diacritical marks as in the >>>>>> second example above. >>>>>> The jar file specification does not explicitly state that manifest >>>>>> should bevalid UTF-8, and they were not always, but it also does not >>>>>> state otherwise,leaving an impression that manifests could be >>>>>> (mis)taken for UTF-8 encodedstrings, which they also are in many or >>>>>> most cases and which has been confusedmany times. At the moment, the >>>>>> only case where a valid manifest is not also avalid UTF-8 encoded >>>>>> string is when a sequence of bytes encoding the samecharacter happens >>>>>> to be interrupted with a continuation line break. To the bestof my >>>>>> knowledge, all other valid manifests are also valid UTF-8 encoded >>>>>> strings. >>>>>> It would be nice, if manifests could be viewed and manipulated with all >>>>>> Unicodecapable editors and not only be parsed correctly with >>>>>> Manifest::read. >>>>>> Any opinions? Would someone sponsor this patch? >>>>>> Regards,Philipp >>>>>> >>>>>> https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#specificationhttps://bugs.openjdk.java.net/browse/JDK-6202130https://bugs.openjdk.java.net/browse/JDK-6443578https://github.com/gradle/gradle/issues/5225https://bugs.openjdk.java.net/browse/JDK-8202525https://en.wikipedia.org/wiki/Combining_character >>>>>> >>>>>> >>>>>> >>>>>> <6202130-manifestutf8linebreak.patch> >>>>> >>>>> < >>>>> http://oracle.com/us/design/oracle-email-sig-198324.gif >>>>> >>>>>> >>>>> < >>>>> http://oracle.com/us/design/oracle-email-sig-198324.gif >>>>> >>>>>> < >>>>> http://oracle.com/us/design/oracle-email-sig-198324.gif >>>>> >>>>>> >>>>> < >>>>> http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance >>>>> >>>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> >>>>> >>>> Lance.Andersen at oracle.com >>>>> >>>>> > >>>>> >>>> Lance.Andersen at oracle.com >>>>> >>>>> >>>>> >>>> Lance.Andersen at oracle.com >>>>> >>>>> > >>>>>> >>>>> >>>>> >>>>> From daniel.fuchs at oracle.com Wed Mar 11 17:25:32 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 Mar 2020 17:25:32 +0000 Subject: Review Request JDK-8228336: Refactor native library loading implementation In-Reply-To: <3b892f87-625f-2c10-f56c-ec39d7877027@oracle.com> References: <00d2029d-ae16-6a9b-5942-cd67aba7c141@oracle.com> <1030f82a-6d7d-daa1-788f-f39848a5022b@oracle.com> <3b892f87-625f-2c10-f56c-ec39d7877027@oracle.com> Message-ID: <93da1c6a-8038-3677-2368-a2a31b307cb8@oracle.com> Hi Mandy, On 11/03/2020 16:10, Alan Bateman wrote: >> I'm open to other suggestion.? This helper method avoids the call to >> doPrivileged when security manager is enabled and I think it's okay to >> add this helper method in sun.security.action package. > BootLoader defines methods to correspond to the methods defined by > ClassLoader so I don't think the loadLibrary method was too bad. > Moreover it was very clear when calling BootLoader.loadLibrary that it > would attempt to load it from the system path. I don't object to putting > this in sun.security.action but it doesn't feel. If it is moved but I > think we'll need to find better names so it's clear in the 20+ places > where it used (and also avoid the temptation to use it in the modules > that aren't mapped to the boot loader). That's probably a stupid question but wouldn't it have been simpler to redefine BootLoader::loadLibrary(String) to call the new LoadLibraryAction rather than removing the method altogether? best regards, -- daniel > > -Alan From mandy.chung at oracle.com Wed Mar 11 17:40:18 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 Mar 2020 10:40:18 -0700 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: References: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> <729bee37-e7b1-6a09-ba42-4d55381cc1fc@oracle.com> Message-ID: <8dab019f-b413-d6bf-6e14-d86d271f8c08@oracle.com> On 3/11/20 12:21 AM, Yangfei (Felix) wrote: >> -----Original Message----- >> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >> Sent: Wednesday, March 11, 2020 3:03 PM >> To: Yangfei (Felix) ; core-libs-dev at openjdk.java.net >> Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible >> between builds >> >> On 11/03/2020 01:11, Yangfei (Felix) wrote: >>> Thanks for reviewing this. Pushed. >> Okay but I think we need to add a test for this. Can you look at >> JLinkReproducibleTest and see if it can be extended to use >> --keep-packaged-modules so that you have the JMOD files in the run-time >> image. > Sure. We will take a look. I created a JBS issue: ??? https://bugs.openjdk.java.net/browse/JDK-8240903 I was expecting this fix be pushed when you have added a regression test.? It's okay as it's pushed. ? Please add one to retrofit that. Mandy From Roger.Riggs at oracle.com Wed Mar 11 20:43:16 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 11 Mar 2020 16:43:16 -0400 Subject: RFR 8240704: CheckHandles.java failed "AssertionError: Handle use increased by more than 10 percent." Message-ID: <358f428c-9507-1a39-b82e-5e8ce8f87be8@oracle.com> Please review a test improvement to avoid counting unexpected handles. The test for 8239893[1]failed when non-test activities used handles. The test is modified to do a warmup phase spawning some processes and cleaning up. It then runs the test to create processes looking for no significant increase in handles. The execution mode is limited to the interpreter to avoid potential side effects of compilation. The error condition was corrected to look only for increases in the number of handles. Previously, it looked for a 10% delta between the minimum and maximum count of handles. Webrev: ??? http://cr.openjdk.java.net/~rriggs/webrev-handlecount-8240704/ Issue: ? https://bugs.openjdk.java.net/browse/JDK-8240704 Thanks, Roger [1] 8239893 Windows handle Leak when starting processes using ProcessBuilder From mandy.chung at oracle.com Wed Mar 11 21:43:28 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 Mar 2020 14:43:28 -0700 (PDT) Subject: Review Request JDK-8228336: Refactor native library loading implementation In-Reply-To: <93da1c6a-8038-3677-2368-a2a31b307cb8@oracle.com> References: <00d2029d-ae16-6a9b-5942-cd67aba7c141@oracle.com> <1030f82a-6d7d-daa1-788f-f39848a5022b@oracle.com> <3b892f87-625f-2c10-f56c-ec39d7877027@oracle.com> <93da1c6a-8038-3677-2368-a2a31b307cb8@oracle.com> Message-ID: <48764f71-93b7-002f-f113-e57bd6c62567@oracle.com> On 3/11/20 10:25 AM, Daniel Fuchs wrote: > Hi Mandy, > > On 11/03/2020 16:10, Alan Bateman wrote: >>> I'm open to other suggestion.? This helper method avoids the call to >>> doPrivileged when security manager is enabled and I think it's okay >>> to add this helper method in sun.security.action package. >> BootLoader defines methods to correspond to the methods defined by >> ClassLoader so I don't think the loadLibrary method was too bad. >> Moreover it was very clear when calling BootLoader.loadLibrary that >> it would attempt to load it from the system path. I don't object to >> putting this in sun.security.action but it doesn't feel. If it is >> moved but I think we'll need to find better names so it's clear in >> the 20+ places where it used (and also avoid the temptation to use it >> in the modules that aren't mapped to the boot loader). > > That's probably a stupid question but wouldn't it have been simpler to > redefine BootLoader::loadLibrary(String) to call the new > LoadLibraryAction rather than removing the method altogether? Thanks for the feedback. I discussed further with Alan.?? Other class and names are no better than BootLoader::loadLibrary.? We agree to keep that helper method as BootLoader::loadLibrary.? The changes due to the renaming is reverted. Updated patch: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8228336/webrev.02/ Mandy From felix.yang at huawei.com Thu Mar 12 07:32:48 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 12 Mar 2020 07:32:48 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: <729bee37-e7b1-6a09-ba42-4d55381cc1fc@oracle.com> References: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> <729bee37-e7b1-6a09-ba42-4d55381cc1fc@oracle.com> Message-ID: Hi Alan, > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Wednesday, March 11, 2020 3:03 PM > To: Yangfei (Felix) ; core-libs-dev at openjdk.java.net > Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible > between builds > > On 11/03/2020 01:11, Yangfei (Felix) wrote: > > Thanks for reviewing this. Pushed. > Okay but I think we need to add a test for this. Can you look at > JLinkReproducibleTest and see if it can be extended to use > --keep-packaged-modules so that you have the JMOD files in the run-time > image. I looked into the JLinkReproducibleTest. There are only two modules contained in lib/modules of the image: main and java.base. I changed the test specifying --keep-packaged-modules: diff -r 8c5697ed51b2 test/jdk/tools/jlink/JLinkReproducibleTest.java --- a/test/jdk/tools/jlink/JLinkReproducibleTest.java Wed Mar 11 08:34:14 2020 +0100 +++ b/test/jdk/tools/jlink/JLinkReproducibleTest.java Thu Mar 12 15:30:45 2020 +0800 @@ -49,6 +49,8 @@ cmd.addAll(List.of( "--module-path", JMODS_DIR.toString() + File.pathSeparator + CLASS_DIR.toString(), "--add-modules", "main", + "--keep-packaged-modules", + image.resolve("jmods").toString(), "--compress=2", "--output", image.toString() )); One extra java.base.jmod file will be emitted for each image created: image-second/jmods/java.base.jmod image-fourth/jmods/java.base.jmod image-third/jmods/java.base.jmod image-first/jmods/java.base.jmod These jmod files are the same with the one located in the JDK install directory. The ModuleHashes attribute is written in java.base.jmod file when building JDK. So the java.base.jmod will always be the same for each run of the JLinkReproducibleTest. Maybe I missed something? Could you please say something more on how extending the test? Thanks, Felix From Alan.Bateman at oracle.com Thu Mar 12 08:47:09 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Mar 2020 08:47:09 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: References: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> <729bee37-e7b1-6a09-ba42-4d55381cc1fc@oracle.com> Message-ID: <8498b24f-270b-0a27-eee5-27ae91c3c610@oracle.com> On 12/03/2020 07:32, Yangfei (Felix) wrote: > : > I looked into the JLinkReproducibleTest. > There are only two modules contained in lib/modules of the image: main and java.base. > I changed the test specifying --keep-packaged-modules: > diff -r 8c5697ed51b2 test/jdk/tools/jlink/JLinkReproducibleTest.java > --- a/test/jdk/tools/jlink/JLinkReproducibleTest.java Wed Mar 11 08:34:14 2020 +0100 > +++ b/test/jdk/tools/jlink/JLinkReproducibleTest.java Thu Mar 12 15:30:45 2020 +0800 > @@ -49,6 +49,8 @@ > cmd.addAll(List.of( > "--module-path", JMODS_DIR.toString() + File.pathSeparator + CLASS_DIR.toString(), > "--add-modules", "main", > + "--keep-packaged-modules", > + image.resolve("jmods").toString(), > "--compress=2", > "--output", image.toString() > )); > > One extra java.base.jmod file will be emitted for each image created: > image-second/jmods/java.base.jmod > image-fourth/jmods/java.base.jmod > image-third/jmods/java.base.jmod > image-first/jmods/java.base.jmod > > These jmod files are the same with the one located in the JDK install directory. > The ModuleHashes attribute is written in java.base.jmod file when building JDK. > So the java.base.jmod will always be the same for each run of the JLinkReproducibleTest. > Maybe I missed something? Could you please say something more on how extending the test? > The `jmod` and `jar` tools can be used to compute the hashes of a set of intimately connected modules. If modules A, B and C are tightly connected, and A requires B and C, then you can use the tooling to create a packaged form of A that includes the hashes of B and C. The hashes are checked at link-time (and in the case of modular JARs on the modular path, at run-time too). So I think you'll need a new test. It might be that running `jmod --hash-modules` with just two dependences is enough to have the entries written to the ModuleHashes attribute in random order. A buddy test to JLinkReproducibleTest that creates a run-time image containing "user modules" that are tightly connected would be a good test. I'm pretty sure that this isn't the last issue related to reproducible builds. Amy is chasing another one that arises with compressed images (jlink --compress=2) that may need work too. -Alan From Alan.Bateman at oracle.com Thu Mar 12 08:55:51 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Mar 2020 08:55:51 +0000 Subject: Review Request JDK-8228336: Refactor native library loading implementation In-Reply-To: <48764f71-93b7-002f-f113-e57bd6c62567@oracle.com> References: <00d2029d-ae16-6a9b-5942-cd67aba7c141@oracle.com> <1030f82a-6d7d-daa1-788f-f39848a5022b@oracle.com> <3b892f87-625f-2c10-f56c-ec39d7877027@oracle.com> <93da1c6a-8038-3677-2368-a2a31b307cb8@oracle.com> <48764f71-93b7-002f-f113-e57bd6c62567@oracle.com> Message-ID: <1566d410-5f58-b1af-04e8-4b3fcc1a36ef@oracle.com> On 11/03/2020 21:43, Mandy Chung wrote: > : > > > I discussed further with Alan.?? Other class and names are no better > than BootLoader::loadLibrary.? We agree to keep that helper method as > BootLoader::loadLibrary.? The changes due to the renaming is reverted. > > Updated patch: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8228336/webrev.02/ This version also renames a method in NativeLibrary so the name is consistent. Looks good to me. -Alan From felix.yang at huawei.com Thu Mar 12 09:30:50 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 12 Mar 2020 09:30:50 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: <8498b24f-270b-0a27-eee5-27ae91c3c610@oracle.com> References: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> <729bee37-e7b1-6a09-ba42-4d55381cc1fc@oracle.com> <8498b24f-270b-0a27-eee5-27ae91c3c610@oracle.com> Message-ID: Hi, > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Thursday, March 12, 2020 4:47 PM > To: Yangfei (Felix) ; core-libs-dev at openjdk.java.net > Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible > between builds > > The `jmod` and `jar` tools can be used to compute the hashes of a set of > intimately connected modules. If modules A, B and C are tightly connected, and > A requires B and C, then you can use the tooling to create a packaged form of A > that includes the hashes of B and C. The hashes are checked at link-time (and in According to [1], if A requires B and C, then I suppose the hashes will be included in B and C instead of A when we do 'jmod hash --module-path jmods --hash-modules .*'. So for the hashed to be stored in A, we may need relations like: B requires A, and C requires A. Am I right? > the case of modular JARs on the modular path, at run-time too). So I think you'll > need a new test. It might be that running `jmod --hash-modules` with just two > dependences is enough to have the entries written to the ModuleHashes > attribute in random order. A buddy test to JLinkReproducibleTest that creates a > run-time image containing "user modules" that are tightly connected would be > a good test. OK, we will try to add a buddy test accordingly. Thanks, Felix [1] https://docs.oracle.com/javase/9/tools/jmod.htm#JSWOR-GUID-0A0BDFF6-BE34-461B-86EF-AAC9A555E2AE From Alan.Bateman at oracle.com Thu Mar 12 09:39:54 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Mar 2020 09:39:54 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: References: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> <729bee37-e7b1-6a09-ba42-4d55381cc1fc@oracle.com> <8498b24f-270b-0a27-eee5-27ae91c3c610@oracle.com> Message-ID: <2f9ff158-da5d-a42e-ec1e-74f114798eec@oracle.com> On 12/03/2020 09:30, Yangfei (Felix) wrote: > : > According to [1], if A requires B and C, then I suppose the hashes will be included in B and C instead of A when we do 'jmod hash --module-path jmods --hash-modules .*'. > So for the hashed to be stored in A, we may need relations like: B requires A, and C requires A. Am I right? > Right, I see there was a typo in my mail, sorry about that. It might help to draw the DAG and then reverse the edges to easily identify the modules where the hashes will be stored. -Alan From daniel.fuchs at oracle.com Thu Mar 12 11:13:22 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 12 Mar 2020 11:13:22 +0000 Subject: RFR 8240704: CheckHandles.java failed "AssertionError: Handle use increased by more than 10 percent." In-Reply-To: <358f428c-9507-1a39-b82e-5e8ce8f87be8@oracle.com> References: <358f428c-9507-1a39-b82e-5e8ce8f87be8@oracle.com> Message-ID: <932738ec-1a35-70e2-aa91-89b779e46ee5@oracle.com> Hi Roger, Looks good to me. If it were my own test I would add a little Thread.sleep() after System.gc() to actually give time to the gc to do something. I have to note however that: 83 final long ERROR_PERCENT = 10; 84 final long ERROR_THRESHOLD = // 10% increase over min to passing max 85 startHandles + ((startHandles + ERROR_PERCENT - 1) / ERROR_PERCENT); is a bit misleading. IMO it only works because ERROR_PERCENT = 10; and 10 * 10 = 100; If you change it to ERROR_PERCENT = 1; for instance, then you end up with allowing 100% of errors (and not 1%). cheers, -- daniel On 11/03/2020 20:43, Roger Riggs wrote: > Please review a test improvement to avoid counting unexpected handles. > The test for 8239893[1]failed when non-test activities used handles. > > The test is modified to do a warmup phase spawning some processes and > cleaning up. > It then runs the test to create processes looking for no significant > increase in handles. > The execution mode is limited to the interpreter to avoid potential side > effects of compilation. > The error condition was corrected to look only for increases in the > number of handles. > Previously, it looked for a 10% delta between the minimum and maximum > count of handles. > > Webrev: > ??? http://cr.openjdk.java.net/~rriggs/webrev-handlecount-8240704/ > > Issue: > ? https://bugs.openjdk.java.net/browse/JDK-8240704 > > Thanks, Roger > > [1] 8239893 Windows > handle Leak when starting processes using ProcessBuilder > From felix.yang at huawei.com Thu Mar 12 13:42:52 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 12 Mar 2020 13:42:52 +0000 Subject: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds In-Reply-To: <2f9ff158-da5d-a42e-ec1e-74f114798eec@oracle.com> References: <9df921a1-b704-7940-3927-38961a9b09d2@oracle.com> <729bee37-e7b1-6a09-ba42-4d55381cc1fc@oracle.com> <8498b24f-270b-0a27-eee5-27ae91c3c610@oracle.com> <2f9ff158-da5d-a42e-ec1e-74f114798eec@oracle.com> Message-ID: Hi, > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Thursday, March 12, 2020 5:40 PM > To: Yangfei (Felix) ; core-libs-dev at openjdk.java.net > Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible > between builds > > On 12/03/2020 09:30, Yangfei (Felix) wrote: > > So for the hashed to be stored in A, we may need relations like: B requires A, > and C requires A. Am I right? > > > Right, I see there was a typo in my mail, sorry about that. It might help to draw > the DAG and then reverse the edges to easily identify the modules where the > hashes will be stored. > We did a quick try with three modules. The new test is uploaded to [1]. Two problems here: a> hash values are different for two different test run. This is illustrate in [2]. I think this is introduced by the SHA-256 algorithm. I didn't mention that our local consistency check is carried out in a specialized environment which avoids such a problem. This means we cannot compare the jmod files with Files.mismatch directly in regular testing environment. b> Looks like the reported issue cannot be reproduced by a small number of modules. We tried [1] many times and it seems that the order of the two module hashes is stable. Note: java.base module records hashes of 67 other modules. Suggestions? [1] https://bugs.openjdk.java.net/secure/attachment/87281/ModuleHashOrderTest.java [2] Classfile /home/sunjianye/openjdk13-community/jdk/JTwork/scratch/jmods-first/cl| Classfile /home/sunjianye/openjdk13-community/jdk/JTwork/scratch/jmods-second/ Last modified Mar 12, 2020; size 399 bytes | Last modified Mar 12, 2020; size 399 bytes SHA-256 checksum 1a8ea671cd45ffb96287d690e383a0f80303111ac51519271a097007b8e0| SHA-256 checksum b7b0ce1af32eb74d2185e4feced2f25ae23ef2b3830b1fe2b7471ba9b34 Compiled from "module-info.java" | Compiled from "module-info.java" module ma | module ma minor version: 0 | minor version: 0 major version: 57 | major version: 57 flags: (0x8000) ACC_MODULE | flags: (0x8000) ACC_MODULE this_class: #2 // "module-info" | this_class: #2 // "module-info" + +-- 51 lines: super_class: + +#0--------------------------------------------------|+ +-- 51 lines: + +super_class: #0------------------------------------------------- #17 // src.ma | #17 // src.ma ModuleHashes: | ModuleHashes: algorithm: #25 // SHA-256 | algorithm: #25 // SHA-256 2 // hashes | 2 // hashes #27 // mb | #27 // mb hash_length: 32 | hash_length: 32 hash: [633a60ff4fa542d082dba41ced181633385574c6a801c843a23538559b63c239] | hash: [951bb41ce54aa1bc93edde4226eeaf38d73f6a54b9e9e150c73e8a48d109de57] #29 // mc | #29 // mc hash_length: 32 | hash_length: 32 hash: [815cb047f93ec3d22ae2889d32a7f687e00b41507abbb1b66a27d87c5c38459a] | hash: [e2c37c902bf8b84ebbb11a765b365ba0fc241772596a8e4091e0345d596a86e5] From Roger.Riggs at oracle.com Thu Mar 12 14:36:30 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 12 Mar 2020 10:36:30 -0400 Subject: RFR 8240957: Clarify BadAttributeValueExpException readObject method Message-ID: <424eacbb-cef8-5165-516f-dee6736a8b24@oracle.com> The change for 8232622: Technical debt in BadAttributeValueExpException failed to document the behavior of the readObject method to ensure compatibility. Please review the javadoc for the readObject method. Webrev: ?? http://cr.openjdk.java.net/~rriggs/webrev-readobject-doc-8240957/ Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8232622 [2] CSR: https://bugs.openjdk.java.net/browse/JDK-8240314 From brian.burkhalter at oracle.com Thu Mar 12 14:59:16 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 12 Mar 2020 07:59:16 -0700 Subject: RFR 8240957: Clarify BadAttributeValueExpException readObject method In-Reply-To: <424eacbb-cef8-5165-516f-dee6736a8b24@oracle.com> References: <424eacbb-cef8-5165-516f-dee6736a8b24@oracle.com> Message-ID: Hi Roger, Looks fine. Brian > On Mar 12, 2020, at 7:36 AM, Roger Riggs wrote: > > The change for 8232622: Technical debt in BadAttributeValueExpException > failed to document the behavior of the readObject method to ensure compatibility. > Please review the javadoc for the readObject method. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-readobject-doc-8240957/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8232622 > [2] CSR: https://bugs.openjdk.java.net/browse/JDK-8240314 From naoto.sato at oracle.com Thu Mar 12 14:59:20 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 12 Mar 2020 07:59:20 -0700 Subject: [15] RFR: 8216332: Grapheme regex does not work with emoji sequences In-Reply-To: <60545389-a3ac-eddb-2c5e-fe6ef67ae1c7@oracle.com> References: <60545389-a3ac-eddb-2c5e-fe6ef67ae1c7@oracle.com> Message-ID: <2789d6d3-4b18-5f84-e4e6-7e7a357ff3f4@oracle.com> Ping. Any takers? Naoto On 3/5/20 8:58 AM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8216332 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8216332/webrev.00/ > > Before this fix, the rule GB11 (Do not break within emoji modifier > sequences or emoji zwj sequences [1]) was only applied once, and was > ignored thereafter for the repeated possible rule candidates. The fix is > to simply stop resetting the GB11 mode. > > Naoto > > [1] https://unicode.org/reports/tr29/#GB11 From Roger.Riggs at oracle.com Thu Mar 12 15:11:19 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 12 Mar 2020 11:11:19 -0400 Subject: RFR 8240704: CheckHandles.java failed "AssertionError: Handle use increased by more than 10 percent." In-Reply-To: <932738ec-1a35-70e2-aa91-89b779e46ee5@oracle.com> References: <358f428c-9507-1a39-b82e-5e8ce8f87be8@oracle.com> <932738ec-1a35-70e2-aa91-89b779e46ee5@oracle.com> Message-ID: Hi Daniel, Good point about the sleep and the percent computation. Fixed both, its a bad idea to leave buggy code around to mislead or be copied. Updated webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-handlecount-8240704-1/ Thanks, Roger On 3/12/20 7:13 AM, Daniel Fuchs wrote: > Hi Roger, > > Looks good to me. If it were my own test I would add a little > Thread.sleep() after System.gc() to actually give time to the > gc to do something. > > I have to note however that: > > ?83???????? final long ERROR_PERCENT = 10; > ?84???????? final long ERROR_THRESHOLD = // 10% increase over min to > passing max > ?85???????????????? startHandles + ((startHandles + ERROR_PERCENT - 1) > / ERROR_PERCENT); > > is a bit misleading. IMO it only works because ERROR_PERCENT = 10; and > 10 * 10 = 100; If you change it to ERROR_PERCENT = 1; for instance, then > you end up with allowing 100% of errors (and not 1%). > > cheers, > > -- daniel > > On 11/03/2020 20:43, Roger Riggs wrote: >> Please review a test improvement to avoid counting unexpected handles. >> The test for 8239893[1]failed when non-test activities used handles. >> >> The test is modified to do a warmup phase spawning some processes and >> cleaning up. >> It then runs the test to create processes looking for no significant >> increase in handles. >> The execution mode is limited to the interpreter to avoid potential >> side effects of compilation. >> The error condition was corrected to look only for increases in the >> number of handles. >> Previously, it looked for a 10% delta between the minimum and maximum >> count of handles. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-handlecount-8240704/ >> >> Issue: >> ?? https://bugs.openjdk.java.net/browse/JDK-8240704 >> >> Thanks, Roger >> >> [1] 8239893 >> Windows handle Leak when starting processes using ProcessBuilder >> > From Roger.Riggs at oracle.com Thu Mar 12 15:19:32 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 12 Mar 2020 11:19:32 -0400 Subject: [15] RFR: 8216332: Grapheme regex does not work with emoji sequences In-Reply-To: <60545389-a3ac-eddb-2c5e-fe6ef67ae1c7@oracle.com> References: <60545389-a3ac-eddb-2c5e-fe6ef67ae1c7@oracle.com> Message-ID: Hi Naoto, The fix looks fine and the set of test cases looks good too. Roger On 3/5/20 11:58 AM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8216332 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8216332/webrev.00/ > > Before this fix, the rule GB11 (Do not break within emoji modifier > sequences or emoji zwj sequences [1]) was only applied once, and was > ignored thereafter for the repeated possible rule candidates. The fix > is to simply stop resetting the GB11 mode. > > Naoto > > [1] https://unicode.org/reports/tr29/#GB11 From daniel.fuchs at oracle.com Thu Mar 12 15:52:59 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 12 Mar 2020 15:52:59 +0000 Subject: RFR 8240704: CheckHandles.java failed "AssertionError: Handle use increased by more than 10 percent." In-Reply-To: References: <358f428c-9507-1a39-b82e-5e8ce8f87be8@oracle.com> <932738ec-1a35-70e2-aa91-89b779e46ee5@oracle.com> Message-ID: <8d6b06da-0c17-bf9c-e1e7-9d85d76d97ba@oracle.com> Looks good Roger! best regards, -- daniel On 12/03/2020 15:11, Roger Riggs wrote: > Hi Daniel, > > Good point about the sleep and the percent computation. > Fixed both, its a bad idea to leave buggy code around to mislead or be > copied. > > Updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-handlecount-8240704-1/ > > Thanks, Roger From jonathan.gibbons at oracle.com Thu Mar 12 20:50:01 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 Mar 2020 13:50:01 -0700 Subject: RFR: [small,docs] JDK-8240971 Fix CSS styles in some doc comments Message-ID: Please review a simple fix regarding the non-standard use of some CSS in some doc comments. From the JBS Description: Recently, for the display of javadoc block tags, javadoc changed from using an inconsistent set of CSS class names on the generated 'dt' elements to using a single new name ("notes") on the enclosing 'dl' element. There are a few (4) places in the main JDK code where the old-style names were used explicitly in doc comments, in order to emulate the appearance of a list of block tags. These use-sites should be fixed up. They are in the following files: open/src/java.base/share/classes/module-info.java open/src/java.se/share/classes/module-info.java open/src/java.management.rmi/share/classes/module-info.java open/src/jdk.jconsole/share/classes/module-info.java In addition, these four files used the style attribute to force the font to be used. The font is now set in the standard CSS for "notes", and so the local use of a "style" attribute is no longer necessary. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8240971 Webrev: http://cr.openjdk.java.net/~jjg/8240971/webrev.00/index.html API: http://cr.openjdk.java.net/~jjg/8240971/api.00/index.html From mandy.chung at oracle.com Thu Mar 12 20:53:31 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 Mar 2020 13:53:31 -0700 Subject: RFR: [small, docs] JDK-8240971 Fix CSS styles in some doc comments In-Reply-To: References: Message-ID: <3b7e1339-a173-9739-fa8c-f603304a5886@oracle.com> This change looks okay. Mandy On 3/12/20 1:50 PM, Jonathan Gibbons wrote: > Please review a simple fix regarding the non-standard use of some CSS > in some doc comments. > > From the JBS Description: > > Recently, for the display of javadoc block tags, javadoc changed from > using an inconsistent set of CSS class names on the generated 'dt' > elements to using a single new name ("notes") on the enclosing 'dl' > element. > > There are a few (4) places in the main JDK code where the old-style > names were used explicitly in doc comments, in order to emulate the > appearance of a list of block tags. These use-sites should be fixed > up. They are in the following files: > > open/src/java.base/share/classes/module-info.java > open/src/java.se/share/classes/module-info.java > open/src/java.management.rmi/share/classes/module-info.java > open/src/jdk.jconsole/share/classes/module-info.java > > In addition, these four files used the style attribute to force the > font to be used. The font is now set in the standard CSS for "notes", > and so the local use of a "style" attribute is no longer necessary. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8240971 > Webrev: http://cr.openjdk.java.net/~jjg/8240971/webrev.00/index.html > API: http://cr.openjdk.java.net/~jjg/8240971/api.00/index.html > From alexey.menkov at oracle.com Fri Mar 13 00:33:21 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 12 Mar 2020 17:33:21 -0700 Subject: RFR: [small, docs] JDK-8240971 Fix CSS styles in some doc comments In-Reply-To: <3b7e1339-a173-9739-fa8c-f603304a5886@oracle.com> References: <3b7e1339-a173-9739-fa8c-f603304a5886@oracle.com> Message-ID: +1 --alex On 03/12/2020 13:53, Mandy Chung wrote: > This change looks okay. > > Mandy > > On 3/12/20 1:50 PM, Jonathan Gibbons wrote: >> Please review a simple fix regarding the non-standard use of some CSS >> in some doc comments. >> >> From the JBS Description: >> >> Recently, for the display of javadoc block tags, javadoc changed from >> using an inconsistent set of CSS class names on the generated 'dt' >> elements to using a single new name ("notes") on the enclosing 'dl' >> element. >> >> There are a few (4) places in the main JDK code where the old-style >> names were used explicitly in doc comments, in order to emulate the >> appearance of a list of block tags. These use-sites should be fixed >> up. They are in the following files: >> >> open/src/java.base/share/classes/module-info.java >> open/src/java.se/share/classes/module-info.java >> open/src/java.management.rmi/share/classes/module-info.java >> open/src/jdk.jconsole/share/classes/module-info.java >> >> In addition, these four files used the style attribute to force the >> font to be used. The font is now set in the standard CSS for "notes", >> and so the local use of a "style" attribute is no longer necessary. >> >> -- Jon >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8240971 >> Webrev: http://cr.openjdk.java.net/~jjg/8240971/webrev.00/index.html >> API: http://cr.openjdk.java.net/~jjg/8240971/api.00/index.html >> > From xu.y.yin at oracle.com Fri Mar 13 08:28:22 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Fri, 13 Mar 2020 16:28:22 +0800 Subject: [15] RFR: 8202117: com/sun/jndi/ldap/RemoveNamingListenerTest.java fails intermittently: Connection reset Message-ID: Hello, Please review following changes to try to fix intermittent failure of test com/sun/jndi/ldap/RemoveNamingListenerTest.java, thanks Bug: https://bugs.openjdk.java.net/browse/JDK-8202117 Webrev: http://cr.openjdk.java.net/~xyin/8202117/webrev.00/ According to failure logs, test already run done and give a pass message, but test framework caught ?java.lang.RuntimeException: java.net.SocketException: Connection reset? from other thread during test end, go through the test code, LDAPServerHandler thread may throw such exception in specific case. This change will replace test itself implemented TestLDAPServer/LDAPServerHandler with customized BaseLdapServer to fix the corner. I had run the changed test on 4 platforms for total 600 times, no failure observed. Thanks, Chris From vyommani at gmail.com Fri Mar 13 10:17:55 2020 From: vyommani at gmail.com (Vyom Tiwari) Date: Fri, 13 Mar 2020 15:47:55 +0530 Subject: [15] RFR: 8202117: com/sun/jndi/ldap/RemoveNamingListenerTest.java fails intermittently: Connection reset In-Reply-To: References: Message-ID: Hi Chris, Thanks for taking care of this issue, changes looks OK to me. I am happy to see that we are removing the lot's of duplicate "DummyServer" from individual test cases and using the "BaseLdapServer" test-server instead. Thanks, Vyom On Fri, Mar 13, 2020 at 1:59 PM Chris Yin wrote: > Hello, > > Please review following changes to try to fix intermittent failure of test > com/sun/jndi/ldap/RemoveNamingListenerTest.java, thanks > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202117 > Webrev: http://cr.openjdk.java.net/~xyin/8202117/webrev.00/ > > > According to failure logs, test already run done and give a pass message, > but test framework caught ?java.lang.RuntimeException: > java.net.SocketException: Connection reset? from other thread during test > end, go through the test code, LDAPServerHandler thread may throw such > exception in specific case. This change will replace test itself > implemented TestLDAPServer/LDAPServerHandler with customized BaseLdapServer > to fix the corner. I had run the changed test on 4 platforms for total 600 > times, no failure observed. > > Thanks, > Chris -- Thanks, Vyom From daniel.fuchs at oracle.com Fri Mar 13 11:51:38 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 13 Mar 2020 11:51:38 +0000 Subject: [15] RFR: 8202117: com/sun/jndi/ldap/RemoveNamingListenerTest.java fails intermittently: Connection reset In-Reply-To: References: Message-ID: <15783e53-6100-e257-b666-b53f91f8aaff@oracle.com> Hi Chris, This looks fine to me too. Thanks for taking care of this issue. A potential issue I see is that the test might fail if "localhost" does not resolve to the loopback address - but you would likely get a "Connection refused" in that case. One possibility to get that out of the way could be to use the URIBuilder: * @library lib/ /test/lib ... URI providerURI = URIBuilder.newBuilder() .scheme("ldap") .loopback() .port(server.getLocalPort()) .path("/o=example") .build(); ... 59 env.put(Context.PROVIDER_URL, providerURI.toString()); best regards, -- daniel On 13/03/2020 08:28, Chris Yin wrote: > Hello, > > Please review following changes to try to fix intermittent failure of test com/sun/jndi/ldap/RemoveNamingListenerTest.java, thanks > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202117 > Webrev: http://cr.openjdk.java.net/~xyin/8202117/webrev.00/ > > > According to failure logs, test already run done and give a pass message, but test framework caught ?java.lang.RuntimeException: java.net.SocketException: Connection reset? from other thread during test end, go through the test code, LDAPServerHandler thread may throw such exception in specific case. This change will replace test itself implemented TestLDAPServer/LDAPServerHandler with customized BaseLdapServer to fix the corner. I had run the changed test on 4 platforms for total 600 times, no failure observed. > > Thanks, > Chris > From denghui.ddh at alibaba-inc.com Fri Mar 13 14:54:35 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Fri, 13 Mar 2020 22:54:35 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIzODY2NTogQWRkIEpGUiBldmVudCBmb3IgZGlyZWN0IG1lbW9yeSBzdGF0?= =?UTF-8?B?aXN0aWNz?= In-Reply-To: <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> , <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> Message-ID: <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> Good suggestion, moved. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.03/ Thanks, Denghui Dong ------------------------------------------------------------------ From:Alan Bateman Send Time:2020?3?12?(???) 00:36 To:???(??) ; Erik Gahlin Cc:hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics On 08/03/2020 15:42, Denghui Dong wrote: Hi Alan and Erik, Thanks for the review. Webrev has been updated in http://cr.openjdk.java.net/~ddong/8238665/webrev.02/ Can you trying moving JavaNioAccess.BufferPool to VM? I think that would help clean this up a bit and avoid having jdk.internal.access types leaking through the jdk.internal.misc.VM interface. -Alan. From pavel.rappo at oracle.com Fri Mar 13 15:42:03 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 13 Mar 2020 15:42:03 +0000 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments Message-ID: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ This is a documentation cleanup. There are no code changes involved, and the changes in documentation are mostly trivial. The following packages are affected: java.lang, java.nio.file, java.nio.file.attribute, java.security, java.time.chrono, java.time.temporal, java.util, java.util.regex, java.util.stream, javax.crypto, javax.security.cert, javax.tools That said, there are two changes that I'd prefer to be carefully reviewed by the experts in the corresponding areas. The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and supported for the sake of backward compatibility. Sadly, we have a number of those in OpenJDK. Even though I performed reasonable checks, the proposed fix should better be verified by the security folk. The second one is for the doc comment for the java.util.stream.Stream.collect method. @apiNote The following will accumulate strings into an ArrayList: List asList = stringStream.collect(Collectors.toList()); Given that the spec for Collectors.toList() clearly says that ...There are no guarantees on the type, mutability, serializability, or thread-safety of the List returned;... I'd assume that @apiNote should be fixed as proposed. -Pavel P.S. Apologies for spamming multiple mailing lists. From pavel.rappo at oracle.com Fri Mar 13 16:26:54 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 13 Mar 2020 16:26:54 +0000 Subject: RFR: [small, docs] JDK-8240971 Fix CSS styles in some doc comments In-Reply-To: References: Message-ID: <2216FA2C-C369-4FF1-B0D2-800D3AD59B1B@oracle.com> This is really nice. Incidentally, it also makes https://bugs.openjdk.java.net/browse/JDK-8234395 less relevant. -Pavel > On 12 Mar 2020, at 20:50, Jonathan Gibbons wrote: > > Please review a simple fix regarding the non-standard use of some CSS in some doc comments. > > From the JBS Description: > > Recently, for the display of javadoc block tags, javadoc changed from using an inconsistent set of CSS class names on the generated 'dt' elements to using a single new name ("notes") on the enclosing 'dl' element. > > There are a few (4) places in the main JDK code where the old-style names were used explicitly in doc comments, in order to emulate the appearance of a list of block tags. These use-sites should be fixed up. They are in the following files: > > open/src/java.base/share/classes/module-info.java > open/src/java.se/share/classes/module-info.java > open/src/java.management.rmi/share/classes/module-info.java > open/src/jdk.jconsole/share/classes/module-info.java > > In addition, these four files used the style attribute to force the font to be used. The font is now set in the standard CSS for "notes", and so the local use of a "style" attribute is no longer necessary. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8240971 > Webrev: http://cr.openjdk.java.net/~jjg/8240971/webrev.00/index.html > API: http://cr.openjdk.java.net/~jjg/8240971/api.00/index.html > From jonathan.gibbons at oracle.com Fri Mar 13 16:34:04 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Mar 2020 09:34:04 -0700 Subject: RFR: [small, docs] JDK-8240971 Fix CSS styles in some doc comments In-Reply-To: <2216FA2C-C369-4FF1-B0D2-800D3AD59B1B@oracle.com> References: <2216FA2C-C369-4FF1-B0D2-800D3AD59B1B@oracle.com> Message-ID: <158d778e-c70d-b5df-b8ab-2296fea609ac@oracle.com> At some point, we should separate JDK-specific definitions from javadoc-general definitions, using a separate stylesheet. -- Jon On 3/13/20 9:26 AM, Pavel Rappo wrote: > This is really nice. Incidentally, it also makes > > https://bugs.openjdk.java.net/browse/JDK-8234395 > > less relevant. > > -Pavel > >> On 12 Mar 2020, at 20:50, Jonathan Gibbons wrote: >> >> Please review a simple fix regarding the non-standard use of some CSS in some doc comments. >> >> From the JBS Description: >> >> Recently, for the display of javadoc block tags, javadoc changed from using an inconsistent set of CSS class names on the generated 'dt' elements to using a single new name ("notes") on the enclosing 'dl' element. >> >> There are a few (4) places in the main JDK code where the old-style names were used explicitly in doc comments, in order to emulate the appearance of a list of block tags. These use-sites should be fixed up. They are in the following files: >> >> open/src/java.base/share/classes/module-info.java >> open/src/java.se/share/classes/module-info.java >> open/src/java.management.rmi/share/classes/module-info.java >> open/src/jdk.jconsole/share/classes/module-info.java >> >> In addition, these four files used the style attribute to force the font to be used. The font is now set in the standard CSS for "notes", and so the local use of a "style" attribute is no longer necessary. >> >> -- Jon >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8240971 >> Webrev: http://cr.openjdk.java.net/~jjg/8240971/webrev.00/index.html >> API: http://cr.openjdk.java.net/~jjg/8240971/api.00/index.html >> From brian.burkhalter at oracle.com Fri Mar 13 17:28:24 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 13 Mar 2020 10:28:24 -0700 Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF In-Reply-To: <575CE79A-D60C-4550-B74D-EDA1FAFBAF2F@oracle.com> References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com> <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com> <14E6EF7F-C01F-4407-B865-32089266DC28@oracle.com> <665e81fc-5136-2cf6-748b-6c6f448cfc16@oracle.com> <575CE79A-D60C-4550-B74D-EDA1FAFBAF2F@oracle.com> Message-ID: <05887BD3-F7F1-4DA6-86EA-82929BC26874@oracle.com> An updated webrev is at [1] and a CSR has been filed [2]. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8235792/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8241020 > On Mar 6, 2020, at 11:13 AM, Brian Burkhalter wrote: > > Thanks, Roger. I?ll let it hang until next week and then file a CSR. > > Brian > >> On Mar 6, 2020, at 10:49 AM, Roger Riggs wrote: >> >> :) Still looks fine. >> >> On 3/5/20 4:53 PM, Brian Burkhalter wrote: >>> Might anyone else have any comments on this thread the original post in which was [1]. >>> >>> Thanks, >>> >>> Brian >>> >>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064417.html From huizhe.wang at oracle.com Fri Mar 13 17:32:06 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 13 Mar 2020 10:32:06 -0700 Subject: RFR [15/java.xml] 8240982 Incorrect copyright header in BCEL 6.4.1 sources Message-ID: Please review a quick fix for the missing commas after the 2nd year in the copyright header: diff --git a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java --- a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java +++ b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. ? */ ?/* ? * Licensed to the Apache Software Foundation (ASF) under one or more diff --git a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java --- a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java +++ b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. ? */ ?/* ? * Licensed to the Apache Software Foundation (ASF) under one or more diff --git a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java --- a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java +++ b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. ? */ ?/* ? * Licensed to the Apache Software Foundation (ASF) under one or more Thanks, Joe From naoto.sato at oracle.com Fri Mar 13 17:35:25 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 13 Mar 2020 10:35:25 -0700 Subject: RFR [15/java.xml] 8240982 Incorrect copyright header in BCEL 6.4.1 sources In-Reply-To: References: Message-ID: Looks good, Joe. Naoto On 3/13/20 10:32 AM, Joe Wang wrote: > Please review a quick fix for the missing commas after the 2nd year in > the copyright header: > > diff --git > a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java > b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java > --- > a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java > +++ > b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights > reserved. > ? */ > ?/* > ? * Licensed to the Apache Software Foundation (ASF) under one or more > diff --git > a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java > b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java > > --- > a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java > > +++ > b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java > > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights > reserved. > ? */ > ?/* > ? * Licensed to the Apache Software Foundation (ASF) under one or more > diff --git > a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java > b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java > > --- > a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java > > +++ > b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java > > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights > reserved. > ? */ > ?/* > ? * Licensed to the Apache Software Foundation (ASF) under one or more > > > > Thanks, > Joe > From lance.andersen at oracle.com Fri Mar 13 17:42:04 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 13 Mar 2020 13:42:04 -0400 Subject: RFR [15/java.xml] 8240982 Incorrect copyright header in BCEL 6.4.1 sources In-Reply-To: References: Message-ID: <8CCAB4DE-56F9-429C-B804-A927E7FBB6AA@oracle.com> +1 > On Mar 13, 2020, at 1:32 PM, Joe Wang wrote: > > Please review a quick fix for the missing commas after the 2nd year in the copyright header: > > diff --git a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java > --- a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java > +++ b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. > */ > /* > * Licensed to the Apache Software Foundation (ASF) under one or more > diff --git a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java > --- a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java > +++ b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. > */ > /* > * Licensed to the Apache Software Foundation (ASF) under one or more > diff --git a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java > --- a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java > +++ b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. > */ > /* > * Licensed to the Apache Software Foundation (ASF) under one or more > > > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Roger.Riggs at oracle.com Fri Mar 13 18:15:10 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 13 Mar 2020 14:15:10 -0400 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: Looks fine. On 3/13/20 11:42 AM, Pavel Rappo wrote: > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > From mandy.chung at oracle.com Fri Mar 13 18:16:51 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Mar 2020 11:16:51 -0700 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading Message-ID: Webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.00/ This is a follow-up task for Panama to allow explicit unloading of native library after JDK-8228336.? `NativeLibraries` associated with a class loader has the capability to auto unload native libraries when the class loader is reclaimed.? This adds a new `NativeLibraries::unload` method that provides the ability to unload a native library on request.? This only allows? `NativeLibraries` of no relationship with a class loader where auto unloading is disabled. Thanks Mandy From huizhe.wang at oracle.com Fri Mar 13 19:13:04 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 13 Mar 2020 12:13:04 -0700 Subject: RFR [15/java.xml] 8240982 Incorrect copyright header in BCEL 6.4.1 sources In-Reply-To: <8CCAB4DE-56F9-429C-B804-A927E7FBB6AA@oracle.com> References: <8CCAB4DE-56F9-429C-B804-A927E7FBB6AA@oracle.com> Message-ID: Thanks Naoto, Lance! -Joe On 3/13/20 10:42 AM, Lance Andersen wrote: > +1 > >> On Mar 13, 2020, at 1:32 PM, Joe Wang > > wrote: >> >> Please review a quick fix for the missing commas after the 2nd year >> in the copyright header: >> >> diff --git >> a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java >> b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java >> --- >> a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java >> +++ >> b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All >> rights reserved. >> ? */ >> ?/* >> ? * Licensed to the Apache Software Foundation (ASF) under one or more >> diff --git >> a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java >> b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java >> --- >> a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java >> +++ >> b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All >> rights reserved. >> ? */ >> ?/* >> ? * Licensed to the Apache Software Foundation (ASF) under one or more >> diff --git >> a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java >> b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java >> --- >> a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java >> +++ >> b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All >> rights reserved. >> ? */ >> ?/* >> ? * Licensed to the Apache Software Foundation (ASF) under one or more >> >> >> >> Thanks, >> Joe >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From naoto.sato at oracle.com Fri Mar 13 20:25:11 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 13 Mar 2020 13:25:11 -0700 Subject: [15] RFR: 8240626: Some of the java.time.chrono.Eras return empty display name for some styles and locales Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8240626 The proposed chageset is located at: https://cr.openjdk.java.net/~naoto/8240626/webrev.00/ In some locales, CLDR only provides partial translations of era names, e.g., only HEISEI and REIWA are provided for Japanese Calendar in Greek locale. CLDRConverter needs to supplement those missing translations from parent locales. Naoto From huizhe.wang at oracle.com Sat Mar 14 00:00:57 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 13 Mar 2020 17:00:57 -0700 Subject: [15] RFR: 8240626: Some of the java.time.chrono.Eras return empty display name for some styles and locales In-Reply-To: References: Message-ID: <4bc10314-09c5-edbf-71e8-f9ab425985ab@oracle.com> Hi Naoto, The existing tests verifies that a display name matches an expected value. I wonder if you'd want to do a bit more than the Boolean assertion with a similar approach as the existing test, that is, check that the fallback values/alias names match expected names. Best, Joe On 3/13/20 1:25 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8240626 > > The proposed chageset is located at: > > https://cr.openjdk.java.net/~naoto/8240626/webrev.00/ > > In some locales, CLDR only provides partial translations of era names, > e.g., only HEISEI and REIWA are provided for Japanese Calendar in > Greek locale. CLDRConverter needs to supplement those missing > translations from parent locales. > > Naoto From akashche at redhat.com Sat Mar 14 00:08:11 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Sat, 14 Mar 2020 00:08:11 +0000 Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found Message-ID: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com> Hi, Based on these maillist threads: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065076.html https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063643.html I am looking for comments and suggestions, whether the following change to JarURLConnection.getJarFile() behaviour may be acceptable: If, during connect() call, jarFile itself was created successfully, but access to (non-existent) jarEntry failed - return this jarFile to caller instead of throwing exception. bug: https://bugs.openjdk.java.net/browse/JDK-8132359 webrev: http://cr.openjdk.java.net/~akasko/jdk/8132359/webrev.00/ This change also allows to fix JDK-8232854 with the minimal change to URLClassPath (included with the patch). This change doesn't cause regression failures in java/net. This change causes one compatibility failure, when getManifest() doesn't throw expected IOException when URL points to non-existent class inside JAR. -- -Alex From ivan.gerasimov at oracle.com Sat Mar 14 02:03:56 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 13 Mar 2020 19:03:56 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> Hi Pavel! Can this please be combined with my collection of typos? http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ Just to save cycles on reviewing :) With kind regards, Ivan On 3/13/20 8:42 AM, Pavel Rappo wrote: > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > -- With kind regards, Ivan Gerasimov From naoto.sato at oracle.com Sat Mar 14 02:16:35 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 13 Mar 2020 19:16:35 -0700 Subject: [15] RFR: 8240626: Some of the java.time.chrono.Eras return empty display name for some styles and locales In-Reply-To: <4bc10314-09c5-edbf-71e8-f9ab425985ab@oracle.com> References: <4bc10314-09c5-edbf-71e8-f9ab425985ab@oracle.com> Message-ID: <244b0da6-f2eb-d83f-30b3-b59a2f8e8fb4@oracle.com> Hi Joe, Thank you for the review. Since those names are filled at the JDK build time, there is no way to confirm the localized ones are from the locale itself or its parents, unless parsing CLDR's source XML files in the test at the runtime. I think it is enough to just ensure there's no empty names returned at the runtime, IMO. Naoto On 3/13/20 5:00 PM, Joe Wang wrote: > Hi Naoto, > > The existing tests verifies that a display name matches an expected > value. I wonder if you'd want to do a bit more than the Boolean > assertion with a similar approach as the existing test, that is, check > that the fallback values/alias names match expected names. > > Best, > Joe > > > On 3/13/20 1:25 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8240626 >> >> The proposed chageset is located at: >> >> https://cr.openjdk.java.net/~naoto/8240626/webrev.00/ >> >> In some locales, CLDR only provides partial translations of era names, >> e.g., only HEISEI and REIWA are provided for Japanese Calendar in >> Greek locale. CLDRConverter needs to supplement those missing >> translations from parent locales. >> >> Naoto > From weijun.wang at oracle.com Sat Mar 14 02:16:47 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 14 Mar 2020 10:16:47 +0800 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: <45501DDD-B9F4-4C1E-9666-2A1AB1BBFD75@oracle.com> > On Mar 13, 2020, at 11:42 PM, Pavel Rappo wrote: > > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. This is indeed a typo. Other changes (including Ivan's) also look fine to me. Thanks, Max > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > From huizhe.wang at oracle.com Sat Mar 14 04:38:39 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 13 Mar 2020 21:38:39 -0700 Subject: [15] RFR: 8240626: Some of the java.time.chrono.Eras return empty display name for some styles and locales In-Reply-To: <244b0da6-f2eb-d83f-30b3-b59a2f8e8fb4@oracle.com> References: <4bc10314-09c5-edbf-71e8-f9ab425985ab@oracle.com> <244b0da6-f2eb-d83f-30b3-b59a2f8e8fb4@oracle.com> Message-ID: <1d4f033d-b4d4-18c2-3a73-d9c19938089e@oracle.com> Hi Naoto, I see. That makes sense. The change looks good to me. Best, Joe On 3/13/20 7:16 PM, naoto.sato at oracle.com wrote: > Hi Joe, > > Thank you for the review. Since those names are filled at the JDK > build time, there is no way to confirm the localized ones are from the > locale itself or its parents, unless parsing CLDR's source XML files > in the test at the runtime. I think it is enough to just ensure > there's no empty names returned at the runtime, IMO. > > Naoto > > On 3/13/20 5:00 PM, Joe Wang wrote: >> Hi Naoto, >> >> The existing tests verifies that a display name matches an expected >> value. I wonder if you'd want to do a bit more than the Boolean >> assertion with a similar approach as the existing test, that is, >> check that the fallback values/alias names match expected names. >> >> Best, >> Joe >> >> >> On 3/13/20 1:25 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8240626 >>> >>> The proposed chageset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8240626/webrev.00/ >>> >>> In some locales, CLDR only provides partial translations of era >>> names, e.g., only HEISEI and REIWA are provided for Japanese >>> Calendar in Greek locale. CLDRConverter needs to supplement those >>> missing translations from parent locales. >>> >>> Naoto >> From pavel.rappo at oracle.com Sat Mar 14 16:19:45 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sat, 14 Mar 2020 16:19:45 +0000 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> Message-ID: Hi Ivan, Your changes look good to me. Thanks for doing this. I will merge your changes into that patch of mine. 1. One thing that your change highlighted is that use of FQN here: public int read(java.nio.CharBuffer target) throws IOException It's been there for ages, but I believe can now safely go away after $ hg log -v -r 49262 changeset: 49262:1b3ee04e3e54 user: rriggs date: Mon Mar 19 09:58:41 2018 -0400 files: src/java.base/share/classes/java/io/Reader.java src/java.base/share/classes/java/io/Writer.java test/jdk/java/io/Reader/NullReader.java test/jdk/java/io/Writer/NullWriter.java description: 8196298: Add null Reader and Writer Reviewed-by: bpb, forax, smarks, alanb, rriggs Contributed-by: patrick at reini.net as this latter change brought import java.nio.CharBuffer; Unless people want to keep that FQN for some other reasons. For example, to emphasize that CharBuffer does not belong to java.io, or so it does not get confused with unrelated concepts like BufferedReader.defaultCharBufferSize, etc. 2. Typos aside, this MethodType.ConcurrentWeakInternSet.WeakEntry#equals has peculiar semantics! Paul Sandoz might be a good fit for reviewing changes in both java.util.stream (mine) and java.util.Arrays (yours). -Pavel > On 14 Mar 2020, at 02:03, Ivan Gerasimov wrote: > > Hi Pavel! > > Can this please be combined with my collection of typos? > > http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ > > Just to save cycles on reviewing :) > > With kind regards, > > Ivan > > > On 3/13/20 8:42 AM, Pavel Rappo wrote: >> Hello, >> >> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >> >> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >> >> This is a documentation cleanup. There are no code changes involved, >> and the changes in documentation are mostly trivial. >> >> The following packages are affected: >> >> java.lang, >> java.nio.file, >> java.nio.file.attribute, >> java.security, >> java.time.chrono, >> java.time.temporal, >> java.util, >> java.util.regex, >> java.util.stream, >> javax.crypto, >> javax.security.cert, >> javax.tools >> >> That said, there are two changes that I'd prefer to be carefully reviewed by >> the experts in the corresponding areas. >> >> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >> supported for the sake of backward compatibility. Sadly, we have a number of >> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >> should better be verified by the security folk. >> >> The second one is for the doc comment for the java.util.stream.Stream.collect method. >> >> @apiNote >> The following will accumulate strings into an ArrayList: >> >> List asList = stringStream.collect(Collectors.toList()); >> >> Given that the spec for Collectors.toList() clearly says that >> >> ...There are no guarantees on the type, mutability, serializability, or >> thread-safety of the List returned;... >> >> I'd assume that @apiNote should be fixed as proposed. >> >> -Pavel >> >> P.S. Apologies for spamming multiple mailing lists. >> > -- > With kind regards, > Ivan Gerasimov > From xu.y.yin at oracle.com Mon Mar 16 07:26:41 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Mon, 16 Mar 2020 15:26:41 +0800 Subject: [15] RFR: 8202117: com/sun/jndi/ldap/RemoveNamingListenerTest.java fails intermittently: Connection reset In-Reply-To: <15783e53-6100-e257-b666-b53f91f8aaff@oracle.com> References: <15783e53-6100-e257-b666-b53f91f8aaff@oracle.com> Message-ID: Thanks for reviewing, Daniel, Vyom. Hi, Daniel I modified the test as you suggested to cover the potential issue with URIBuilder, many thanks. Updated webrev as below: http://cr.openjdk.java.net/~xyin/8202117/webrev.01/ Regards, Chris > On 13 Mar 2020, at 7:51 PM, Daniel Fuchs wrote: > > Hi Chris, > > This looks fine to me too. Thanks for taking care of this issue. > > A potential issue I see is that the test might fail if > "localhost" does not resolve to the loopback address - but you > would likely get a "Connection refused" in that case. > > One possibility to get that out of the way could be to use > the URIBuilder: > > * @library lib/ /test/lib > > ... > > URI providerURI = URIBuilder.newBuilder() > .scheme("ldap") > .loopback() > .port(server.getLocalPort()) > .path("/o=example") > .build(); > ... > > 59 env.put(Context.PROVIDER_URL, providerURI.toString()); > > best regards, > > -- daniel > > > On 13/03/2020 08:28, Chris Yin wrote: >> Hello, >> Please review following changes to try to fix intermittent failure of test com/sun/jndi/ldap/RemoveNamingListenerTest.java, thanks >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202117 >> Webrev: http://cr.openjdk.java.net/~xyin/8202117/webrev.00/ >> According to failure logs, test already run done and give a pass message, but test framework caught ?java.lang.RuntimeException: java.net.SocketException: Connection reset? from other thread during test end, go through the test code, LDAPServerHandler thread may throw such exception in specific case. This change will replace test itself implemented TestLDAPServer/LDAPServerHandler with customized BaseLdapServer to fix the corner. I had run the changed test on 4 platforms for total 600 times, no failure observed. >> Thanks, >> Chris > From vyommani at gmail.com Mon Mar 16 09:07:36 2020 From: vyommani at gmail.com (Vyom Tiwari) Date: Mon, 16 Mar 2020 14:37:36 +0530 Subject: [15] RFR: 8202117: com/sun/jndi/ldap/RemoveNamingListenerTest.java fails intermittently: Connection reset In-Reply-To: References: <15783e53-6100-e257-b666-b53f91f8aaff@oracle.com> Message-ID: looks good to me. Vyom On Mon, Mar 16, 2020 at 12:59 PM Chris Yin wrote: > Thanks for reviewing, Daniel, Vyom. > > > Hi, Daniel > > I modified the test as you suggested to cover the potential issue with > URIBuilder, many thanks. Updated webrev as below: > > http://cr.openjdk.java.net/~xyin/8202117/webrev.01/ > > Regards, > Chris > > > > On 13 Mar 2020, at 7:51 PM, Daniel Fuchs > wrote: > > > > Hi Chris, > > > > This looks fine to me too. Thanks for taking care of this issue. > > > > A potential issue I see is that the test might fail if > > "localhost" does not resolve to the loopback address - but you > > would likely get a "Connection refused" in that case. > > > > One possibility to get that out of the way could be to use > > the URIBuilder: > > > > * @library lib/ /test/lib > > > > ... > > > > URI providerURI = URIBuilder.newBuilder() > > .scheme("ldap") > > .loopback() > > .port(server.getLocalPort()) > > .path("/o=example") > > .build(); > > ... > > > > 59 env.put(Context.PROVIDER_URL, providerURI.toString()); > > > > best regards, > > > > -- daniel > > > > > > On 13/03/2020 08:28, Chris Yin wrote: > >> Hello, > >> Please review following changes to try to fix intermittent failure of > test com/sun/jndi/ldap/RemoveNamingListenerTest.java, thanks > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202117 > >> Webrev: http://cr.openjdk.java.net/~xyin/8202117/webrev.00/ > >> According to failure logs, test already run done and give a pass > message, but test framework caught ?java.lang.RuntimeException: > java.net.SocketException: Connection reset? from other thread during test > end, go through the test code, LDAPServerHandler thread may throw such > exception in specific case. This change will replace test itself > implemented TestLDAPServer/LDAPServerHandler with customized BaseLdapServer > to fix the corner. I had run the changed test on 4 platforms for total 600 > times, no failure observed. > >> Thanks, > >> Chris > > > > -- Thanks, Vyom From Alan.Bateman at oracle.com Mon Mar 16 10:47:46 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Mar 2020 10:47:46 +0000 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: References: Message-ID: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> On 13/03/2020 18:16, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.00/ > > This is a follow-up task for Panama to allow explicit unloading of > native library after JDK-8228336.? `NativeLibraries` associated with a > class loader has the capability to auto unload native libraries when > the class loader is reclaimed.? This adds a new > `NativeLibraries::unload` method that provides the ability to unload a > native library on request.? This only allows `NativeLibraries` of no > relationship with a class loader where auto unloading is disabled The difference between the 2 constructors might not be obvious at the use sites. I'm just wondering if would be better to use static factory methods instead, e.g. the 2-arg constructor could be replaced with a trusted(caller, searchLibPath) method that would make it a lot more obvious in the places where that will eventually be used. A small inconsistency is that VM.isSystemDomainLoader is used in constructor whereas the other checks for null and platform class loader (plus app class loader). The Main test could use Path.of("classes"). In setup, dir could be a Path and also Path p = Files.createDirectories(...) would allow the Files.move to be a bit more readable. I can't quite tell why the test is skipped with -Xcomp but maybe it's just too slow and times out? A small suggestion for NativeLibrariesTest is that loadWithCustomLoader might be a better name to load p.Test with a custom loader. Also noticed libnativeLibrariesTest.c has a 2017 date on it. -Alan. From michael.x.mcmahon at oracle.com Mon Mar 16 12:39:03 2020 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 16 Mar 2020 12:39:03 +0000 Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found In-Reply-To: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com> References: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com> Message-ID: <5e148c2e-c708-aaf7-08b0-fd090ede1741@oracle.com> Hi Alex, (and redirecting the thread to net-dev) It looks like a straight forward solution and perhaps the compatibility test could be challenged on the basis of reliance on implementation behavior rather than the spec. But, more important I think is the behavior change of the fix itself and that will require careful review which we can't commit to immediately. We will try and get back to you about it in a week or so. Thanks, Michael. On 14/03/2020 00:08, Alex Kashchenko wrote: > Hi, > > Based on these maillist threads: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065076.html > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063643.html > > > I am looking for comments and suggestions, whether the following > change to JarURLConnection.getJarFile() behaviour may be acceptable: > > If, during connect() call, jarFile itself was created successfully, > but access to (non-existent) jarEntry failed - return this jarFile to > caller instead of throwing exception. > > bug: https://bugs.openjdk.java.net/browse/JDK-8132359 > webrev: http://cr.openjdk.java.net/~akasko/jdk/8132359/webrev.00/ > > This change also allows to fix JDK-8232854 with the minimal change to > URLClassPath (included with the patch). > > This change doesn't cause regression failures in java/net. > > This change causes one compatibility failure, when getManifest() > doesn't throw expected IOException when URL points to non-existent > class inside JAR. > From Roger.Riggs at oracle.com Mon Mar 16 16:02:33 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 16 Mar 2020 12:02:33 -0400 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming Message-ID: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> Please review adding pre-generated RMI stub classes to the jdk repo and the removal of make files supporting the specific APIs. It removes a dependency on build time generation invoking RMIC. RMIC was? deprecated in JDK 13 [1]. The source files have been edited to remove or suppress compilation warnings. Webrev: ?? http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ Issue: ?https://bugs.openjdk.java.net/browse/JDK-8241073 Thanks, Roger p.s. A future change will remove the interim build steps [1] https://bugs.openjdk.java.net/browse/JDK-8217412 From erik.joelsson at oracle.com Mon Mar 16 16:22:06 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Mar 2020 09:22:06 -0700 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> Message-ID: <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> Hello Roger, There is more to be removed in the makefiles. This file should also be removed: make/CompileInterimRmic.gmk In make/Main.gmk, all the targets concerning rmic needs to be removed as well as any dependencies declared that involves them. Searching for "rmic" should find all relevant lines. /Erik On 2020-03-16 09:02, Roger Riggs wrote: > Please review adding pre-generated RMI stub classes to the jdk repo > and the removal of make files supporting the specific APIs. > > It removes a dependency on build time generation invoking RMIC. > RMIC was? deprecated in JDK 13 [1]. > > The source files have been edited to remove or suppress compilation > warnings. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ > > Issue: > ?https://bugs.openjdk.java.net/browse/JDK-8241073 > > > Thanks, Roger > > p.s. A future change will remove the interim build steps > > > [1] https://bugs.openjdk.java.net/browse/JDK-8217412 From Roger.Riggs at oracle.com Mon Mar 16 16:34:16 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 16 Mar 2020 12:34:16 -0400 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> Message-ID: <21566002-ad06-2701-268e-de47f9f7043f@oracle.com> Hi Erik, I was thinking that was a separate step, but can pull it in. (And there's something in spec.gmk.in.) Roger On 3/16/20 12:22 PM, Erik Joelsson wrote: > Hello Roger, > > There is more to be removed in the makefiles. > > This file should also be removed: > > make/CompileInterimRmic.gmk > > In make/Main.gmk, all the targets concerning rmic needs to be removed > as well as any dependencies declared that involves them. Searching for > "rmic" should find all relevant lines. > > /Erik > > On 2020-03-16 09:02, Roger Riggs wrote: >> Please review adding pre-generated RMI stub classes to the jdk repo >> and the removal of make files supporting the specific APIs. >> >> It removes a dependency on build time generation invoking RMIC. >> RMIC was? deprecated in JDK 13 [1]. >> >> The source files have been edited to remove or suppress compilation >> warnings. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ >> >> Issue: >> ?https://bugs.openjdk.java.net/browse/JDK-8241073 >> >> >> Thanks, Roger >> >> p.s. A future change will remove the interim build steps >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217412 From Alan.Bateman at oracle.com Mon Mar 16 17:39:18 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Mar 2020 17:39:18 +0000 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> Message-ID: On 16/03/2020 16:02, Roger Riggs wrote: > Please review adding pre-generated RMI stub classes to the jdk repo > and the removal of make files supporting the specific APIs. > > It removes a dependency on build time generation invoking RMIC. > RMIC was? deprecated in JDK 13 [1]. > > The source files have been edited to remove or suppress compilation > warnings. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ > > Issue: > ?https://bugs.openjdk.java.net/browse/JDK-8241073 > > > Thanks, Roger > > p.s. A future change will remove the interim build steps Checking-in the generated stubs looks good. I'm sure build-dev can suggest the following removal/cleanup (I have no opinion on whether it's a follow-up on issue or not). I assume you'll test that boot cycle builds work with the changes. Are you, or maybe Stuart, planning to follow-up soon with the removal of rmic? -Alan From joel.borggren.franck at gmail.com Mon Mar 16 20:44:47 2020 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Mon, 16 Mar 2020 21:44:47 +0100 Subject: 8202469 / 8202473: Correct type annotation resolution for class type variables In-Reply-To: References: <0aaaa441-c193-6155-4da3-5bd91888f73e@oracle.com> Message-ID: Looks good to me! I'll see if I can find a sponsor for this. cheers /Joel On Sat, Mar 7, 2020 at 2:15 AM Rafael Winterhalter wrote: > I finally found the time to look at this again, sorry for the delay. > > Thank you for your comments. I had the chance to better look into the > problem and simplify the code a bit more and also reduced the scope of the > fix to a single problem. I also added test cases that should be exhaustive > for all possible scenarios and adjusted the code comment. > > I uploaded the adjusted patch as a webrev: > http://cr.openjdk.java.net/~winterhalter/8202469/webrev.01/ > > Thanks, Rafael > > Am So., 16. Feb. 2020 um 10:51 Uhr schrieb Joel Borggr?n-Franck < > joel.borggren.franck at gmail.com>: > >> Hi Rafael, >> >> Thanks for reaching out and reminding me of this! >> >> I managed to find some time to look into 8202469 during the weekend. By >> swapping place of the TVars in the test I managed to isolate this without >> depending on 8202473, take a look at my hacky copy-paste update to your >> test at http://cr.openjdk.java.net/~jfranck/8202469/ . >> >> The comment on lines 269-276 needs to be updated. Perhaps include a table >> with the start index depending of the type? Also referencing JVMLS 4.4 for >> the structure of the bound might be instructive for future readers. >> >> My current understanding is that there are two problems with the code on >> (the original) lines 277-287: >> 1) Type Variables should have index 0 while getting index 1 due to lines >> 279-280. >> 2) Bounds that are instances of ParameterizedType always gets index 1 but >> if the first bound represents a Class type the index should be 0. >> >> Does this make sense? >> >> Can you make the if-switches positive? I find my original code with the >> negative tests hard to read and the update doesn't help. >> >> Also can you expand the test to cover the different kinds of bounds >> mentioned in 4.4 and also test Type Variables on methods, I suspect javac >> treats method (and constructor) tvars similarly but there have been bugs ... >> >> TL;DR please update the webrev with: >> >> - Split out test and fix for 8202469 >> - More test coverage of different kinds of bounds >> - Test for method tvars >> - See if you can rework the logic to have (mostly) positive tests in if >> switch >> >> Thanks again for looking into this, I'll start looking into 8202473, I >> think the fix for that one opens up a bigger rework of the code which is >> why I want to separate the two. >> >> cheers >> /Joel >> >> On Sun, Aug 4, 2019 at 10:12 PM Rafael Winterhalter >> wrote: >> >>> Hi, >>> >>> appologies for the delay, I only managed to get my patched up to webrev >>> today (http://cr.openjdk.java.net/~winterhalter/). It's three patches >>> in total now, for the third one I could not add a test case, it would >>> require to compile an annotation property against an enumeration type and >>> load it against another class where the enumeration was turned into an >>> annotation. I struggled a bit with jtreg to make it work but I cannot see >>> myself complete this in a meaningful amount of time. However, I hope that >>> the patch and the error it solves are straightforward to see. >>> >>> I only submitted a patch for 8202469. 8202473 is solved by it. It's two >>> bugs but they are a symptom of the same oversight. >>> >>> I hope this helps you to review it but let me know if you have any >>> questions or if I should further adjust my patch. >>> >>> Best regards, Rafael >>> >>> Am Fr., 2. Aug. 2019 um 12:18 Uhr schrieb Rafael Winterhalter < >>> rafael.wth at gmail.com>: >>> >>>> Thanks Daniel, >>>> I did some work on Glassfish a bunch of years ago, I had no idea. >>>> I will try to split up the changes (I fixed another bug in annotation >>>> processing yesterday) and upload everything there. >>>> Best regards, Rafael >>>> >>>> Am Fr., 2. Aug. 2019 um 11:59 Uhr schrieb Daniel Fuchs < >>>> daniel.fuchs at oracle.com>: >>>> >>>>> Hi Rafael, >>>>> >>>>> On 02/08/2019 09:00, Joel Borggr?n-Franck wrote: >>>>> > I can host webrevs for you on cr to make it easier for other >>>>> reviewers, if >>>>> > you also send me the patches or webrefs off-list to get around the >>>>> > attachment stripping I can upload them to cr. >>>>> >>>>> I see that you are a JDK project author, so you already own a page >>>>> on cr (http://cr.openjdk.java.net/~winterhalter/) where you can >>>>> upload webrevs (e.g. using `scp` as in: >>>>> $ scp -r webrev-NNNNN.01 winterhalter at cr.openjdk.java.net: ) >>>>> >>>>> best regards and welcome! >>>>> >>>>> -- daniel >>>>> >>>> From roger.riggs at oracle.com Mon Mar 16 22:18:32 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 16 Mar 2020 18:18:32 -0400 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> Message-ID: <6d77e97c-8505-c99c-3105-7381fe5b678b@oracle.com> Hi Alan, Removal of rmic itself is assigned to Stuart with a fixVersion of 15: 8225319 Remove rmic from the set of supported tools I'll see how to test the build-cycle. Thanks, Roger On 3/16/20 1:39 PM, Alan Bateman wrote: > On 16/03/2020 16:02, Roger Riggs wrote: >> Please review adding pre-generated RMI stub classes to the jdk repo >> and the removal of make files supporting the specific APIs. >> >> It removes a dependency on build time generation invoking RMIC. >> RMIC was? deprecated in JDK 13 [1]. >> >> The source files have been edited to remove or suppress compilation >> warnings. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ >> >> Issue: >> ?https://bugs.openjdk.java.net/browse/JDK-8241073 >> >> >> Thanks, Roger >> >> p.s. A future change will remove the interim build steps > Checking-in the generated stubs looks good. I'm sure build-dev can > suggest the following removal/cleanup (I have no opinion on whether > it's a follow-up on issue or not). I assume you'll test that boot > cycle builds work with the changes. > > Are you, or maybe Stuart, planning to follow-up soon with the removal > of rmic? > > -Alan From roger.riggs at oracle.com Mon Mar 16 22:19:34 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 16 Mar 2020 18:19:34 -0400 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> Message-ID: Hi Erik, Please review a new webrev that adds the change to remove the interim build parts. (Passes Tier 1-3 of CI testing) http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-1/ Thanks, Roger On 3/16/20 12:22 PM, Erik Joelsson wrote: > Hello Roger, > > There is more to be removed in the makefiles. > > This file should also be removed: > > make/CompileInterimRmic.gmk > > In make/Main.gmk, all the targets concerning rmic needs to be removed > as well as any dependencies declared that involves them. Searching for > "rmic" should find all relevant lines. > > /Erik > > On 2020-03-16 09:02, Roger Riggs wrote: >> Please review adding pre-generated RMI stub classes to the jdk repo >> and the removal of make files supporting the specific APIs. >> >> It removes a dependency on build time generation invoking RMIC. >> RMIC was? deprecated in JDK 13 [1]. >> >> The source files have been edited to remove or suppress compilation >> warnings. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ >> >> Issue: >> ?https://bugs.openjdk.java.net/browse/JDK-8241073 >> >> >> Thanks, Roger >> >> p.s. A future change will remove the interim build steps >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217412 From erik.joelsson at oracle.com Tue Mar 17 13:17:11 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 17 Mar 2020 06:17:11 -0700 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> Message-ID: Hello, That looks better, but there are still some more things to remove. This whole block: ################################################################################ # Targets for running rmic. $(eval $(call DeclareRecipesForPhase, RMIC, \ ??? TARGET_SUFFIX := rmic, \ ??? FILE_PREFIX := Rmic, \ ??? MAKE_SUBDIR := rmic, \ ??? CHECK_MODULES := $(ALL_MODULES))) ALL_TARGETS += $(RMIC_TARGETS) And all references to $(RMIC_TARGETS) and $(RMIC_MODULES). In most cases the whole lines (like the $(foreach) calls that iterate over them) can just be removed. /Erik On 2020-03-16 15:19, Roger Riggs wrote: > Hi Erik, > > Please review a new webrev that adds the change to remove the interim > build parts. > (Passes Tier 1-3 of CI testing) > > http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-1/ > > Thanks, Roger > > > On 3/16/20 12:22 PM, Erik Joelsson wrote: >> Hello Roger, >> >> There is more to be removed in the makefiles. >> >> This file should also be removed: >> >> make/CompileInterimRmic.gmk >> >> In make/Main.gmk, all the targets concerning rmic needs to be removed >> as well as any dependencies declared that involves them. Searching >> for "rmic" should find all relevant lines. >> >> /Erik >> >> On 2020-03-16 09:02, Roger Riggs wrote: >>> Please review adding pre-generated RMI stub classes to the jdk repo >>> and the removal of make files supporting the specific APIs. >>> >>> It removes a dependency on build time generation invoking RMIC. >>> RMIC was? deprecated in JDK 13 [1]. >>> >>> The source files have been edited to remove or suppress compilation >>> warnings. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ >>> >>> Issue: >>> ?https://bugs.openjdk.java.net/browse/JDK-8241073 >>> >>> >>> Thanks, Roger >>> >>> p.s. A future change will remove the interim build steps >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8217412 > From magnus.ihse.bursie at oracle.com Tue Mar 17 14:06:25 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 17 Mar 2020 15:06:25 +0100 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> Message-ID: <80722047-3e15-3716-a015-4caf628027e5@oracle.com> On 2020-03-17 14:17, Erik Joelsson wrote: > Hello, > > That looks better, but there are still some more things to remove. > This whole block: > > ################################################################################ > > # Targets for running rmic. > $(eval $(call DeclareRecipesForPhase, RMIC, \ > ??? TARGET_SUFFIX := rmic, \ > ??? FILE_PREFIX := Rmic, \ > ??? MAKE_SUBDIR := rmic, \ > ??? CHECK_MODULES := $(ALL_MODULES))) > > ALL_TARGETS += $(RMIC_TARGETS) > > And all references to $(RMIC_TARGETS) and $(RMIC_MODULES). In most > cases the whole lines (like the $(foreach) calls that iterate over > them) can just be removed. This also means killing the entire "rmic" phase of the build. So please also remove the rmic target from Main.gmk line 1015, and ALL_TARGETs line 1133. And the reference to "rmic" from the phases in the help in Global.gmk. In ZipSource.gmk, there's special handling to include rmic source code, which is no longer needed. In Docs.gmk, you can remove $(SUPPORT_OUTPUTDIR)/rmic/* from MODULES_SOURCE_PATH. (That actually made me notice another weird rmi thingy. How does these new stubs relate to src/java.rmi/share/doc/stub/java/rmi/activation/ActivationGroup_Stub.java? That file has been present for a long time. It is included when generating Javadoc, but not when compiling the class files for the JDK.) ?It is probably a good idea to make a case-insensitive search for "rmic" in the make directory afterwards, to confirm that all remaining cases of rmic should be there (i.e. it relates to compiling jdk.rmi, not running rmic during the build.) And btw, I'm eternally grateful to you for removing this. :-) Now the prospect of a fully warning-free build seems closer than ever! /Magnus > > /Erik > > On 2020-03-16 15:19, Roger Riggs wrote: >> Hi Erik, >> >> Please review a new webrev that adds the change to remove the interim >> build parts. >> (Passes Tier 1-3 of CI testing) >> >> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-1/ >> >> Thanks, Roger >> >> >> On 3/16/20 12:22 PM, Erik Joelsson wrote: >>> Hello Roger, >>> >>> There is more to be removed in the makefiles. >>> >>> This file should also be removed: >>> >>> make/CompileInterimRmic.gmk >>> >>> In make/Main.gmk, all the targets concerning rmic needs to be >>> removed as well as any dependencies declared that involves them. >>> Searching for "rmic" should find all relevant lines. >>> >>> /Erik >>> >>> On 2020-03-16 09:02, Roger Riggs wrote: >>>> Please review adding pre-generated RMI stub classes to the jdk repo >>>> and the removal of make files supporting the specific APIs. >>>> >>>> It removes a dependency on build time generation invoking RMIC. >>>> RMIC was? deprecated in JDK 13 [1]. >>>> >>>> The source files have been edited to remove or suppress compilation >>>> warnings. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ >>>> >>>> Issue: >>>> ?https://bugs.openjdk.java.net/browse/JDK-8241073 >>>> >>>> >>>> Thanks, Roger >>>> >>>> p.s. A future change will remove the interim build steps >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8217412 >> From andrew_m_leonard at uk.ibm.com Tue Mar 17 14:36:22 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 17 Mar 2020 14:36:22 +0000 Subject: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings Message-ID: Hi, Please can I get a sponsor and reviews for the following "patch" to the SymmetricRangeTests.java test, for bug https://bugs.openjdk.java.net/browse/JDK-8241097 patch: http://cr.openjdk.java.net/~aleonard/8241097/webrev.00/ The current testcase makes the assumption that -XX:+CompactStrings is the default, which it is for Hotspot, but that's not necessarily true for all JVM providers. Thank you Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From brian.burkhalter at oracle.com Tue Mar 17 14:47:42 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Mar 2020 07:47:42 -0700 Subject: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings In-Reply-To: References: Message-ID: <56F933F1-63E1-436A-9791-DA89085D0A2D@oracle.com> Hi Andrew, I can help you. The change looks good but what do you see when you run the test without the change on a non-Hotspot VM? Thanks, Brian > On Mar 17, 2020, at 7:36 AM, Andrew Leonard wrote: > > Please can I get a sponsor and reviews for the following "patch" to the > SymmetricRangeTests.java test, for bug > https://bugs.openjdk.java.net/browse/JDK-8241097 > patch: http://cr.openjdk.java.net/~aleonard/8241097/webrev.00/ > > The current testcase makes the assumption that -XX:+CompactStrings is the > default, which it is for Hotspot, but that's not necessarily true for all > JVM providers. From andrew_m_leonard at uk.ibm.com Tue Mar 17 14:52:51 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 17 Mar 2020 14:52:51 +0000 Subject: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings In-Reply-To: <56F933F1-63E1-436A-9791-DA89085D0A2D@oracle.com> References: <56F933F1-63E1-436A-9791-DA89085D0A2D@oracle.com> Message-ID: Thanks Brian, With Eclipse OpenJ9 you see this, which is very similar to if you force Hotspot with -XX:-CompactStrings: Exception in thread "main" java.lang.OutOfMemoryError at java.base/java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214) at java.base/java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206) at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173) at java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:748) at java.base/java.lang.StringBuilder.append(StringBuilder.java:241) at StringBufferTest.main(StringBufferTest.java:8) Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Brian Burkhalter To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 17/03/2020 14:48 Subject: [EXTERNAL] Re: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings Hi Andrew, I can help you. The change looks good but what do you see when you run the test without the change on a non-Hotspot VM? Thanks, Brian On Mar 17, 2020, at 7:36 AM, Andrew Leonard wrote: Please can I get a sponsor and reviews for the following "patch" to the SymmetricRangeTests.java test, for bug https://bugs.openjdk.java.net/browse/JDK-8241097 patch: http://cr.openjdk.java.net/~aleonard/8241097/webrev.00/ The current testcase makes the assumption that -XX:+CompactStrings is the default, which it is for Hotspot, but that's not necessarily true for all JVM providers. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From brian.burkhalter at oracle.com Tue Mar 17 15:06:34 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Mar 2020 08:06:34 -0700 Subject: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings In-Reply-To: References: <56F933F1-63E1-436A-9791-DA89085D0A2D@oracle.com> Message-ID: <032E77D2-A554-473E-AE07-DFB5E512F1B2@oracle.com> You?re welcome. I see. Let?s leave this hang out a bit for further comment. Also, is a test possible, or a modification of an existing test? Thanks, Brian > On Mar 17, 2020, at 7:52 AM, Andrew Leonard wrote: > > Thanks Brian, > With Eclipse OpenJ9 you see this, which is very similar to if you force Hotspot with -XX:-CompactStrings: > Exception in thread "main" java.lang.OutOfMemoryError > at java.base/java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214) From brian.burkhalter at oracle.com Tue Mar 17 15:40:29 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Mar 2020 08:40:29 -0700 Subject: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings In-Reply-To: <032E77D2-A554-473E-AE07-DFB5E512F1B2@oracle.com> References: <56F933F1-63E1-436A-9791-DA89085D0A2D@oracle.com> <032E77D2-A554-473E-AE07-DFB5E512F1B2@oracle.com> Message-ID: To clarify, could the compact strings setting be detected and maybe add another @run tag and expect an OOME? Not sure this is critical. Brian > On Mar 17, 2020, at 8:06 AM, Brian Burkhalter wrote: > > You?re welcome. > > I see. Let?s leave this hang out a bit for further comment. Also, is a test possible, or a modification of an existing test? From mik3hall at gmail.com Tue Mar 17 17:37:38 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 17 Mar 2020 12:37:38 -0500 Subject: jpackage and alternate JRE's - OS X Message-ID: I was looking at GraalVM in order to try out FastR, a jre based R language implementation. It seemed to me if it was actually a standalone JRE I should be able to use jpackage to turn it into an application. Or use my usual application for trying things out but just replace the runtime. It seems to work for running the application. I seem to be able to use the included RScript command to run R files. I can?t use the R command due to limitations in my own code. Otherwise the normal application functionality appears to work. However, If I try a simple test for programmatic R access the application crashes with? Exception Type: EXC_BAD_ACCESS (Code Signature Invalid) If I check? codesign -dv outFastR/FastRGraalHP.app Executable=/Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHP.app/Contents/MacOS/FastRGraalHP Identifier=jpackageapplauncher ? It does appear that jpackage is doing some default code signing. I guess my question would be if it could be possible to omit the signing. Where I assume the application would be subject to the usual Gatekeeper ?use at your own risk? messages. But could be runnable. I see there are signing parameters in the help but I currently don?t have ADC certificates. That includes ?mac-sign to indicate signing should be done. Could there be some way to get none? Or supported is that you must get the signing certs? It doesn?t make sense to me that you can fully use the included commands but can?t have programmatic access. How is that less secure? But it seems to be the case. I realize jpackage is probably not intended to support GraalVM. But it is possible it?s use could be extended even if unsupported. From andrew_m_leonard at uk.ibm.com Tue Mar 17 17:39:16 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 17 Mar 2020 17:39:16 +0000 Subject: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings In-Reply-To: References: <56F933F1-63E1-436A-9791-DA89085D0A2D@oracle.com> <032E77D2-A554-473E-AE07-DFB5E512F1B2@oracle.com> Message-ID: I see what you mean, but it's not really the point of the the BigInteger test, which is testing for an Arithmetic exception: The problem test is the one for 8021204 which constructs a String of "0"'s 2*31 long! which if you use 2bytes for each "0" is very likely to run out of memory! The problem is a "bug" in the testcase in that it doesn't quite ensure the environment is capable of running the test, by ensuring 1byte per char helps ensure that. Hotspot is that by default. I also suspect OOME is not certain either necessarily. Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Brian Burkhalter To: Andrew Leonard Cc: Java Core Libs Date: 17/03/2020 15:48 Subject: [EXTERNAL] Re: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings To clarify, could the compact strings setting be detected and maybe add another @run tag and expect an OOME? Not sure this is critical. Brian On Mar 17, 2020, at 8:06 AM, Brian Burkhalter wrote: You?re welcome. I see. Let?s leave this hang out a bit for further comment. Also, is a test possible, or a modification of an existing test? Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From brian.burkhalter at oracle.com Tue Mar 17 17:46:20 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Mar 2020 10:46:20 -0700 Subject: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings In-Reply-To: References: <56F933F1-63E1-436A-9791-DA89085D0A2D@oracle.com> <032E77D2-A554-473E-AE07-DFB5E512F1B2@oracle.com> Message-ID: OK, I am fine with that. I?ll leave it open for the moment though in case anyone else has a comment. Brian > On Mar 17, 2020, at 10:39 AM, Andrew Leonard wrote: > > I see what you mean, but it's not really the point of the the BigInteger test, which is testing for an Arithmetic exception: > The problem test is the one for 8021204 which constructs a String of "0"'s 2*31 long! which if you use 2bytes for each "0" is very likely to run out of memory! The problem is a "bug" in the testcase in that it doesn't quite ensure the environment is capable of running the test, by ensuring 1byte per char helps ensure that. Hotspot is that by default. I also suspect OOME is not certain either necessarily. > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Brian Burkhalter > To: Andrew Leonard > Cc: Java Core Libs > Date: 17/03/2020 15:48 > Subject: [EXTERNAL] Re: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings > > > > To clarify, could the compact strings setting be detected and maybe add another @run tag and expect an OOME? Not sure this is critical. > > Brian > > On Mar 17, 2020, at 8:06 AM, Brian Burkhalter > wrote: > > You?re welcome. > > I see. Let?s leave this hang out a bit for further comment. Also, is a test possible, or a modification of an existing test? > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From raffaello.giulietti at gmail.com Tue Mar 17 19:38:33 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 17 Mar 2020 20:38:33 +0100 Subject: RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results Message-ID: <337af475-162d-c942-a6d5-2957c1fb69f2@gmail.com> Hello, there's a new version of the documentation [1] for the attached patch to solve the long standing issues described in [2]. The CSR referred to in the subject is in [3]. Besides many improvements in the proofs, a couple of simplifications and a better overall organization (this is my hope), I could find an ideal treatment of a special case that in the previous inception had a ugly, yet pragmatic solution in form of rather ad-hoc switch constructs. The new approach is mathematically clean and makes the code some lines shorter. The new code reflects this improvement and also adds a couple of additional tests. Passes tier1 tests. @BrianBurkalter Brian, can you please upload the patch to webrev? As usual, there's an email attachemnt for your benefit. Thanks. Greetings Raffaello ---- [1] https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN [2] https://bugs.openjdk.java.net/browse/JDK-4511638 [3] https://bugs.openjdk.java.net/browse/JDK-8202555 ---- # HG changeset patch # User lello # Date 1584472052 -3600 # Tue Mar 17 20:07:32 2020 +0100 # Node ID ec615c419ab236ae291651f5a810807f05fb4421 # Parent 42b62267498dbea03a82eeb073c6020b4b43d288 Patch to fix JDK-4511638 4511638: Double.toString(double) sometimes produces incorrect results Reviewed-by: TBD Contributed-by: Raffaello Giulietti diff --git a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java --- a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java +++ b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java @@ -25,8 +25,10 @@ package java.lang; -import jdk.internal.math.FloatingDecimal; +import jdk.internal.math.DoubleToDecimal; +import jdk.internal.math.FloatToDecimal; +import java.io.IOException; import java.util.Arrays; import java.util.Spliterator; import java.util.stream.IntStream; @@ -880,7 +882,11 @@ * @return a reference to this object. */ public AbstractStringBuilder append(float f) { - FloatingDecimal.appendTo(f,this); + try { + FloatToDecimal.appendTo(f, this); + } catch (IOException ignored) { + assert false; + } return this; } @@ -897,7 +903,11 @@ * @return a reference to this object. */ public AbstractStringBuilder append(double d) { - FloatingDecimal.appendTo(d,this); + try { + DoubleToDecimal.appendTo(d, this); + } catch (IOException ignored) { + assert false; + } return this; } diff --git a/src/java.base/share/classes/java/lang/Double.java b/src/java.base/share/classes/java/lang/Double.java --- a/src/java.base/share/classes/java/lang/Double.java +++ b/src/java.base/share/classes/java/lang/Double.java @@ -32,6 +32,7 @@ import jdk.internal.math.FloatingDecimal; import jdk.internal.math.DoubleConsts; +import jdk.internal.math.DoubleToDecimal; import jdk.internal.HotSpotIntrinsicCandidate; /** @@ -145,69 +146,120 @@ public static final Class TYPE = (Class) Class.getPrimitiveClass("double"); /** - * Returns a string representation of the {@code double} - * argument. All characters mentioned below are ASCII characters. - *

    - *
  • If the argument is NaN, the result is the string - * "{@code NaN}". - *
  • Otherwise, the result is a string that represents the sign and - * magnitude (absolute value) of the argument. If the sign is negative, - * the first character of the result is '{@code -}' - * ({@code '\u005Cu002D'}); if the sign is positive, no sign character - * appears in the result. As for the magnitude m: - *
      - *
    • If m is infinity, it is represented by the characters - * {@code "Infinity"}; thus, positive infinity produces the result - * {@code "Infinity"} and negative infinity produces the result - * {@code "-Infinity"}. - * - *
    • If m is zero, it is represented by the characters - * {@code "0.0"}; thus, negative zero produces the result - * {@code "-0.0"} and positive zero produces the result - * {@code "0.0"}. + * Returns a string rendering of the {@code double} argument. * - *
    • If m is greater than or equal to 10-3 but less - * than 107, then it is represented as the integer part of - * m, in decimal form with no leading zeroes, followed by - * '{@code .}' ({@code '\u005Cu002E'}), followed by one or - * more decimal digits representing the fractional part of m. - * - *
    • If m is less than 10-3 or greater than or - * equal to 107, then it is represented in so-called - * "computerized scientific notation." Let n be the unique - * integer such that 10n ≤ m {@literal <} - * 10n+1; then let a be the - * mathematically exact quotient of m and - * 10n so that 1 ≤ a {@literal <} 10. The - * magnitude is then represented as the integer part of a, - * as a single decimal digit, followed by '{@code .}' - * ({@code '\u005Cu002E'}), followed by decimal digits - * representing the fractional part of a, followed by the - * letter '{@code E}' ({@code '\u005Cu0045'}), followed - * by a representation of n as a decimal integer, as - * produced by the method {@link Integer#toString(int)}. + *

      The characters of the result are all drawn from the ASCII set. + *

        + *
      • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
      • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
      • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
      • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
      • A finite positive {@code v} is rendered in two stages: + *
          + *
        • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
        • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. *
        *
      - * How many digits must be printed for the fractional part of - * m or a? There must be at least one digit to represent - * the fractional part, and beyond that as many, but only as many, more - * digits as are needed to uniquely distinguish the argument value from - * adjacent values of type {@code double}. That is, suppose that - * x is the exact mathematical value represented by the decimal - * representation produced by this method for a finite nonzero argument - * d. Then d must be the {@code double} value nearest - * to x; or if two {@code double} values are equally close - * to x, then d must be one of them and the least - * significant bit of the significand of d must be {@code 0}. + * + *

      A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

      The decimal dv + * for a finite positive {@code v} is defined as follows: + *

        + *
      • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
      • Let m be the minimal length over all decimals in R. + *
      • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
      • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
      + * + *

      The (uniquely) selected decimal dv + * is then formatted. * - *

      To create localized string representations of a floating-point - * value, use subclasses of {@link java.text.NumberFormat}. + *

      Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

        + *
      • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
      • Case 0 ≤ e < 7: + *
          + *
        • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
        • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
        + *
      • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
          + *
        • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
        • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
        + *
      * - * @param d the {@code double} to be converted. - * @return a string representation of the argument. + * @param v the {@code double} to be rendered. + * @return a string rendering of the argument. */ - public static String toString(double d) { - return FloatingDecimal.toJavaFormatString(d); + public static String toString(double v) { + return DoubleToDecimal.toString(v); } /** diff --git a/src/java.base/share/classes/java/lang/Float.java b/src/java.base/share/classes/java/lang/Float.java --- a/src/java.base/share/classes/java/lang/Float.java +++ b/src/java.base/share/classes/java/lang/Float.java @@ -31,6 +31,7 @@ import java.util.Optional; import jdk.internal.math.FloatingDecimal; +import jdk.internal.math.FloatToDecimal; import jdk.internal.HotSpotIntrinsicCandidate; /** @@ -142,73 +143,120 @@ public static final Class TYPE = (Class) Class.getPrimitiveClass("float"); /** - * Returns a string representation of the {@code float} - * argument. All characters mentioned below are ASCII characters. - *
        - *
      • If the argument is NaN, the result is the string - * "{@code NaN}". - *
      • Otherwise, the result is a string that represents the sign and - * magnitude (absolute value) of the argument. If the sign is - * negative, the first character of the result is - * '{@code -}' ({@code '\u005Cu002D'}); if the sign is - * positive, no sign character appears in the result. As for - * the magnitude m: + * Returns a string rendering of the {@code float} argument. + * + *

        The characters of the result are all drawn from the ASCII set. *

          - *
        • If m is infinity, it is represented by the characters - * {@code "Infinity"}; thus, positive infinity produces - * the result {@code "Infinity"} and negative infinity - * produces the result {@code "-Infinity"}. - *
        • If m is zero, it is represented by the characters - * {@code "0.0"}; thus, negative zero produces the result - * {@code "-0.0"} and positive zero produces the result - * {@code "0.0"}. - *
        • If m is greater than or equal to 10-3 but - * less than 107, then it is represented as the - * integer part of m, in decimal form with no leading - * zeroes, followed by '{@code .}' - * ({@code '\u005Cu002E'}), followed by one or more - * decimal digits representing the fractional part of - * m. - *
        • If m is less than 10-3 or greater than or - * equal to 107, then it is represented in - * so-called "computerized scientific notation." Let n - * be the unique integer such that 10n ≤ - * m {@literal <} 10n+1; then let a - * be the mathematically exact quotient of m and - * 10n so that 1 ≤ a {@literal <} 10. - * The magnitude is then represented as the integer part of - * a, as a single decimal digit, followed by - * '{@code .}' ({@code '\u005Cu002E'}), followed by - * decimal digits representing the fractional part of - * a, followed by the letter '{@code E}' - * ({@code '\u005Cu0045'}), followed by a representation - * of n as a decimal integer, as produced by the - * method {@link java.lang.Integer#toString(int)}. - * + *
        • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
        • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
        • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
        • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
        • A finite positive {@code v} is rendered in two stages: + *
            + *
          • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
          • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. *
          *
        - * How many digits must be printed for the fractional part of - * m or a? There must be at least one digit - * to represent the fractional part, and beyond that as many, but - * only as many, more digits as are needed to uniquely distinguish - * the argument value from adjacent values of type - * {@code float}. That is, suppose that x is the - * exact mathematical value represented by the decimal - * representation produced by this method for a finite nonzero - * argument f. Then f must be the {@code float} - * value nearest to x; or, if two {@code float} values are - * equally close to x, then f must be one of - * them and the least significant bit of the significand of - * f must be {@code 0}. + * + *

        A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

        The decimal dv + * for a finite positive {@code v} is defined as follows: + *

          + *
        • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
        • Let m be the minimal length over all decimals in R. + *
        • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
        • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
        + * + *

        The (uniquely) selected decimal dv + * is then formatted. * - *

        To create localized string representations of a floating-point - * value, use subclasses of {@link java.text.NumberFormat}. + *

        Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

          + *
        • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
        • Case 0 ≤ e < 7: + *
            + *
          • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
          • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
          + *
        • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
            + *
          • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
          • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
          + *
        * - * @param f the float to be converted. - * @return a string representation of the argument. + * @param v the {@code float} to be rendered. + * @return a string rendering of the argument. */ - public static String toString(float f) { - return FloatingDecimal.toJavaFormatString(f); + public static String toString(float v) { + return FloatToDecimal.toString(v); } /** diff --git a/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java new file mode 100644 --- /dev/null +++ b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java @@ -0,0 +1,644 @@ +/* + * Copyright 2018-2020 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +import java.io.IOException; + +import static java.lang.Double.*; +import static java.lang.Long.*; +import static java.lang.Math.multiplyHigh; +import static jdk.internal.math.MathUtils.*; + +/** + * This class exposes a method to render a {@code double} as a string. + * + * @author Raffaello Giulietti + */ +final public class DoubleToDecimal { + /* + For full details about this code see the following references: + + [1] Giulietti, "The Schubfach way to render doubles", + https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN + + [2] IEEE Computer Society, "IEEE Standard for Floating-Point Arithmetic" + + [3] Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion" + + Divisions are avoided altogether for the benefit of those architectures + that do not provide specific machine instructions or where they are slow. + This is discussed in section 10 of [1]. + */ + + // The precision in bits. + static final int P = 53; + + // Exponent width in bits. + private static final int W = (Double.SIZE - 1) - (P - 1); + + // Minimum value of the exponent: -(2^(W-1)) - P + 3. + static final int Q_MIN = (-1 << W - 1) - P + 3; + + // Maximum value of the exponent: 2^(W-1) - P. + static final int Q_MAX = (1 << W - 1) - P; + + // 10^(E_MIN - 1) <= MIN_VALUE < 10^E_MIN + static final int E_MIN = -323; + + // 10^(E_MAX - 1) <= MAX_VALUE < 10^E_MAX + static final int E_MAX = 309; + + // Threshold to detect tiny values, as in section 8.1.1 of [1] + static final long C_TINY = 3; + + // The minimum and maximum k, as in section 8 of [1] + static final int K_MIN = -324; + static final int K_MAX = 292; + + // H is as in section 8 of [1]. + static final int H = 17; + + // Minimum value of the significand of a normal value: 2^(P-1). + private static final long C_MIN = 1L << P - 1; + + // Mask to extract the biased exponent. + private static final int BQ_MASK = (1 << W) - 1; + + // Mask to extract the fraction bits. + private static final long T_MASK = (1L << P - 1) - 1; + + // Used in rop(). + private static final long MASK_63 = (1L << 63) - 1; + + // Used for left-to-tight digit extraction. + private static final int MASK_28 = (1 << 28) - 1; + + private static final int NON_SPECIAL = 0; + private static final int PLUS_ZERO = 1; + private static final int MINUS_ZERO = 2; + private static final int PLUS_INF = 3; + private static final int MINUS_INF = 4; + private static final int NAN = 5; + + // For thread-safety, each thread gets its own instance of this class. + private static final ThreadLocal threadLocal = + ThreadLocal.withInitial(DoubleToDecimal::new); + + /* + Room for the longer of the forms + -ddddd.dddddddddddd H + 2 characters + -0.00ddddddddddddddddd H + 5 characters + -d.ddddddddddddddddE-eee H + 7 characters + where there are H digits d + */ + public final int MAX_CHARS = H + 7; + + // Numerical results are created here... + private final byte[] bytes = new byte[MAX_CHARS]; + + // ... and copied here in appendTo() + private final char[] chars = new char[MAX_CHARS]; + + // Index into bytes of rightmost valid character. + private int index; + + private DoubleToDecimal() { + } + + /** + * Returns a string rendering of the {@code double} argument. + * + *

        The characters of the result are all drawn from the ASCII set. + *

          + *
        • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
        • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
        • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
        • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
        • A finite positive {@code v} is rendered in two stages: + *
            + *
          • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
          • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. + *
          + *
        + * + *

        A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

        The decimal dv + * for a finite positive {@code v} is defined as follows: + *

          + *
        • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
        • Let m be the minimal length over all decimals in R. + *
        • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
        • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
        + * + *

        The (uniquely) selected decimal dv + * is then formatted. + * + *

        Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

          + *
        • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
        • Case 0 ≤ e < 7: + *
            + *
          • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
          • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
          + *
        • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
            + *
          • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
          • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
          + *
        + * + * @param v the {@code double} to be rendered. + * @return a string rendering of the argument. + */ + public static String toString(double v) { + return threadLocalInstance().toDecimalString(v); + } + + /** + * Appends the rendering of the {@code v} to {@code app}. + * + *

        The outcome is the same as if {@code v} were first + * {@link #toString(double) rendered} and the resulting string were then + * {@link Appendable#append(CharSequence) appended} to {@code app}. + * + * @param v the {@code double} whose rendering is appended. + * @param app the {@link Appendable} to append to. + * @throws IOException If an I/O error occurs + */ + public static Appendable appendTo(double v, Appendable app) + throws IOException { + return threadLocalInstance().appendDecimalTo(v, app); + } + + private static DoubleToDecimal threadLocalInstance() { + return threadLocal.get(); + } + + private String toDecimalString(double v) { + switch (toDecimal(v)) { + case NON_SPECIAL: return charsToString(); + case PLUS_ZERO: return "0.0"; + case MINUS_ZERO: return "-0.0"; + case PLUS_INF: return "Infinity"; + case MINUS_INF: return "-Infinity"; + default: return "NaN"; + } + } + + private Appendable appendDecimalTo(double v, Appendable app) + throws IOException { + switch (toDecimal(v)) { + case NON_SPECIAL: + for (int i = 0; i <= index; ++i) { + chars[i] = (char) bytes[i]; + } + if (app instanceof StringBuilder) { + return ((StringBuilder) app).append(chars, 0, index + 1); + } + if (app instanceof StringBuffer) { + return ((StringBuffer) app).append(chars, 0, index + 1); + } + for (int i = 0; i <= index; ++i) { + app.append(chars[i]); + } + return app; + case PLUS_ZERO: return app.append("0.0"); + case MINUS_ZERO: return app.append("-0.0"); + case PLUS_INF: return app.append("Infinity"); + case MINUS_INF: return app.append("-Infinity"); + default: return app.append("NaN"); + } + } + + /* + Returns + PLUS_ZERO iff v is 0.0 + MINUS_ZERO iff v is -0.0 + PLUS_INF iff v is POSITIVE_INFINITY + MINUS_INF iff v is NEGATIVE_INFINITY + NAN iff v is NaN + */ + private int toDecimal(double v) { + /* + For full details see references [2] and [1]. + + For finite v != 0, determine integers c and q such that + |v| = c 2^q and + Q_MIN <= q <= Q_MAX and + either 2^(P-1) <= c < 2^P (normal) + or 0 < c < 2^(P-1) and q = Q_MIN (subnormal) + */ + long bits = doubleToRawLongBits(v); + long t = bits & T_MASK; + int bq = (int) (bits >>> P - 1) & BQ_MASK; + if (bq < BQ_MASK) { + index = -1; + if (bits < 0) { + append('-'); + } + if (bq != 0) { + // normal value. Here mq = -q + int mq = -Q_MIN + 1 - bq; + long c = C_MIN | t; + // The fast path discussed in section 8.2 of [1]. + if (0 < mq & mq < P) { + long f = c >> mq; + if (f << mq == c) { + return toChars(f, 0); + } + } + return toDecimal(-mq, c, 0); + } + if (t != 0) { + // subnormal value + return t < C_TINY + ? toDecimal(Q_MIN, 10 * t, -1) + : toDecimal(Q_MIN, t, 0); + } + return bits == 0 ? PLUS_ZERO : MINUS_ZERO; + } + if (t != 0) { + return NAN; + } + return bits > 0 ? PLUS_INF : MINUS_INF; + } + + private int toDecimal(int q, long c, int dk) { + /* + The skeleton corresponds to figure 4 of [1]. + The efficient computations are those summarized in figure 7. + + Here's a correspondence between Java names and names in [1], + expressed as approximate LaTeX source code and informally. + Other names are identical. + cb: \bar{c} "c-bar" + cbr: \bar{c}_r "c-bar-r" + cbl: \bar{c}_l "c-bar-l" + + vb: \bar{v} "v-bar" + vbr: \bar{v}_r "v-bar-r" + vbl: \bar{v}_l "v-bar-l" + + rop: r_o' "r-o-prime" + */ + int out = (int) c & 0x1; + long cb = c << 2; + long cbr = cb + 2; + long cbl; + int k; + /* + flog10pow2(e) = floor(log_10(2^e)) + flog10threeQuartersPow2(e) = floor(log_10(3/4 2^e)) + flog2pow10(e) = floor(log_2(10^e)) + */ + if (c != C_MIN | q == Q_MIN) { + // regular spacing + cbl = cb - 2; + k = flog10pow2(q); + } else { + // irregular spacing + cbl = cb - 1; + k = flog10threeQuartersPow2(q); + } + int h = q + flog2pow10(-k) + 2; + + // g1 and g0 are as in section 9.9.3 of [1], so g = g1 2^63 + g0 + long g1 = g1(k); + long g0 = g0(k); + + long vb = rop(g1, g0, cb << h); + long vbl = rop(g1, g0, cbl << h); + long vbr = rop(g1, g0, cbr << h); + + long s = vb >> 2; + if (s >= 100) { + /* + For n = 17, m = 1 the table in section 10 of [1] shows + s' = floor(s / 10) = floor(s 115_292_150_460_684_698 / 2^60) + = floor(s 115_292_150_460_684_698 2^4 / 2^64) + + sp10 = 10 s' + tp10 = 10 t' + upin iff u' = sp10 10^k in Rv + wpin iff w' = tp10 10^k in Rv + See section 9.4 of [1]. + */ + long sp10 = 10 * multiplyHigh(s, 115_292_150_460_684_698L << 4); + long tp10 = sp10 + 10; + boolean upin = vbl + out <= sp10 << 2; + boolean wpin = (tp10 << 2) + out <= vbr; + if (upin != wpin) { + return toChars(upin ? sp10 : tp10, k); + } + } + + /* + 10 <= s < 100 or s >= 100 and u', w' not in Rv + uin iff u = s 10^k in Rv + win iff w = t 10^k in Rv + See section 9.4 of [1]. + */ + long t = s + 1; + boolean uin = vbl + out <= s << 2; + boolean win = (t << 2) + out <= vbr; + if (uin != win) { + // Exactly one of u or w lies in Rv. + return toChars(uin ? s : t, k + dk); + } + /* + Both u and w lie in Rv: determine the one closest to v. + See section 9.4 of [1]. + */ + long cmp = vb - (s + t << 1); + return toChars(cmp < 0 || cmp == 0 && (s & 0x1) == 0 ? s : t, k + dk); + } + + /* + Computes rop(cp g 2^(-127)), where g = g1 2^63 + g0 + See section 9.10 and figure 5 of [1]. + */ + private static long rop(long g1, long g0, long cp) { + long x1 = multiplyHigh(g0, cp); + long y0 = g1 * cp; + long y1 = multiplyHigh(g1, cp); + long z = (y0 >>> 1) + x1; + long vbp = y1 + (z >>> 63); + return vbp | (z & MASK_63) + MASK_63 >>> 63; + } + + /* + Formats the decimal f 10^e. + */ + private int toChars(long f, int e) { + /* + For details not discussed here see section 10 of [1]. + + Determine len such that + 10^(len-1) <= f < 10^len + */ + int len = flog10pow2(Long.SIZE - numberOfLeadingZeros(f)); + if (f >= pow10(len)) { + len += 1; + } + + /* + Let fp and ep be the original f and e, respectively. + Transform f and e to ensure + 10^(H-1) <= f < 10^H + fp 10^ep = f 10^(e-H) = 0.f 10^e + */ + f *= pow10(H - len); + e += len; + + /* + The toChars?() methods perform left-to-right digits extraction + using ints, provided that the arguments are limited to 8 digits. + Therefore, split the H = 17 digits of f into: + h = the most significant digit of f + m = the next 8 most significant digits of f + l = the last 8, least significant digits of f + + For n = 17, m = 8 the table in section 10 of [1] shows + floor(f / 10^8) = floor(193_428_131_138_340_668 f / 2^84) = + floor(floor(193_428_131_138_340_668 f / 2^64) / 2^20) + and for n = 9, m = 8 + floor(hm / 10^8) = floor(1_441_151_881 hm / 2^57) + */ + long hm = multiplyHigh(f, 193_428_131_138_340_668L) >>> 20; + int l = (int) (f - 100_000_000L * hm); + int h = (int) (hm * 1_441_151_881L >>> 57); + int m = (int) (hm - 100_000_000 * h); + + if (0 < e && e <= 7) { + return toChars1(h, m, l, e); + } + if (-3 < e && e <= 0) { + return toChars2(h, m, l, e); + } + return toChars3(h, m, l, e); + } + + private int toChars1(int h, int m, int l, int e) { + /* + 0 < e <= 7: plain format without leading zeroes. + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + appendDigit(h); + int y = y(m); + int t; + int i = 1; + for (; i < e; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + append('.'); + for (; i <= 8; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + lowDigits(l); + return NON_SPECIAL; + } + + private int toChars2(int h, int m, int l, int e) { + // -3 < e <= 0: plain format with leading zeroes. + appendDigit(0); + append('.'); + for (; e < 0; ++e) { + appendDigit(0); + } + appendDigit(h); + append8Digits(m); + lowDigits(l); + return NON_SPECIAL; + } + + private int toChars3(int h, int m, int l, int e) { + // -3 >= e | e > 7: computerized scientific notation + appendDigit(h); + append('.'); + append8Digits(m); + lowDigits(l); + exponent(e - 1); + return NON_SPECIAL; + } + + private void lowDigits(int l) { + if (l != 0) { + append8Digits(l); + } + removeTrailingZeroes(); + } + + private void append8Digits(int m) { + /* + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + int y = y(m); + for (int i = 0; i < 8; ++i) { + int t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + } + + private void removeTrailingZeroes() { + while (bytes[index] == '0') { + --index; + } + // ... but do not remove the one directly to the right of '.' + if (bytes[index] == '.') { + ++index; + } + } + + private int y(int a) { + /* + Algorithm 1 in [3] needs computation of + floor((a + 1) 2^n / b^k) - 1 + with a < 10^8, b = 10, k = 8, n = 28. + Noting that + (a + 1) 2^n <= 10^8 2^28 < 10^17 + For n = 17, m = 8 the table in section 10 of [1] leads to: + */ + return (int) (multiplyHigh( + (long) (a + 1) << 28, + 193_428_131_138_340_668L) >>> 20) - 1; + } + + private void exponent(int e) { + append('E'); + if (e < 0) { + append('-'); + e = -e; + } + if (e < 10) { + appendDigit(e); + return; + } + int d; + if (e >= 100) { + /* + For n = 3, m = 2 the table in section 10 of [1] shows + floor(e / 100) = floor(1_311 e / 2^17) + */ + d = e * 1_311 >>> 17; + appendDigit(d); + e -= 100 * d; + } + /* + For n = 2, m = 1 the table in section 10 of [1] shows + floor(e / 10) = floor(103 e / 2^10) + */ + d = e * 103 >>> 10; + appendDigit(d); + appendDigit(e - 10 * d); + } + + private void append(int c) { + bytes[++index] = (byte) c; + } + + private void appendDigit(int d) { + bytes[++index] = (byte) ('0' + d); + } + + // Using the deprecated constructor enhances performance. + @SuppressWarnings("deprecation") + private String charsToString() { + return new String(bytes, 0, 0, index + 1); + } + +} diff --git a/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java new file mode 100644 --- /dev/null +++ b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java @@ -0,0 +1,617 @@ +/* + * Copyright 2018-2020 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +import java.io.IOException; + +import static java.lang.Float.*; +import static java.lang.Integer.*; +import static java.lang.Math.multiplyHigh; +import static jdk.internal.math.MathUtils.*; + +/** + * This class exposes a method to render a {@code float} as a string. + * + * @author Raffaello Giulietti + */ +final public class FloatToDecimal { + /* + For full details about this code see the following references: + + [1] Giulietti, "The Schubfach way to render doubles", + https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN + + [2] IEEE Computer Society, "IEEE Standard for Floating-Point Arithmetic" + + [3] Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion" + + Divisions are avoided altogether for the benefit of those architectures + that do not provide specific machine instructions or where they are slow. + This is discussed in section 10 of [1]. + */ + + // The precision in bits. + static final int P = 24; + + // Exponent width in bits. + private static final int W = (Float.SIZE - 1) - (P - 1); + + // Minimum value of the exponent: -(2^(W-1)) - P + 3. + static final int Q_MIN = (-1 << W - 1) - P + 3; + + // Maximum value of the exponent: 2^(W-1) - P. + static final int Q_MAX = (1 << W - 1) - P; + + // 10^(E_MIN - 1) <= MIN_VALUE < 10^E_MIN + static final int E_MIN = -44; + + // 10^(E_MAX - 1) <= MAX_VALUE < 10^E_MAX + static final int E_MAX = 39; + + // Threshold to detect tiny values, as in section 8.1.1 of [1] + static final int C_TINY = 8; + + // The minimum and maximum k, as in section 8 of [1] + static final int K_MIN = -45; + static final int K_MAX = 31; + + // H is as in section 8 of [1]. + static final int H = 9; + + // Minimum value of the significand of a normal value: 2^(P-1). + private static final int C_MIN = 1 << P - 1; + + // Mask to extract the biased exponent. + private static final int BQ_MASK = (1 << W) - 1; + + // Mask to extract the fraction bits. + private static final int T_MASK = (1 << P - 1) - 1; + + // Used in rop(). + private static final long MASK_32 = (1L << 32) - 1; + + // Used for left-to-tight digit extraction. + private static final int MASK_28 = (1 << 28) - 1; + + private static final int NON_SPECIAL = 0; + private static final int PLUS_ZERO = 1; + private static final int MINUS_ZERO = 2; + private static final int PLUS_INF = 3; + private static final int MINUS_INF = 4; + private static final int NAN = 5; + + // For thread-safety, each thread gets its own instance of this class. + private static final ThreadLocal threadLocal = + ThreadLocal.withInitial(FloatToDecimal::new); + + /* + Room for the longer of the forms + -ddddd.dddd H + 2 characters + -0.00ddddddddd H + 5 characters + -d.ddddddddE-ee H + 6 characters + where there are H digits d + */ + public final int MAX_CHARS = H + 6; + + // Numerical results are created here... + private final byte[] bytes = new byte[MAX_CHARS]; + + // ... and copied here in appendTo() + private final char[] chars = new char[MAX_CHARS]; + + // Index into buf of rightmost valid character. + private int index; + + private FloatToDecimal() { + } + + /** + * Returns a string rendering of the {@code float} argument. + * + *

        The characters of the result are all drawn from the ASCII set. + *

          + *
        • Any NaN, whether quiet or signaling, is rendered as + * {@code "NaN"}, regardless of the sign bit. + *
        • The infinities +∞ and -∞ are rendered as + * {@code "Infinity"} and {@code "-Infinity"}, respectively. + *
        • The positive and negative zeroes are rendered as + * {@code "0.0"} and {@code "-0.0"}, respectively. + *
        • A finite negative {@code v} is rendered as the sign + * '{@code -}' followed by the rendering of the magnitude -{@code v}. + *
        • A finite positive {@code v} is rendered in two stages: + *
            + *
          • Selection of a decimal: A well-defined + * decimal dv is selected + * to represent {@code v}. + *
          • Formatting as a string: The decimal + * dv is formatted as a string, + * either in plain or in computerized scientific notation, + * depending on its value. + *
          + *
        + * + *

        A decimal is a number of the form + * d×10i + * for some (unique) integers d > 0 and i such that + * d is not a multiple of 10. + * These integers are the significand and + * the exponent, respectively, of the decimal. + * The length of the decimal is the (unique) + * integer n meeting + * 10n-1 ≤ d < 10n. + * + *

        The decimal dv + * for a finite positive {@code v} is defined as follows: + *

          + *
        • Let R be the set of all decimals that round to {@code v} + * according to the usual round-to-closest rule of + * IEEE 754 floating-point arithmetic. + *
        • Let m be the minimal length over all decimals in R. + *
        • When m ≥ 2, let T be the set of all decimals + * in R with length m. + * Otherwise, let T be the set of all decimals + * in R with length 1 or 2. + *
        • Define dv as + * the decimal in T that is closest to {@code v}. + * Or if there are two such decimals in T, + * select the one with the even significand (there is exactly one). + *
        + * + *

        The (uniquely) selected decimal dv + * is then formatted. + * + *

        Let d, i and n be the significand, exponent and + * length of dv, respectively. + * Further, let e = n + i - 1 and let + * d1…dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

          + *
        • Case -3 ≤ e < 0: + * dv is formatted as + * 0.0…0d1…dn, + * where there are exactly -(n + i) zeroes between + * the decimal point and d1. + * For example, 123 × 10-4 is formatted as + * {@code 0.0123}. + *
        • Case 0 ≤ e < 7: + *
            + *
          • Subcase i ≥ 0: + * dv is formatted as + * d1…dn0…0.0, + * where there are exactly i zeroes + * between dn and the decimal point. + * For example, 123 × 102 is formatted as + * {@code 12300.0}. + *
          • Subcase i < 0: + * dv is formatted as + * d1…dn+i.dn+i+1…dn. + * There are exactly -i digits to the right of + * the decimal point. + * For example, 123 × 10-1 is formatted as + * {@code 12.3}. + *
          + *
        • Case e < -3 or e ≥ 7: + * computerized scientific notation is used to format + * dv. + * Here e is formatted as by {@link Integer#toString(int)}. + *
            + *
          • Subcase n = 1: + * dv is formatted as + * d1.0Ee. + * For example, 1 × 1023 is formatted as + * {@code 1.0E23}. + *
          • Subcase n > 1: + * dv is formatted as + * d1.d2…dnEe. + * For example, 123 × 10-21 is formatted as + * {@code 1.23E-19}. + *
          + *
        + * + * @param v the {@code float} to be rendered. + * @return a string rendering of the argument. + */ + public static String toString(float v) { + return threadLocalInstance().toDecimalString(v); + } + + /** + * Appends the rendering of the {@code v} to {@code app}. + * + *

        The outcome is the same as if {@code v} were first + * {@link #toString(float) rendered} and the resulting string were then + * {@link Appendable#append(CharSequence) appended} to {@code app}. + * + * @param v the {@code float} whose rendering is appended. + * @param app the {@link Appendable} to append to. + * @throws IOException If an I/O error occurs + */ + public static Appendable appendTo(float v, Appendable app) + throws IOException { + return threadLocalInstance().appendDecimalTo(v, app); + } + + private static FloatToDecimal threadLocalInstance() { + return threadLocal.get(); + } + + private String toDecimalString(float v) { + switch (toDecimal(v)) { + case NON_SPECIAL: return charsToString(); + case PLUS_ZERO: return "0.0"; + case MINUS_ZERO: return "-0.0"; + case PLUS_INF: return "Infinity"; + case MINUS_INF: return "-Infinity"; + default: return "NaN"; + } + } + + private Appendable appendDecimalTo(float v, Appendable app) + throws IOException { + switch (toDecimal(v)) { + case NON_SPECIAL: + for (int i = 0; i <= index; ++i) { + chars[i] = (char) bytes[i]; + } + if (app instanceof StringBuilder) { + return ((StringBuilder) app).append(chars, 0, index + 1); + } + if (app instanceof StringBuffer) { + return ((StringBuffer) app).append(chars, 0, index + 1); + } + for (int i = 0; i <= index; ++i) { + app.append(chars[i]); + } + return app; + case PLUS_ZERO: return app.append("0.0"); + case MINUS_ZERO: return app.append("-0.0"); + case PLUS_INF: return app.append("Infinity"); + case MINUS_INF: return app.append("-Infinity"); + default: return app.append("NaN"); + } + } + + /* + Returns + PLUS_ZERO iff v is 0.0 + MINUS_ZERO iff v is -0.0 + PLUS_INF iff v is POSITIVE_INFINITY + MINUS_INF iff v is NEGATIVE_INFINITY + NAN iff v is NaN + */ + private int toDecimal(float v) { + /* + For full details see references [2] and [1]. + + For finite v != 0, determine integers c and q such that + |v| = c 2^q and + Q_MIN <= q <= Q_MAX and + either 2^(P-1) <= c < 2^P (normal) + or 0 < c < 2^(P-1) and q = Q_MIN (subnormal) + */ + int bits = floatToRawIntBits(v); + int t = bits & T_MASK; + int bq = (bits >>> P - 1) & BQ_MASK; + if (bq < BQ_MASK) { + index = -1; + if (bits < 0) { + append('-'); + } + if (bq != 0) { + // normal value. Here mq = -q + int mq = -Q_MIN + 1 - bq; + int c = C_MIN | t; + // The fast path discussed in section 8.2 of [1]. + if (0 < mq & mq < P) { + int f = c >> mq; + if (f << mq == c) { + return toChars(f, 0); + } + } + return toDecimal(-mq, c, 0); + } + if (t != 0) { + // subnormal value + return t < C_TINY + ? toDecimal(Q_MIN, 10 * t, -1) + : toDecimal(Q_MIN, t, 0); + } + return bits == 0 ? PLUS_ZERO : MINUS_ZERO; + } + if (t != 0) { + return NAN; + } + return bits > 0 ? PLUS_INF : MINUS_INF; + } + + private int toDecimal(int q, int c, int dk) { + /* + The skeleton corresponds to figure 4 of [1]. + The efficient computations are those summarized in figure 7. + Also check the appendix. + + Here's a correspondence between Java names and names in [1], + expressed as approximate LaTeX source code and informally. + Other names are identical. + cb: \bar{c} "c-bar" + cbr: \bar{c}_r "c-bar-r" + cbl: \bar{c}_l "c-bar-l" + + vb: \bar{v} "v-bar" + vbr: \bar{v}_r "v-bar-r" + vbl: \bar{v}_l "v-bar-l" + + rop: r_o' "r-o-prime" + */ + int out = c & 0x1; + long cb = c << 2; + long cbr = cb + 2; + long cbl; + int k; + /* + flog10pow2(e) = floor(log_10(2^e)) + flog10threeQuartersPow2(e) = floor(log_10(3/4 2^e)) + flog2pow10(e) = floor(log_2(10^e)) + */ + if (c != C_MIN | q == Q_MIN) { + // regular spacing + cbl = cb - 2; + k = flog10pow2(q); + } else { + // irregular spacing0 + cbl = cb - 1; + k = flog10threeQuartersPow2(q); + } + int h = q + flog2pow10(-k) + 33; + + // g is as in the appendix + long g = g1(k) + 1; + + int vb = rop(g, cb << h); + int vbl = rop(g, cbl << h); + int vbr = rop(g, cbr << h); + + int s = vb >> 2; + if (s >= 100) { + /* + For n = 9, m = 1 the table in section 10 of [1] shows + s' = floor(s / 10) = floor(s 1_717_986_919 / 2^34) + + sp10 = 10 s' + tp10 = 10 t' + upin iff u' = sp10 10^k in Rv + wpin iff w' = tp10 10^k in Rv + See section 9.4 of [1]. + */ + int sp10 = 10 * (int) (s * 1_717_986_919L >>> 34); + int tp10 = sp10 + 10; + boolean upin = vbl + out <= sp10 << 2; + boolean wpin = (tp10 << 2) + out <= vbr; + if (upin != wpin) { + return toChars(upin ? sp10 : tp10, k); + } + } + + /* + 10 <= s < 100 or s >= 100 and u', w' not in Rv + uin iff u = s 10^k in Rv + win iff w = t 10^k in Rv + See section 9.4 of [1]. + */ + int t = s + 1; + boolean uin = vbl + out <= s << 2; + boolean win = (t << 2) + out <= vbr; + if (uin != win) { + // Exactly one of u or w lies in Rv. + return toChars(uin ? s : t, k + dk); + } + /* + Both u and w lie in Rv: determine the one closest to v. + See section 9.4 of [1]. + */ + int cmp = vb - (s + t << 1); + return toChars(cmp < 0 || cmp == 0 && (s & 0x1) == 0 ? s : t, k + dk); + } + + /* + Computes rop(cp g 2^(-95)) + See appendix and figure 8 of [1]. + */ + private static int rop(long g, long cp) { + long x1 = multiplyHigh(g, cp); + long vbp = x1 >>> 31; + return (int) (vbp | (x1 & MASK_32) + MASK_32 >>> 32); + } + + /* + Formats the decimal f 10^e. + */ + private int toChars(int f, int e) { + /* + For details not discussed here see section 10 of [1]. + + Determine len such that + 10^(len-1) <= f < 10^len + */ + int len = flog10pow2(Integer.SIZE - numberOfLeadingZeros(f)); + if (f >= pow10(len)) { + len += 1; + } + + /* + Let fp and ep be the original f and e, respectively. + Transform f and e to ensure + 10^(H-1) <= f < 10^H + fp 10^ep = f 10^(e-H) = 0.f 10^e + */ + f *= pow10(H - len); + e += len; + + /* + The toChars?() methods perform left-to-right digits extraction + using ints, provided that the arguments are limited to 8 digits. + Therefore, split the H = 9 digits of f into: + h = the most significant digit of f + l = the last 8, least significant digits of f + + For n = 9, m = 8 the table in section 10 of [1] shows + floor(f / 10^8) = floor(1_441_151_881 f / 2^57) + */ + int h = (int) (f * 1_441_151_881L >>> 57); + int l = f - 100_000_000 * h; + + if (0 < e && e <= 7) { + return toChars1(h, l, e); + } + if (-3 < e && e <= 0) { + return toChars2(h, l, e); + } + return toChars3(h, l, e); + } + + private int toChars1(int h, int l, int e) { + /* + 0 < e <= 7: plain format without leading zeroes. + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + appendDigit(h); + int y = y(l); + int t; + int i = 1; + for (; i < e; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + append('.'); + for (; i <= 8; ++i) { + t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + removeTrailingZeroes(); + return NON_SPECIAL; + } + + private int toChars2(int h, int l, int e) { + // -3 < e <= 0: plain format with leading zeroes. + appendDigit(0); + append('.'); + for (; e < 0; ++e) { + appendDigit(0); + } + appendDigit(h); + append8Digits(l); + removeTrailingZeroes(); + return NON_SPECIAL; + } + + private int toChars3(int h, int l, int e) { + // -3 >= e | e > 7: computerized scientific notation + appendDigit(h); + append('.'); + append8Digits(l); + removeTrailingZeroes(); + exponent(e - 1); + return NON_SPECIAL; + } + + private void append8Digits(int m) { + /* + Left-to-right digits extraction: + algorithm 1 in [3], with b = 10, k = 8, n = 28. + */ + int y = y(m); + for (int i = 0; i < 8; ++i) { + int t = 10 * y; + appendDigit(t >>> 28); + y = t & MASK_28; + } + } + + private void removeTrailingZeroes() { + while (bytes[index] == '0') { + --index; + } + // ... but do not remove the one directly to the right of '.' + if (bytes[index] == '.') { + ++index; + } + } + + private int y(int a) { + /* + Algorithm 1 in [3] needs computation of + floor((a + 1) 2^n / b^k) - 1 + with a < 10^8, b = 10, k = 8, n = 28. + Noting that + (a + 1) 2^n <= 10^8 2^28 < 10^17 + For n = 17, m = 8 the table in section 10 of [1] leads to: + */ + return (int) (multiplyHigh( + (long) (a + 1) << 28, + 193_428_131_138_340_668L) >>> 20) - 1; + } + + private void exponent(int e) { + append('E'); + if (e < 0) { + append('-'); + e = -e; + } + if (e < 10) { + appendDigit(e); + return; + } + /* + For n = 2, m = 1 the table in section 10 of [1] shows + floor(e / 10) = floor(103 e / 2^10) + */ + int d = e * 103 >>> 10; + appendDigit(d); + appendDigit(e - 10 * d); + } + + private void append(int c) { + bytes[++index] = (byte) c; + } + + private void appendDigit(int d) { + bytes[++index] = (byte) ('0' + d); + } + + // Using the deprecated constructor enhances performance. + @SuppressWarnings("deprecation") + private String charsToString() { + return new String(bytes, 0, 0, index + 1); + } + +} diff --git a/src/java.base/share/classes/jdk/internal/math/MathUtils.java b/src/java.base/share/classes/jdk/internal/math/MathUtils.java new file mode 100644 --- /dev/null +++ b/src/java.base/share/classes/jdk/internal/math/MathUtils.java @@ -0,0 +1,811 @@ +/* + * Copyright 2018-2020 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +/** + * This class exposes package private utilities for other classes. + * Thus, all methods are assumed to be invoked with correct arguments, + * so these are not checked at all. + * + * @author Raffaello Giulietti + */ +final class MathUtils { + /* + For full details about this code see the following reference: + + Giulietti, "The Schubfach way to render doubles", + https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN + */ + + /* + The boundaries for k in g0(int) and g1(int). + K_MIN must be DoubleToDecimal.K_MIN or less. + K_MAX must be DoubleToDecimal.K_MAX or more. + */ + static final int K_MIN = -324; + static final int K_MAX = 292; + + // Must be DoubleToDecimal.H or more + static final int H = 17; + + // C_10 = floor(log10(2) * 2^Q_10), A_10 = floor(log10(3/4) * 2^Q_10) + private static final int Q_10 = 41; + private static final long C_10 = 661_971_961_083L; + private static final long A_10 = -274_743_187_321L; + + // C_2 = floor(log2(10) * 2^Q_2) + private static final int Q_2 = 38; + private static final long C_2 = 913_124_641_741L; + + private MathUtils() { + } + + // The first powers of 10. The last entry must be 10^H. + private static final long[] pow10 = { + 1L, + 10L, + 100L, + 1_000L, + 10_000L, + 100_000L, + 1_000_000L, + 10_000_000L, + 100_000_000L, + 1_000_000_000L, + 10_000_000_000L, + 100_000_000_000L, + 1_000_000_000_000L, + 10_000_000_000_000L, + 100_000_000_000_000L, + 1_000_000_000_000_000L, + 10_000_000_000_000_000L, + 100_000_000_000_000_000L, + }; + + /** + * Returns 10{@code e}. + * + * @param e The exponent which must meet + * 0 ≤ {@code e} ≤ {@link #H}. + * @return 10{@code e}. + */ + static long pow10(int e) { + return pow10[e]; + } + + /** + * Returns the unique integer k such that + * 10k ≤ 2{@code e} + * < 10k+1. + *

        + * The result is correct when |{@code e}| ≤ 5_456_721. + * Otherwise the result is undefined. + * + * @param e The exponent of 2, which should meet + * |{@code e}| ≤ 5_456_721 for safe results. + * @return ⌊log102{@code e}⌋. + */ + static int flog10pow2(int e) { + return (int) (e * C_10 >> Q_10); + } + + /** + * Returns the unique integer k such that + * 10k ≤ 3/4 · 2{@code e} + * < 10k+1. + *

        + * The result is correct when + * -2_956_395 ≤ {@code e} ≤ 2_500_325. + * Otherwise the result is undefined. + * + * @param e The exponent of 2, which should meet + * -2_956_395 ≤ {@code e} ≤ 2_500_325 for safe results. + * @return ⌊log10(3/4 · + * 2{@code e})⌋. + */ + static int flog10threeQuartersPow2(int e) { + return (int) (e * C_10 + A_10 >> Q_10); + } + + /** + * Returns the unique integer k such that + * 2k ≤ 10{@code e} + * < 2k+1. + *

        + * The result is correct when |{@code e}| ≤ 1_838_394. + * Otherwise the result is undefined. + * + * @param e The exponent of 10, which should meet + * |{@code e}| ≤ 1_838_394 for safe results. + * @return ⌊log210{@code e}⌋. + */ + static int flog2pow10(int e) { + return (int) (e * C_2 >> Q_2); + } + + /** + * Let 10-{@code k} = β 2r, + * for the unique pair of integer r and real β meeting + * 2125 ≤ β < 2126. + * Further, let g = ⌊β⌋ + 1. + * Split g into the higher 63 bits g1 and + * the lower 63 bits g0. Thus, + * g1 = + * ⌊g 2-63⌋ + * and + * g0 = + * g - g1 263. + *

        + * This method returns g1 while + * {@link #g0(int)} returns g0. + *

        + * If needed, the exponent r can be computed as + * r = {@code flog2pow10(-k)} - 125 (see {@link #flog2pow10(int)}). + * + * @param k The exponent of 10, which must meet + * {@link #K_MIN} ≤ {@code e} ≤ {@link #K_MAX}. + * @return g1 as described above. + */ + static long g1(int k) { + return g[k - K_MIN << 1]; + } + + /** + * Returns g0 as described in + * {@link #g1(int)}. + * + * @param k The exponent of 10, which must meet + * {@link #K_MIN} ≤ {@code e} ≤ {@link #K_MAX}. + * @return g0 as described in + * {@link #g1(int)}. + */ + static long g0(int k) { + return g[k - K_MIN << 1 | 1]; + } + + /* + The precomputed values for g1(int) and g0(int). + The first entry must be for an exponent of K_MIN or less. + The last entry must be for an exponent of K_MAX or more. + */ + private static final long[] g = { + /* -324 */ 0x4F0C_EDC9_5A71_8DD4L, 0x5B01_E8B0_9AA0_D1B5L, + /* -323 */ 0x7E7B_160E_F71C_1621L, 0x119C_A780_F767_B5EEL, + /* -322 */ 0x652F_44D8_C5B0_11B4L, 0x0E16_EC67_2C52_F7F2L, + /* -321 */ 0x50F2_9D7A_37C0_0E29L, 0x5812_56B8_F042_5FF5L, + /* -320 */ 0x40C2_1794_F966_71BAL, 0x79A8_4560_C035_1991L, + /* -319 */ 0x679C_F287_F570_B5F7L, 0x75DA_089A_CD21_C281L, + /* -318 */ 0x52E3_F539_9126_F7F9L, 0x44AE_6D48_A41B_0201L, + /* -317 */ 0x424F_F761_40EB_F994L, 0x36F1_F106_E9AF_34CDL, + /* -316 */ 0x6A19_8BCE_CE46_5C20L, 0x57E9_81A4_A918_547BL, + /* -315 */ 0x54E1_3CA5_71D1_E34DL, 0x2CBA_CE1D_5413_76C9L, + /* -314 */ 0x43E7_63B7_8E41_82A4L, 0x23C8_A4E4_4342_C56EL, + /* -313 */ 0x6CA5_6C58_E39C_043AL, 0x060D_D4A0_6B9E_08B0L, + /* -312 */ 0x56EA_BD13_E949_9CFBL, 0x1E71_76E6_BC7E_6D59L, + /* -311 */ 0x4588_9743_2107_B0C8L, 0x7EC1_2BEB_C9FE_BDE1L, + /* -310 */ 0x6F40_F205_01A5_E7A7L, 0x7E01_DFDF_A997_9635L, + /* -309 */ 0x5900_C19D_9AEB_1FB9L, 0x4B34_B319_5479_44F7L, + /* -308 */ 0x4733_CE17_AF22_7FC7L, 0x55C3_C27A_A9FA_9D93L, + /* -307 */ 0x71EC_7CF2_B1D0_CC72L, 0x5606_03F7_765D_C8EAL, + /* -306 */ 0x5B23_9728_8E40_A38EL, 0x7804_CFF9_2B7E_3A55L, + /* -305 */ 0x48E9_45BA_0B66_E93FL, 0x1337_0CC7_55FE_9511L, + /* -304 */ 0x74A8_6F90_123E_41FEL, 0x51F1_AE0B_BCCA_881BL, + /* -303 */ 0x5D53_8C73_41CB_67FEL, 0x74C1_5809_63D5_39AFL, + /* -302 */ 0x4AA9_3D29_016F_8665L, 0x43CD_E007_8310_FAF3L, + /* -301 */ 0x7775_2EA8_024C_0A3CL, 0x0616_333F_381B_2B1EL, + /* -300 */ 0x5F90_F220_01D6_6E96L, 0x3811_C298_F9AF_55B1L, + /* -299 */ 0x4C73_F4E6_67DE_BEDEL, 0x600E_3547_2E25_DE28L, + /* -298 */ 0x7A53_2170_A631_3164L, 0x3349_EED8_49D6_303FL, + /* -297 */ 0x61DC_1AC0_84F4_2783L, 0x42A1_8BE0_3B11_C033L, + /* -296 */ 0x4E49_AF00_6A5C_EC69L, 0x1BB4_6FE6_95A7_CCF5L, + /* -295 */ 0x7D42_B19A_43C7_E0A8L, 0x2C53_E63D_BC3F_AE55L, + /* -294 */ 0x6435_5AE1_CFD3_1A20L, 0x2376_51CA_FCFF_BEAAL, + /* -293 */ 0x502A_AF1B_0CA8_E1B3L, 0x35F8_416F_30CC_9888L, + /* -292 */ 0x4022_25AF_3D53_E7C2L, 0x5E60_3458_F3D6_E06DL, + /* -291 */ 0x669D_0918_621F_D937L, 0x4A33_86F4_B957_CD7BL, + /* -290 */ 0x5217_3A79_E819_7A92L, 0x6E8F_9F2A_2DDF_D796L, + /* -289 */ 0x41AC_2EC7_ECE1_2EDBL, 0x720C_7F54_F17F_DFABL, + /* -288 */ 0x6913_7E0C_AE35_17C6L, 0x1CE0_CBBB_1BFF_CC45L, + /* -287 */ 0x540F_980A_24F7_4638L, 0x171A_3C95_AFFF_D69EL, + /* -286 */ 0x433F_ACD4_EA5F_6B60L, 0x127B_63AA_F333_1218L, + /* -285 */ 0x6B99_1487_DD65_7899L, 0x6A5F_05DE_51EB_5026L, + /* -284 */ 0x5614_106C_B11D_FA14L, 0x5518_D17E_A7EF_7352L, + /* -283 */ 0x44DC_D9F0_8DB1_94DDL, 0x2A7A_4132_1FF2_C2A8L, + /* -282 */ 0x6E2E_2980_E2B5_BAFBL, 0x5D90_6850_331E_043FL, + /* -281 */ 0x5824_EE00_B55E_2F2FL, 0x6473_86A6_8F4B_3699L, + /* -280 */ 0x4683_F19A_2AB1_BF59L, 0x36C2_D21E_D908_F87BL, + /* -279 */ 0x70D3_1C29_DDE9_3228L, 0x579E_1CFE_280E_5A5DL, + /* -278 */ 0x5A42_7CEE_4B20_F4EDL, 0x2C7E_7D98_200B_7B7EL, + /* -277 */ 0x4835_30BE_A280_C3F1L, 0x09FE_CAE0_19A2_C932L, + /* -276 */ 0x7388_4DFD_D0CE_064EL, 0x4331_4499_C29E_0EB6L, + /* -275 */ 0x5C6D_0B31_73D8_050BL, 0x4F5A_9D47_CEE4_D891L, + /* -274 */ 0x49F0_D5C1_2979_9DA2L, 0x72AE_E439_7250_AD41L, + /* -273 */ 0x764E_22CE_A8C2_95D1L, 0x377E_39F5_83B4_4868L, + /* -272 */ 0x5EA4_E8A5_53CE_DE41L, 0x12CB_6191_3629_D387L, + /* -271 */ 0x4BB7_2084_430B_E500L, 0x756F_8140_F821_7605L, + /* -270 */ 0x7925_00D3_9E79_6E67L, 0x6F18_CECE_59CF_233CL, + /* -269 */ 0x60EA_670F_B1FA_BEB9L, 0x3F47_0BD8_47D8_E8FDL, + /* -268 */ 0x4D88_5272_F4C8_9894L, 0x329F_3CAD_0647_20CAL, + /* -267 */ 0x7C0D_50B7_EE0D_C0EDL, 0x3765_2DE1_A3A5_0143L, + /* -266 */ 0x633D_DA2C_BE71_6724L, 0x2C50_F181_4FB7_3436L, + /* -265 */ 0x4F64_AE8A_31F4_5283L, 0x3D0D_8E01_0C92_902BL, + /* -264 */ 0x7F07_7DA9_E986_EA6BL, 0x7B48_E334_E0EA_8045L, + /* -263 */ 0x659F_97BB_2138_BB89L, 0x4907_1C2A_4D88_669DL, + /* -262 */ 0x514C_7962_80FA_2FA1L, 0x20D2_7CEE_A46D_1EE4L, + /* -261 */ 0x4109_FAB5_33FB_594DL, 0x670E_CA58_838A_7F1DL, + /* -260 */ 0x680F_F788_532B_C216L, 0x0B4A_DD5A_6C10_CB62L, + /* -259 */ 0x533F_F939_DC23_01ABL, 0x22A2_4AAE_BCDA_3C4EL, + /* -258 */ 0x4299_942E_49B5_9AEFL, 0x354E_A225_63E1_C9D8L, + /* -257 */ 0x6A8F_537D_42BC_2B18L, 0x554A_9D08_9FCF_A95AL, + /* -256 */ 0x553F_75FD_CEFC_EF46L, 0x776E_E406_E63F_BAAEL, + /* -255 */ 0x4432_C4CB_0BFD_8C38L, 0x5F8B_E99F_1E99_6225L, + /* -254 */ 0x6D1E_07AB_4662_79F4L, 0x3279_75CB_6428_9D08L, + /* -253 */ 0x574B_3955_D1E8_6190L, 0x2861_2B09_1CED_4A6DL, + /* -252 */ 0x45D5_C777_DB20_4E0DL, 0x06B4_226D_B0BD_D524L, + /* -251 */ 0x6FBC_7259_5E9A_167BL, 0x2453_6A49_1AC9_5506L, + /* -250 */ 0x5963_8EAD_E548_11FCL, 0x1D0F_883A_7BD4_4405L, + /* -249 */ 0x4782_D88B_1DD3_4196L, 0x4A72_D361_FCA9_D004L, + /* -248 */ 0x726A_F411_C952_028AL, 0x43EA_EBCF_FAA9_4CD3L, + /* -247 */ 0x5B88_C341_6DDB_353BL, 0x4FEF_230C_C887_70A9L, + /* -246 */ 0x493A_35CD_F17C_2A96L, 0x0CBF_4F3D_6D39_26EEL, + /* -245 */ 0x7529_EFAF_E8C6_AA89L, 0x6132_1862_485B_717CL, + /* -244 */ 0x5DBB_2626_53D2_2207L, 0x675B_46B5_06AF_8DFDL, + /* -243 */ 0x4AFC_1E85_0FDB_4E6CL, 0x52AF_6BC4_0559_3E64L, + /* -242 */ 0x77F9_CA6E_7FC5_4A47L, 0x377F_12D3_3BC1_FD6DL, + /* -241 */ 0x5FFB_0858_6637_6E9FL, 0x45FF_4242_9634_CABDL, + /* -240 */ 0x4CC8_D379_EB5F_8BB2L, 0x6B32_9B68_782A_3BCBL, + /* -239 */ 0x7ADA_EBF6_4565_AC51L, 0x2B84_2BDA_59DD_2C77L, + /* -238 */ 0x6248_BCC5_0451_56A7L, 0x3C69_BCAE_AE4A_89F9L, + /* -237 */ 0x4EA0_9704_0374_4552L, 0x6387_CA25_583B_A194L, + /* -236 */ 0x7DCD_BE6C_D253_A21EL, 0x05A6_103B_C05F_68EDL, + /* -235 */ 0x64A4_9857_0EA9_4E7EL, 0x37B8_0CFC_99E5_ED8AL, + /* -234 */ 0x5083_AD12_7221_0B98L, 0x2C93_3D96_E184_BE08L, + /* -233 */ 0x4069_5741_F4E7_3C79L, 0x7075_CADF_1AD0_9807L, + /* -232 */ 0x670E_F203_2171_FA5CL, 0x4D89_4498_2AE7_59A4L, + /* -231 */ 0x5272_5B35_B45B_2EB0L, 0x3E07_6A13_5585_E150L, + /* -230 */ 0x41F5_15C4_9048_F226L, 0x64D2_BB42_AAD1_810DL, + /* -229 */ 0x6988_22D4_1A0E_503EL, 0x07B7_9204_4482_6815L, + /* -228 */ 0x546C_E8A9_AE71_D9CBL, 0x1FC6_0E69_D068_5344L, + /* -227 */ 0x438A_53BA_F1F4_AE3CL, 0x196B_3EBB_0D20_429DL, + /* -226 */ 0x6C10_85F7_E987_7D2DL, 0x0F11_FDF8_1500_6A94L, + /* -225 */ 0x5673_9E5F_EE05_FDBDL, 0x58DB_3193_4400_5543L, + /* -224 */ 0x4529_4B7F_F19E_6497L, 0x60AF_5ADC_3666_AA9CL, + /* -223 */ 0x6EA8_78CC_B5CA_3A8CL, 0x344B_C493_8A3D_DDC7L, + /* -222 */ 0x5886_C70A_2B08_2ED6L, 0x5D09_6A0F_A1CB_17D2L, + /* -221 */ 0x46D2_38D4_EF39_BF12L, 0x173A_BB3F_B4A2_7975L, + /* -220 */ 0x7150_5AEE_4B8F_981DL, 0x0B91_2B99_2103_F588L, + /* -219 */ 0x5AA6_AF25_093F_ACE4L, 0x0940_EFAD_B403_2AD3L, + /* -218 */ 0x4885_58EA_6DCC_8A50L, 0x0767_2624_9002_88A9L, + /* -217 */ 0x7408_8E43_E2E0_DD4CL, 0x723E_A36D_B337_410EL, + /* -216 */ 0x5CD3_A503_1BE7_1770L, 0x5B65_4F8A_F5C5_CDA5L, + /* -215 */ 0x4A42_EA68_E31F_45F3L, 0x62B7_72D5_916B_0AEBL, + /* -214 */ 0x76D1_770E_3832_0986L, 0x0458_B7BC_1BDE_77DDL, + /* -213 */ 0x5F0D_F8D8_2CF4_D46BL, 0x1D13_C630_164B_9318L, + /* -212 */ 0x4C0B_2D79_BD90_A9EFL, 0x30DC_9E8C_DEA2_DC13L, + /* -211 */ 0x79AB_7BF5_FC1A_A97FL, 0x0160_FDAE_3104_9351L, + /* -210 */ 0x6155_FCC4_C9AE_EDFFL, 0x1AB3_FE24_F403_A90EL, + /* -209 */ 0x4DDE_63D0_A158_BE65L, 0x6229_981D_9002_EDA5L, + /* -208 */ 0x7C97_061A_9BC1_30A2L, 0x69DC_2695_B337_E2A1L, + /* -207 */ 0x63AC_04E2_1634_26E8L, 0x54B0_1EDE_28F9_821BL, + /* -206 */ 0x4FBC_D0B4_DE90_1F20L, 0x43C0_18B1_BA61_34E2L, + /* -205 */ 0x7F94_8121_6419_CB67L, 0x1F99_C11C_5D68_549DL, + /* -204 */ 0x6610_674D_E9AE_3C52L, 0x4C7B_00E3_7DED_107EL, + /* -203 */ 0x51A6_B90B_2158_3042L, 0x09FC_00B5_FE57_4065L, + /* -202 */ 0x4152_2DA2_8113_59CEL, 0x3B30_0091_9845_CD1DL, + /* -201 */ 0x6883_7C37_34EB_C2E3L, 0x784C_CDB5_C06F_AE95L, + /* -200 */ 0x539C_635F_5D89_68B6L, 0x2D0A_3E2B_0059_5877L, + /* -199 */ 0x42E3_82B2_B13A_BA2BL, 0x3DA1_CB55_99E1_1393L, + /* -198 */ 0x6B05_9DEA_B52A_C378L, 0x629C_7888_F634_EC1EL, + /* -197 */ 0x559E_17EE_F755_692DL, 0x3549_FA07_2B5D_89B1L, + /* -196 */ 0x447E_798B_F911_20F1L, 0x1107_FB38_EF7E_07C1L, + /* -195 */ 0x6D97_28DF_F4E8_34B5L, 0x01A6_5EC1_7F30_0C68L, + /* -194 */ 0x57AC_20B3_2A53_5D5DL, 0x4E1E_B234_65C0_09EDL, + /* -193 */ 0x4623_4D5C_21DC_4AB1L, 0x24E5_5B5D_1E33_3B24L, + /* -192 */ 0x7038_7BC6_9C93_AAB5L, 0x216E_F894_FD1E_C506L, + /* -191 */ 0x59C6_C96B_B076_222AL, 0x4DF2_6077_30E5_6A6CL, + /* -190 */ 0x47D2_3ABC_8D2B_4E88L, 0x3E5B_805F_5A51_21F0L, + /* -189 */ 0x72E9_F794_1512_1740L, 0x63C5_9A32_2A1B_697FL, + /* -188 */ 0x5BEE_5FA9_AA74_DF67L, 0x0304_7B5B_54E2_BACCL, + /* -187 */ 0x498B_7FBA_EEC3_E5ECL, 0x0269_FC49_10B5_623DL, + /* -186 */ 0x75AB_FF91_7E06_3CACL, 0x6A43_2D41_B455_69FBL, + /* -185 */ 0x5E23_32DA_CB38_308AL, 0x21CF_5767_C377_87FCL, + /* -184 */ 0x4B4F_5BE2_3C2C_F3A1L, 0x67D9_12B9_692C_6CCAL, + /* -183 */ 0x787E_F969_F9E1_85CFL, 0x595B_5128_A847_1476L, + /* -182 */ 0x6065_9454_C7E7_9E3FL, 0x6115_DA86_ED05_A9F8L, + /* -181 */ 0x4D1E_1043_D31F_B1CCL, 0x4DAB_1538_BD9E_2193L, + /* -180 */ 0x7B63_4D39_51CC_4FADL, 0x62AB_5527_95C9_CF52L, + /* -179 */ 0x62B5_D761_0E3D_0C8BL, 0x0222_AA86_116E_3F75L, + /* -178 */ 0x4EF7_DF80_D830_D6D5L, 0x4E82_2204_DABE_992AL, + /* -177 */ 0x7E59_659A_F381_57BCL, 0x1736_9CD4_9130_F510L, + /* -176 */ 0x6514_5148_C2CD_DFC9L, 0x5F5E_E3DD_40F3_F740L, + /* -175 */ 0x50DD_0DD3_CF0B_196EL, 0x1918_B64A_9A5C_C5CDL, + /* -174 */ 0x40B0_D7DC_A5A2_7ABEL, 0x4746_F83B_AEB0_9E3EL, + /* -173 */ 0x6781_5961_0903_F797L, 0x253E_59F9_1780_FD2FL, + /* -172 */ 0x52CD_E11A_6D9C_C612L, 0x50FE_AE60_DF9A_6426L, + /* -171 */ 0x423E_4DAE_BE17_04DBL, 0x5A65_584D_7FAE_B685L, + /* -170 */ 0x69FD_4917_968B_3AF9L, 0x10A2_26E2_65E4_573BL, + /* -169 */ 0x54CA_A0DF_ABA2_9594L, 0x0D4E_8581_EB1D_1295L, + /* -168 */ 0x43D5_4D7F_BC82_1143L, 0x243E_D134_BC17_4211L, + /* -167 */ 0x6C88_7BFF_9403_4ED2L, 0x06CA_E854_6025_3682L, + /* -166 */ 0x56D3_9666_1002_A574L, 0x6BD5_86A9_E684_2B9BL, + /* -165 */ 0x4576_11EB_4002_1DF7L, 0x0977_9EEE_5203_5616L, + /* -164 */ 0x6F23_4FDE_CCD0_2FF1L, 0x5BF2_97E3_B66B_BCEFL, + /* -163 */ 0x58E9_0CB2_3D73_598EL, 0x165B_ACB6_2B89_63F3L, + /* -162 */ 0x4720_D6F4_FDF5_E13EL, 0x4516_23C4_EFA1_1CC2L, + /* -161 */ 0x71CE_24BB_2FEF_CECAL, 0x3B56_9FA1_7F68_2E03L, + /* -160 */ 0x5B0B_5095_BFF3_0BD5L, 0x15DE_E61A_CC53_5803L, + /* -159 */ 0x48D5_DA11_665C_0977L, 0x2B18_B815_7042_ACCFL, + /* -158 */ 0x7489_5CE8_A3C6_758BL, 0x5E8D_F355_806A_AE18L, + /* -157 */ 0x5D3A_B0BA_1C9E_C46FL, 0x653E_5C44_66BB_BE7AL, + /* -156 */ 0x4A95_5A2E_7D4B_D059L, 0x3765_169D_1EFC_9861L, + /* -155 */ 0x7755_5D17_2EDF_B3C2L, 0x256E_8A94_FE60_F3CFL, + /* -154 */ 0x5F77_7DAC_257F_C301L, 0x6ABE_D543_FEB3_F63FL, + /* -153 */ 0x4C5F_97BC_EACC_9C01L, 0x3BCB_DDCF_FEF6_5E99L, + /* -152 */ 0x7A32_8C61_77AD_C668L, 0x5FAC_9619_97F0_975BL, + /* -151 */ 0x61C2_09E7_92F1_6B86L, 0x7FBD_44E1_465A_12AFL, + /* -150 */ 0x4E34_D4B9_425A_BC6BL, 0x7FCA_9D81_0514_DBBFL, + /* -149 */ 0x7D21_545B_9D5D_FA46L, 0x32DD_C8CE_6E87_C5FFL, + /* -148 */ 0x641A_A9E2_E44B_2E9EL, 0x5BE4_A0A5_2539_6B32L, + /* -147 */ 0x5015_54B5_836F_587EL, 0x7CB6_E6EA_842D_EF5CL, + /* -146 */ 0x4011_1091_35F2_AD32L, 0x3092_5255_368B_25E3L, + /* -145 */ 0x6681_B41B_8984_4850L, 0x4DB6_EA21_F0DE_A304L, + /* -144 */ 0x5201_5CE2_D469_D373L, 0x57C5_881B_2718_826AL, + /* -143 */ 0x419A_B0B5_76BB_0F8FL, 0x5FD1_39AF_527A_01EFL, + /* -142 */ 0x68F7_8122_5791_B27FL, 0x4C81_F5E5_50C3_364AL, + /* -141 */ 0x53F9_341B_7941_5B99L, 0x239B_2B1D_DA35_C508L, + /* -140 */ 0x432D_C349_2DCD_E2E1L, 0x02E2_88E4_AE91_6A6DL, + /* -139 */ 0x6B7C_6BA8_4949_6B01L, 0x516A_74A1_174F_10AEL, + /* -138 */ 0x55FD_22ED_076D_EF34L, 0x4121_F6E7_45D8_DA25L, + /* -137 */ 0x44CA_8257_3924_BF5DL, 0x1A81_9252_9E47_14EBL, + /* -136 */ 0x6E10_D08B_8EA1_322EL, 0x5D9C_1D50_FD3E_87DDL, + /* -135 */ 0x580D_73A2_D880_F4F2L, 0x17B0_1773_FDCB_9FE4L, + /* -134 */ 0x4671_294F_139A_5D8EL, 0x4626_7929_97D6_1984L, + /* -133 */ 0x70B5_0EE4_EC2A_2F4AL, 0x3D0A_5B75_BFBC_F59FL, + /* -132 */ 0x5A2A_7250_BCEE_8C3BL, 0x4A6E_AF91_6630_C47FL, + /* -131 */ 0x4821_F50D_63F2_09C9L, 0x21F2_260D_EB5A_36CCL, + /* -130 */ 0x7369_8815_6CB6_760EL, 0x6983_7016_455D_247AL, + /* -129 */ 0x5C54_6CDD_F091_F80BL, 0x6E02_C011_D117_5062L, + /* -128 */ 0x49DD_23E4_C074_C66FL, 0x719B_CCDB_0DAC_404EL, + /* -127 */ 0x762E_9FD4_6721_3D7FL, 0x68F9_47C4_E2AD_33B0L, + /* -126 */ 0x5E8B_B310_5280_FDFFL, 0x6D94_396A_4EF0_F627L, + /* -125 */ 0x4BA2_F5A6_A867_3199L, 0x3E10_2DEE_A58D_91B9L, + /* -124 */ 0x7904_BC3D_DA3E_B5C2L, 0x3019_E317_6F48_E927L, + /* -123 */ 0x60D0_9697_E1CB_C49BL, 0x4014_B5AC_5907_20ECL, + /* -122 */ 0x4D73_ABAC_B4A3_03AFL, 0x4CDD_5E23_7A6C_1A57L, + /* -121 */ 0x7BEC_45E1_2104_D2B2L, 0x47C8_969F_2A46_908AL, + /* -120 */ 0x6323_6B1A_80D0_A88EL, 0x6CA0_787F_5505_406FL, + /* -119 */ 0x4F4F_88E2_00A6_ED3FL, 0x0A19_F9FF_7737_66BFL, + /* -118 */ 0x7EE5_A7D0_010B_1531L, 0x5CF6_5CCB_F1F2_3DFEL, + /* -117 */ 0x6584_8640_00D5_AA8EL, 0x172B_7D6F_F4C1_CB32L, + /* -116 */ 0x5136_D1CC_CD77_BBA4L, 0x78EF_978C_C3CE_3C28L, + /* -115 */ 0x40F8_A7D7_0AC6_2FB7L, 0x13F2_DFA3_CFD8_3020L, + /* -114 */ 0x67F4_3FBE_77A3_7F8BL, 0x3984_9906_1959_E699L, + /* -113 */ 0x5329_CC98_5FB5_FFA2L, 0x6136_E0D1_ADE1_8548L, + /* -112 */ 0x4287_D6E0_4C91_994FL, 0x00F8_B3DA_F181_376DL, + /* -111 */ 0x6A72_F166_E0E8_F54BL, 0x1B27_862B_1C01_F247L, + /* -110 */ 0x5528_C11F_1A53_F76FL, 0x2F52_D1BC_1667_F506L, + /* -109 */ 0x4420_9A7F_4843_2C59L, 0x0C42_4163_451F_F738L, + /* -108 */ 0x6D00_F732_0D38_46F4L, 0x7A03_9BD2_0833_2526L, + /* -107 */ 0x5733_F8F4_D760_38C3L, 0x7B36_1641_A028_EA85L, + /* -106 */ 0x45C3_2D90_AC4C_FA36L, 0x2F5E_7834_8020_BB9EL, + /* -105 */ 0x6F9E_AF4D_E07B_29F0L, 0x4BCA_59ED_99CD_F8FCL, + /* -104 */ 0x594B_BF71_8062_87F3L, 0x563B_7B24_7B0B_2D96L, + /* -103 */ 0x476F_CC5A_CD1B_9FF6L, 0x11C9_2F50_626F_57ACL, + /* -102 */ 0x724C_7A2A_E1C5_CCBDL, 0x02DB_7EE7_03E5_5912L, + /* -101 */ 0x5B70_61BB_E7D1_7097L, 0x1BE2_CBEC_031D_E0DCL, + /* -100 */ 0x4926_B496_530D_F3ACL, 0x164F_0989_9C17_E716L, + /* -99 */ 0x750A_BA8A_1E7C_B913L, 0x3D4B_4275_C68C_A4F0L, + /* -98 */ 0x5DA2_2ED4_E530_940FL, 0x4AA2_9B91_6BA3_B726L, + /* -97 */ 0x4AE8_2577_1DC0_7672L, 0x6EE8_7C74_561C_9285L, + /* -96 */ 0x77D9_D58B_62CD_8A51L, 0x3173_FA53_BCFA_8408L, + /* -95 */ 0x5FE1_77A2_B571_3B74L, 0x278F_FB76_30C8_69A0L, + /* -94 */ 0x4CB4_5FB5_5DF4_2F90L, 0x1FA6_62C4_F3D3_87B3L, + /* -93 */ 0x7ABA_32BB_C986_B280L, 0x32A3_D13B_1FB8_D91FL, + /* -92 */ 0x622E_8EFC_A138_8ECDL, 0x0EE9_742F_4C93_E0E6L, + /* -91 */ 0x4E8B_A596_E760_723DL, 0x58BA_C359_0A0F_E71EL, + /* -90 */ 0x7DAC_3C24_A567_1D2FL, 0x412A_D228_1019_71C9L, + /* -89 */ 0x6489_C9B6_EAB8_E426L, 0x00EF_0E86_7347_8E3BL, + /* -88 */ 0x506E_3AF8_BBC7_1CEBL, 0x1A58_D86B_8F6C_71C9L, + /* -87 */ 0x4058_2F2D_6305_B0BCL, 0x1513_E056_0C56_C16EL, + /* -86 */ 0x66F3_7EAF_04D5_E793L, 0x3B53_0089_AD57_9BE2L, + /* -85 */ 0x525C_6558_D0AB_1FA9L, 0x15DC_006E_2446_164FL, + /* -84 */ 0x41E3_8447_0D55_B2EDL, 0x5E49_99F1_B69E_783FL, + /* -83 */ 0x696C_06D8_1555_EB15L, 0x7D42_8FE9_2430_C065L, + /* -82 */ 0x5456_6BE0_1111_88DEL, 0x3102_0CBA_835A_3384L, + /* -81 */ 0x4378_564C_DA74_6D7EL, 0x5A68_0A2E_CF7B_5C69L, + /* -80 */ 0x6BF3_BD47_C3ED_7BFDL, 0x770C_DD17_B25E_FA42L, + /* -79 */ 0x565C_976C_9CBD_FCCBL, 0x1270_B0DF_C1E5_9502L, + /* -78 */ 0x4516_DF8A_16FE_63D5L, 0x5B8D_5A4C_9B1E_10CEL, + /* -77 */ 0x6E8A_FF43_57FD_6C89L, 0x127B_C3AD_C4FC_E7B0L, + /* -76 */ 0x586F_329C_4664_56D4L, 0x0EC9_6957_D0CA_52F3L, + /* -75 */ 0x46BF_5BB0_3850_4576L, 0x3F07_8779_73D5_0F29L, + /* -74 */ 0x7132_2C4D_26E6_D58AL, 0x31A5_A58F_1FBB_4B75L, + /* -73 */ 0x5A8E_89D7_5252_446EL, 0x5AEA_EAD8_E62F_6F91L, + /* -72 */ 0x4872_07DF_750E_9D25L, 0x2F22_557A_51BF_8C74L, + /* -71 */ 0x73E9_A632_54E4_2EA2L, 0x1836_EF2A_1C65_AD86L, + /* -70 */ 0x5CBA_EB5B_771C_F21BL, 0x2CF8_BF54_E384_8AD2L, + /* -69 */ 0x4A2F_22AF_927D_8E7CL, 0x23FA_32AA_4F9D_3BDBL, + /* -68 */ 0x76B1_D118_EA62_7D93L, 0x5329_EAAA_18FB_92F8L, + /* -67 */ 0x5EF4_A747_21E8_6476L, 0x0F54_BBBB_472F_A8C6L, + /* -66 */ 0x4BF6_EC38_E7ED_1D2BL, 0x25DD_62FC_38F2_ED6CL, + /* -65 */ 0x798B_138E_3FE1_C845L, 0x22FB_D193_8E51_7BDFL, + /* -64 */ 0x613C_0FA4_FFE7_D36AL, 0x4F2F_DADC_71DA_C97FL, + /* -63 */ 0x4DC9_A61D_9986_42BBL, 0x58F3_157D_27E2_3ACCL, + /* -62 */ 0x7C75_D695_C270_6AC5L, 0x74B8_2261_D969_F7ADL, + /* -61 */ 0x6391_7877_CEC0_556BL, 0x1093_4EB4_ADEE_5FBEL, + /* -60 */ 0x4FA7_9393_0BCD_1122L, 0x4075_D890_8B25_1965L, + /* -59 */ 0x7F72_85B8_12E1_B504L, 0x00BC_8DB4_11D4_F56EL, + /* -58 */ 0x65F5_37C6_7581_5D9CL, 0x66FD_3E29_A7DD_9125L, + /* -57 */ 0x5190_F96B_9134_4AE3L, 0x6BFD_CB54_864A_DA84L, + /* -56 */ 0x4140_C789_40F6_A24FL, 0x6FFE_3C43_9EA2_486AL, + /* -55 */ 0x6867_A5A8_67F1_03B2L, 0x7FFD_2D38_FDD0_73DCL, + /* -54 */ 0x5386_1E20_5327_3628L, 0x6664_242D_97D9_F64AL, + /* -53 */ 0x42D1_B1B3_75B8_F820L, 0x51E9_B68A_DFE1_91D5L, + /* -52 */ 0x6AE9_1C52_55F4_C034L, 0x1CA9_2411_6635_B621L, + /* -51 */ 0x5587_49DB_77F7_0029L, 0x63BA_8341_1E91_5E81L, + /* -50 */ 0x446C_3B15_F992_6687L, 0x6962_029A_7EDA_B201L, + /* -49 */ 0x6D79_F823_28EA_3DA6L, 0x0F03_375D_97C4_5001L, + /* -48 */ 0x5794_C682_8721_CAEBL, 0x259C_2C4A_DFD0_4001L, + /* -47 */ 0x4610_9ECE_D281_6F22L, 0x5149_BD08_B30D_0001L, + /* -46 */ 0x701A_97B1_50CF_1837L, 0x3542_C80D_EB48_0001L, + /* -45 */ 0x59AE_DFC1_0D72_79C5L, 0x7768_A00B_22A0_0001L, + /* -44 */ 0x47BF_1967_3DF5_2E37L, 0x7920_8008_E880_0001L, + /* -43 */ 0x72CB_5BD8_6321_E38CL, 0x5B67_3341_7400_0001L, + /* -42 */ 0x5BD5_E313_8281_82D6L, 0x7C52_8F67_9000_0001L, + /* -41 */ 0x4977_E8DC_6867_9BDFL, 0x16A8_72B9_4000_0001L, + /* -40 */ 0x758C_A7C7_0D72_92FEL, 0x5773_EAC2_0000_0001L, + /* -39 */ 0x5E0A_1FD2_7128_7598L, 0x45F6_5568_0000_0001L, + /* -38 */ 0x4B3B_4CA8_5A86_C47AL, 0x04C5_1120_0000_0001L, + /* -37 */ 0x785E_E10D_5DA4_6D90L, 0x07A1_B500_0000_0001L, + /* -36 */ 0x604B_E73D_E483_8AD9L, 0x52E7_C400_0000_0001L, + /* -35 */ 0x4D09_85CB_1D36_08AEL, 0x0F1F_D000_0000_0001L, + /* -34 */ 0x7B42_6FAB_61F0_0DE3L, 0x31CC_8000_0000_0001L, + /* -33 */ 0x629B_8C89_1B26_7182L, 0x5B0A_0000_0000_0001L, + /* -32 */ 0x4EE2_D6D4_15B8_5ACEL, 0x7C08_0000_0000_0001L, + /* -31 */ 0x7E37_BE20_22C0_914BL, 0x1340_0000_0000_0001L, + /* -30 */ 0x64F9_64E6_8233_A76FL, 0x2900_0000_0000_0001L, + /* -29 */ 0x50C7_83EB_9B5C_85F2L, 0x5400_0000_0000_0001L, + /* -28 */ 0x409F_9CBC_7C4A_04C2L, 0x1000_0000_0000_0001L, + /* -27 */ 0x6765_C793_FA10_079DL, 0x0000_0000_0000_0001L, + /* -26 */ 0x52B7_D2DC_C80C_D2E4L, 0x0000_0000_0000_0001L, + /* -25 */ 0x422C_A8B0_A00A_4250L, 0x0000_0000_0000_0001L, + /* -24 */ 0x69E1_0DE7_6676_D080L, 0x0000_0000_0000_0001L, + /* -23 */ 0x54B4_0B1F_852B_DA00L, 0x0000_0000_0000_0001L, + /* -22 */ 0x43C3_3C19_3756_4800L, 0x0000_0000_0000_0001L, + /* -21 */ 0x6C6B_935B_8BBD_4000L, 0x0000_0000_0000_0001L, + /* -20 */ 0x56BC_75E2_D631_0000L, 0x0000_0000_0000_0001L, + /* -19 */ 0x4563_9182_44F4_0000L, 0x0000_0000_0000_0001L, + /* -18 */ 0x6F05_B59D_3B20_0000L, 0x0000_0000_0000_0001L, + /* -17 */ 0x58D1_5E17_6280_0000L, 0x0000_0000_0000_0001L, + /* -16 */ 0x470D_E4DF_8200_0000L, 0x0000_0000_0000_0001L, + /* -15 */ 0x71AF_D498_D000_0000L, 0x0000_0000_0000_0001L, + /* -14 */ 0x5AF3_107A_4000_0000L, 0x0000_0000_0000_0001L, + /* -13 */ 0x48C2_7395_0000_0000L, 0x0000_0000_0000_0001L, + /* -12 */ 0x746A_5288_0000_0000L, 0x0000_0000_0000_0001L, + /* -11 */ 0x5D21_DBA0_0000_0000L, 0x0000_0000_0000_0001L, + /* -10 */ 0x4A81_7C80_0000_0000L, 0x0000_0000_0000_0001L, + /* -9 */ 0x7735_9400_0000_0000L, 0x0000_0000_0000_0001L, + /* -8 */ 0x5F5E_1000_0000_0000L, 0x0000_0000_0000_0001L, + /* -7 */ 0x4C4B_4000_0000_0000L, 0x0000_0000_0000_0001L, + /* -6 */ 0x7A12_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* -5 */ 0x61A8_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* -4 */ 0x4E20_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* -3 */ 0x7D00_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* -2 */ 0x6400_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* -1 */ 0x5000_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 0 */ 0x4000_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 1 */ 0x6666_6666_6666_6666L, 0x3333_3333_3333_3334L, + /* 2 */ 0x51EB_851E_B851_EB85L, 0x0F5C_28F5_C28F_5C29L, + /* 3 */ 0x4189_374B_C6A7_EF9DL, 0x5916_872B_020C_49BBL, + /* 4 */ 0x68DB_8BAC_710C_B295L, 0x74F0_D844_D013_A92BL, + /* 5 */ 0x53E2_D623_8DA3_C211L, 0x43F3_E037_0CDC_8755L, + /* 6 */ 0x431B_DE82_D7B6_34DAL, 0x698F_E692_70B0_6C44L, + /* 7 */ 0x6B5F_CA6A_F2BD_215EL, 0x0F4C_A41D_811A_46D4L, + /* 8 */ 0x55E6_3B88_C230_E77EL, 0x3F70_834A_CDAE_9F10L, + /* 9 */ 0x44B8_2FA0_9B5A_52CBL, 0x4C5A_02A2_3E25_4C0DL, + /* 10 */ 0x6DF3_7F67_5EF6_EADFL, 0x2D5C_D103_96A2_1347L, + /* 11 */ 0x57F5_FF85_E592_557FL, 0x3DE3_DA69_454E_75D3L, + /* 12 */ 0x465E_6604_B7A8_4465L, 0x7E4F_E1ED_D10B_9175L, + /* 13 */ 0x7097_09A1_25DA_0709L, 0x4A19_697C_81AC_1BEFL, + /* 14 */ 0x5A12_6E1A_84AE_6C07L, 0x54E1_2130_67BC_E326L, + /* 15 */ 0x480E_BE7B_9D58_566CL, 0x43E7_4DC0_52FD_8285L, + /* 16 */ 0x734A_CA5F_6226_F0ADL, 0x530B_AF9A_1E62_6A6DL, + /* 17 */ 0x5C3B_D519_1B52_5A24L, 0x426F_BFAE_7EB5_21F1L, + /* 18 */ 0x49C9_7747_490E_AE83L, 0x4EBF_CC8B_9890_E7F4L, + /* 19 */ 0x760F_253E_DB4A_B0D2L, 0x4ACC_7A78_F41B_0CBAL, + /* 20 */ 0x5E72_8432_4908_8D75L, 0x223D_2EC7_29AF_3D62L, + /* 21 */ 0x4B8E_D028_3A6D_3DF7L, 0x34FD_BF05_BAF2_9781L, + /* 22 */ 0x78E4_8040_5D7B_9658L, 0x54C9_31A2_C4B7_58CFL, + /* 23 */ 0x60B6_CD00_4AC9_4513L, 0x5D6D_C14F_03C5_E0A5L, + /* 24 */ 0x4D5F_0A66_A23A_9DA9L, 0x3124_9AA5_9C9E_4D51L, + /* 25 */ 0x7BCB_43D7_69F7_62A8L, 0x4EA0_F76F_60FD_4882L, + /* 26 */ 0x6309_0312_BB2C_4EEDL, 0x254D_92BF_80CA_A068L, + /* 27 */ 0x4F3A_68DB_C8F0_3F24L, 0x1DD7_A899_33D5_4D20L, + /* 28 */ 0x7EC3_DAF9_4180_6506L, 0x62F2_A75B_8622_1500L, + /* 29 */ 0x6569_7BFA_9ACD_1D9FL, 0x025B_B916_04E8_10CDL, + /* 30 */ 0x5121_2FFB_AF0A_7E18L, 0x6849_60DE_6A53_40A4L, + /* 31 */ 0x40E7_5996_25A1_FE7AL, 0x203A_B3E5_21DC_33B6L, + /* 32 */ 0x67D8_8F56_A29C_CA5DL, 0x19F7_863B_6960_52BDL, + /* 33 */ 0x5313_A5DE_E87D_6EB0L, 0x7B2C_6B62_BAB3_7564L, + /* 34 */ 0x4276_1E4B_ED31_255AL, 0x2F56_BC4E_FBC2_C450L, + /* 35 */ 0x6A56_96DF_E1E8_3BC3L, 0x6557_93B1_92D1_3A1AL, + /* 36 */ 0x5512_124C_B4B9_C969L, 0x3779_42F4_7574_2E7BL, + /* 37 */ 0x440E_750A_2A2E_3ABAL, 0x5F94_3590_5DF6_8B96L, + /* 38 */ 0x6CE3_EE76_A9E3_912AL, 0x65B9_EF4D_6324_1289L, + /* 39 */ 0x571C_BEC5_54B6_0DBBL, 0x6AFB_25D7_8283_4207L, + /* 40 */ 0x45B0_989D_DD5E_7163L, 0x08C8_EB12_CECF_6806L, + /* 41 */ 0x6F80_F42F_C897_1BD1L, 0x5ADB_11B7_B14B_D9A3L, + /* 42 */ 0x5933_F68C_A078_E30EL, 0x157C_0E2C_8DD6_47B5L, + /* 43 */ 0x475C_C53D_4D2D_8271L, 0x5DFC_D823_A4AB_6C91L, + /* 44 */ 0x722E_0862_1515_9D82L, 0x632E_269F_6DDF_141BL, + /* 45 */ 0x5B58_06B4_DDAA_E468L, 0x4F58_1EE5_F17F_4349L, + /* 46 */ 0x4913_3890_B155_8386L, 0x72AC_E584_C132_9C3BL, + /* 47 */ 0x74EB_8DB4_4EEF_38D7L, 0x6AAE_3C07_9B84_2D2AL, + /* 48 */ 0x5D89_3E29_D8BF_60ACL, 0x5558_3006_1603_5755L, + /* 49 */ 0x4AD4_31BB_13CC_4D56L, 0x7779_C004_DE69_12ABL, + /* 50 */ 0x77B9_E92B_52E0_7BBEL, 0x258F_99A1_63DB_5111L, + /* 51 */ 0x5FC7_EDBC_424D_2FCBL, 0x37A6_1481_1CAF_740DL, + /* 52 */ 0x4C9F_F163_683D_BFD5L, 0x7951_AA00_E3BF_900BL, + /* 53 */ 0x7A99_8238_A6C9_32EFL, 0x754F_7667_D2CC_19ABL, + /* 54 */ 0x6214_682D_523A_8F26L, 0x2AA5_F853_0F09_AE22L, + /* 55 */ 0x4E76_B9BD_DB62_0C1EL, 0x5551_9375_A5A1_581BL, + /* 56 */ 0x7D8A_C2C9_5F03_4697L, 0x3BB5_B8BC_3C35_59C5L, + /* 57 */ 0x646F_023A_B269_0545L, 0x7C91_6096_9691_149EL, + /* 58 */ 0x5058_CE95_5B87_376BL, 0x16DA_B3AB_ABA7_43B2L, + /* 59 */ 0x4047_0BAA_AF9F_5F88L, 0x78AE_F622_EFB9_02F5L, + /* 60 */ 0x66D8_12AA_B298_98DBL, 0x0DE4_BD04_B2C1_9E54L, + /* 61 */ 0x5246_7555_5BAD_4715L, 0x57EA_30D0_8F01_4B76L, + /* 62 */ 0x41D1_F777_7C8A_9F44L, 0x4654_F3DA_0C01_092CL, + /* 63 */ 0x694F_F258_C744_3207L, 0x23BB_1FC3_4668_0EACL, + /* 64 */ 0x543F_F513_D29C_F4D2L, 0x4FC8_E635_D1EC_D88AL, + /* 65 */ 0x4366_5DA9_754A_5D75L, 0x263A_51C4_A7F0_AD3BL, + /* 66 */ 0x6BD6_FC42_5543_C8BBL, 0x56C3_B607_731A_AEC4L, + /* 67 */ 0x5645_969B_7769_6D62L, 0x789C_919F_8F48_8BD0L, + /* 68 */ 0x4504_787C_5F87_8AB5L, 0x46E3_A7B2_D906_D640L, + /* 69 */ 0x6E6D_8D93_CC0C_1122L, 0x3E39_0C51_5B3E_239AL, + /* 70 */ 0x5857_A476_3CD6_741BL, 0x4B60_D6A7_7C31_B615L, + /* 71 */ 0x46AC_8391_CA45_29AFL, 0x55E7_121F_968E_2B44L, + /* 72 */ 0x7114_05B6_106E_A919L, 0x0971_B698_F0E3_786DL, + /* 73 */ 0x5A76_6AF8_0D25_5414L, 0x078E_2BAD_8D82_C6BDL, + /* 74 */ 0x485E_BBF9_A41D_DCDCL, 0x6C71_BC8A_D79B_D231L, + /* 75 */ 0x73CA_C65C_39C9_6161L, 0x2D82_C744_8C2C_8382L, + /* 76 */ 0x5CA2_3849_C7D4_4DE7L, 0x3E02_3903_A356_CF9BL, + /* 77 */ 0x4A1B_603B_0643_7185L, 0x7E68_2D9C_82AB_D949L, + /* 78 */ 0x7692_3391_A39F_1C09L, 0x4A40_48FA_6AAC_8EDBL, + /* 79 */ 0x5EDB_5C74_82E5_B007L, 0x5500_3A61_EEF0_7249L, + /* 80 */ 0x4BE2_B05D_3584_8CD2L, 0x7733_61E7_F259_F507L, + /* 81 */ 0x796A_B3C8_55A0_E151L, 0x3EB8_9CA6_508F_EE71L, + /* 82 */ 0x6122_296D_114D_810DL, 0x7EFA_16EB_73A6_585BL, + /* 83 */ 0x4DB4_EDF0_DAA4_673EL, 0x3261_ABEF_8FB8_46AFL, + /* 84 */ 0x7C54_AFE7_C43A_3ECAL, 0x1D69_1318_E5F3_A44BL, + /* 85 */ 0x6376_F31F_D02E_98A1L, 0x6454_0F47_1E5C_836FL, + /* 86 */ 0x4F92_5C19_7358_7A1BL, 0x0376_729F_4B7D_35F3L, + /* 87 */ 0x7F50_935B_EBC0_C35EL, 0x38BD_8432_1261_EFEBL, + /* 88 */ 0x65DA_0F7C_BC9A_35E5L, 0x13CA_D028_0EB4_BFEFL, + /* 89 */ 0x517B_3F96_FD48_2B1DL, 0x5CA2_4020_0BC3_CCBFL, + /* 90 */ 0x412F_6612_6439_BC17L, 0x63B5_0019_A303_0A33L, + /* 91 */ 0x684B_D683_D38F_9359L, 0x1F88_0029_04D1_A9EAL, + /* 92 */ 0x536F_DECF_DC72_DC47L, 0x32D3_3354_03DA_EE55L, + /* 93 */ 0x42BF_E573_16C2_49D2L, 0x5BDC_2910_0315_8B77L, + /* 94 */ 0x6ACC_A251_BE03_A951L, 0x12F9_DB4C_D1BC_1258L, + /* 95 */ 0x5570_81DA_FE69_5440L, 0x7594_AF70_A7C9_A847L, + /* 96 */ 0x445A_017B_FEBA_A9CDL, 0x4476_F2C0_863A_ED06L, + /* 97 */ 0x6D5C_CF2C_CAC4_42E2L, 0x3A57_EACD_A391_7B3CL, + /* 98 */ 0x577D_728A_3BD0_3581L, 0x7B79_88A4_82DA_C8FDL, + /* 99 */ 0x45FD_F53B_630C_F79BL, 0x15FA_D3B6_CF15_6D97L, + /* 100 */ 0x6FFC_BB92_3814_BF5EL, 0x565E_1F8A_E4EF_15BEL, + /* 101 */ 0x5996_FC74_F9AA_32B2L, 0x11E4_E608_B725_AAFFL, + /* 102 */ 0x47AB_FD2A_6154_F55BL, 0x27EA_51A0_9284_88CCL, + /* 103 */ 0x72AC_C843_CEEE_555EL, 0x7310_829A_8407_4146L, + /* 104 */ 0x5BBD_6D03_0BF1_DDE5L, 0x4273_9BAE_D005_CDD2L, + /* 105 */ 0x4964_5735_A327_E4B7L, 0x4EC2_E2F2_4004_A4A8L, + /* 106 */ 0x756D_5855_D1D9_6DF2L, 0x4AD1_6B1D_333A_A10CL, + /* 107 */ 0x5DF1_1377_DB14_57F5L, 0x2241_227D_C295_4DA3L, + /* 108 */ 0x4B27_42C6_48DD_132AL, 0x4E9A_81FE_3544_3E1CL, + /* 109 */ 0x783E_D13D_4161_B844L, 0x175D_9CC9_EED3_9694L, + /* 110 */ 0x6032_40FD_CDE7_C69CL, 0x7917_B0A1_8BDC_7876L, + /* 111 */ 0x4CF5_00CB_0B1F_D217L, 0x1412_F3B4_6FE3_9392L, + /* 112 */ 0x7B21_9ADE_7832_E9BEL, 0x5351_85ED_7FD2_85B6L, + /* 113 */ 0x6281_48B1_F9C2_5498L, 0x42A7_9E57_9975_37C5L, + /* 114 */ 0x4ECD_D3C1_949B_76E0L, 0x3552_E512_E12A_9304L, + /* 115 */ 0x7E16_1F9C_20F8_BE33L, 0x6EEB_081E_3510_EB39L, + /* 116 */ 0x64DE_7FB0_1A60_9829L, 0x3F22_6CE4_F740_BC2EL, + /* 117 */ 0x50B1_FFC0_151A_1354L, 0x3281_F0B7_2C33_C9BEL, + /* 118 */ 0x408E_6633_4414_DC43L, 0x4201_8D5F_568F_D498L, + /* 119 */ 0x674A_3D1E_D354_939FL, 0x1CCF_4898_8A7F_BA8DL, + /* 120 */ 0x52A1_CA7F_0F76_DC7FL, 0x30A5_D3AD_3B99_620BL, + /* 121 */ 0x421B_0865_A5F8_B065L, 0x73B7_DC8A_9614_4E6FL, + /* 122 */ 0x69C4_DA3C_3CC1_1A3CL, 0x52BF_C744_2353_B0B1L, + /* 123 */ 0x549D_7B63_63CD_AE96L, 0x7566_3903_4F76_26F4L, + /* 124 */ 0x43B1_2F82_B63E_2545L, 0x4451_C735_D92B_525DL, + /* 125 */ 0x6C4E_B26A_BD30_3BA2L, 0x3A1C_71EF_C1DE_EA2EL, + /* 126 */ 0x56A5_5B88_9759_C94EL, 0x61B0_5B26_34B2_54F2L, + /* 127 */ 0x4551_1606_DF7B_0772L, 0x1AF3_7C1E_908E_AA5BL, + /* 128 */ 0x6EE8_233E_325E_7250L, 0x2B1F_2CFD_B417_76F8L, + /* 129 */ 0x58B9_B5CB_5B7E_C1D9L, 0x6F4C_23FE_29AC_5F2DL, + /* 130 */ 0x46FA_F7D5_E2CB_CE47L, 0x72A3_4FFE_87BD_18F1L, + /* 131 */ 0x7191_8C89_6ADF_B073L, 0x0438_7FFD_A5FB_5B1BL, + /* 132 */ 0x5ADA_D6D4_557F_C05CL, 0x0360_6664_84C9_15AFL, + /* 133 */ 0x48AF_1243_7799_66B0L, 0x02B3_851D_3707_448CL, + /* 134 */ 0x744B_506B_F28F_0AB3L, 0x1DEC_082E_BE72_0746L, + /* 135 */ 0x5D09_0D23_2872_6EF5L, 0x64BC_D358_985B_3905L, + /* 136 */ 0x4A6D_A41C_205B_8BF7L, 0x6A30_A913_AD15_C738L, + /* 137 */ 0x7715_D360_33C5_ACBFL, 0x5D1A_A81F_7B56_0B8CL, + /* 138 */ 0x5F44_A919_C304_8A32L, 0x7DAE_ECE5_FC44_D609L, + /* 139 */ 0x4C36_EDAE_359D_3B5BL, 0x7E25_8A51_969D_7808L, + /* 140 */ 0x79F1_7C49_EF61_F893L, 0x16A2_76E8_F0FB_F33FL, + /* 141 */ 0x618D_FD07_F2B4_C6DCL, 0x121B_9253_F3FC_C299L, + /* 142 */ 0x4E0B_30D3_2890_9F16L, 0x41AF_A843_2997_0214L, + /* 143 */ 0x7CDE_B485_0DB4_31BDL, 0x4F7F_739E_A8F1_9CEDL, + /* 144 */ 0x63E5_5D37_3E29_C164L, 0x3F99_294B_BA5A_E3F1L, + /* 145 */ 0x4FEA_B0F8_FE87_CDE9L, 0x7FAD_BAA2_FB7B_E98DL, + /* 146 */ 0x7FDD_E7F4_CA72_E30FL, 0x7F7C_5DD1_925F_DC15L, + /* 147 */ 0x664B_1FF7_085B_E8D9L, 0x4C63_7E41_41E6_49ABL, + /* 148 */ 0x51D5_B32C_06AF_ED7AL, 0x704F_9834_34B8_3AEFL, + /* 149 */ 0x4177_C289_9EF3_2462L, 0x26A6_135C_F6F9_C8BFL, + /* 150 */ 0x68BF_9DA8_FE51_D3D0L, 0x3DD6_8561_8B29_4132L, + /* 151 */ 0x53CC_7E20_CB74_A973L, 0x4B12_044E_08ED_CDC2L, + /* 152 */ 0x4309_FE80_A2C3_BAC2L, 0x6F41_9D0B_3A57_D7CEL, + /* 153 */ 0x6B43_30CD_D139_2AD1L, 0x3202_94DE_C3BF_BFB0L, + /* 154 */ 0x55CF_5A3E_40FA_88A7L, 0x419B_AA4B_CFCC_995AL, + /* 155 */ 0x44A5_E1CB_672E_D3B9L, 0x1AE2_EEA3_0CA3_ADE1L, + /* 156 */ 0x6DD6_3612_3EB1_52C1L, 0x77D1_7DD1_ADD2_AFCFL, + /* 157 */ 0x57DE_91A8_3227_7567L, 0x7974_64A7_BE42_263FL, + /* 158 */ 0x464B_A7B9_C1B9_2AB9L, 0x4790_5086_31CE_84FFL, + /* 159 */ 0x7079_0C5C_6928_445CL, 0x0C1A_1A70_4FB0_D4CCL, + /* 160 */ 0x59FA_7049_EDB9_D049L, 0x567B_4859_D95A_43D6L, + /* 161 */ 0x47FB_8D07_F161_736EL, 0x11FC_39E1_7AAE_9CABL, + /* 162 */ 0x732C_14D9_8235_857DL, 0x032D_2968_C44A_9445L, + /* 163 */ 0x5C23_43E1_34F7_9DFDL, 0x4F57_5453_D03B_A9D1L, + /* 164 */ 0x49B5_CFE7_5D92_E4CAL, 0x72AC_4376_402F_BB0EL, + /* 165 */ 0x75EF_B30B_C8EB_07ABL, 0x0446_D256_CD19_2B49L, + /* 166 */ 0x5E59_5C09_6D88_D2EFL, 0x1D05_7512_3DAD_BC3AL, + /* 167 */ 0x4B7A_B007_8AD3_DBF2L, 0x4A6A_C40E_97BE_302FL, + /* 168 */ 0x78C4_4CD8_DE1F_C650L, 0x7711_39B0_F2C9_E6B1L, + /* 169 */ 0x609D_0A47_1819_6B73L, 0x78DA_948D_8F07_EBC1L, + /* 170 */ 0x4D4A_6E9F_467A_BC5CL, 0x60AE_DD3E_0C06_5634L, + /* 171 */ 0x7BAA_4A98_70C4_6094L, 0x344A_FB96_79A3_BD20L, + /* 172 */ 0x62EE_A213_8D69_E6DDL, 0x103B_FC78_614F_CA80L, + /* 173 */ 0x4F25_4E76_0ABB_1F17L, 0x2696_6393_810C_A200L, + /* 174 */ 0x7EA2_1723_445E_9825L, 0x2423_D285_9B47_6999L, + /* 175 */ 0x654E_78E9_037E_E01DL, 0x69B6_4204_7C39_2148L, + /* 176 */ 0x510B_93ED_9C65_8017L, 0x6E2B_6803_9694_1AA0L, + /* 177 */ 0x40D6_0FF1_49EA_CCDFL, 0x71BC_5336_1210_154DL, + /* 178 */ 0x67BC_E64E_DCAA_E166L, 0x1C60_8523_5019_BBAEL, + /* 179 */ 0x52FD_850B_E3BB_E784L, 0x7D1A_041C_4014_9625L, + /* 180 */ 0x4264_6A6F_E963_1F9DL, 0x4A7B_367D_0010_781DL, + /* 181 */ 0x6A3A_43E6_4238_3295L, 0x5D91_F0C8_001A_59C8L, + /* 182 */ 0x54FB_6985_01C6_8EDEL, 0x17A7_F3D3_3348_47D4L, + /* 183 */ 0x43FC_546A_67D2_0BE4L, 0x7953_2975_C2A0_3976L, + /* 184 */ 0x6CC6_ED77_0C83_463BL, 0x0EEB_7589_3766_C256L, + /* 185 */ 0x5705_8AC5_A39C_382FL, 0x2589_2AD4_2C52_3512L, + /* 186 */ 0x459E_089E_1C7C_F9BFL, 0x37A0_EF10_2374_F742L, + /* 187 */ 0x6F63_40FC_FA61_8F98L, 0x5901_7E80_38BB_2536L, + /* 188 */ 0x591C_33FD_951A_D946L, 0x7A67_9866_93C8_EA91L, + /* 189 */ 0x4749_C331_4415_7A9FL, 0x151F_AD1E_DCA0_BBA8L, + /* 190 */ 0x720F_9EB5_39BB_F765L, 0x0832_AE97_C767_92A5L, + /* 191 */ 0x5B3F_B22A_9496_5F84L, 0x068E_F213_05EC_7551L, + /* 192 */ 0x48FF_C1BB_AA11_E603L, 0x1ED8_C1A8_D189_F774L, + /* 193 */ 0x74CC_692C_434F_D66BL, 0x4AF4_690E_1C0F_F253L, + /* 194 */ 0x5D70_5423_690C_AB89L, 0x225D_20D8_1673_2843L, + /* 195 */ 0x4AC0_434F_873D_5607L, 0x3517_4D79_AB8F_5369L, + /* 196 */ 0x779A_054C_0B95_5672L, 0x21BE_E25C_45B2_1F0EL, + /* 197 */ 0x5FAE_6AA3_3C77_785BL, 0x3498_B516_9E28_18D8L, + /* 198 */ 0x4C8B_8882_96C5_F9E2L, 0x5D46_F745_4B53_4713L, + /* 199 */ 0x7A78_DA6A_8AD6_5C9DL, 0x7BA4_BED5_4552_0B52L, + /* 200 */ 0x61FA_4855_3BDE_B07EL, 0x2FB6_FF11_0441_A2A8L, + /* 201 */ 0x4E61_D377_6318_8D31L, 0x72F8_CC0D_9D01_4EEDL, + /* 202 */ 0x7D69_5258_9E8D_AEB6L, 0x1E5A_E015_C802_17E1L, + /* 203 */ 0x6454_41E0_7ED7_BEF8L, 0x1848_B344_A001_ACB4L, + /* 204 */ 0x5043_67E6_CBDF_CBF9L, 0x603A_2903_B334_8A2AL, + /* 205 */ 0x4035_ECB8_A319_6FFBL, 0x002E_8736_28F6_D4EEL, + /* 206 */ 0x66BC_ADF4_3828_B32BL, 0x19E4_0B89_DB24_87E3L, + /* 207 */ 0x5230_8B29_C686_F5BCL, 0x14B6_6FA1_7C1D_3983L, + /* 208 */ 0x41C0_6F54_9ED2_5E30L, 0x1091_F2E7_967D_C79CL, + /* 209 */ 0x6933_E554_3150_96B3L, 0x341C_B7D8_F0C9_3F5FL, + /* 210 */ 0x5429_8443_5AA6_DEF5L, 0x767D_5FE0_C0A0_FF80L, + /* 211 */ 0x4354_69CF_7BB8_B25EL, 0x2B97_7FE7_0080_CC66L, + /* 212 */ 0x6BBA_42E5_92C1_1D63L, 0x5F58_CCA4_CD9A_E0A3L, + /* 213 */ 0x562E_9BEA_DBCD_B11CL, 0x4C47_0A1D_7148_B3B6L, + /* 214 */ 0x44F2_1655_7CA4_8DB0L, 0x3D05_A1B1_276D_5C92L, + /* 215 */ 0x6E50_23BB_FAA0_E2B3L, 0x7B3C_35E8_3F15_60E9L, + /* 216 */ 0x5840_1C96_621A_4EF6L, 0x2F63_5E53_65AA_B3EDL, + /* 217 */ 0x4699_B078_4E7B_725EL, 0x591C_4B75_EAEE_F658L, + /* 218 */ 0x70F5_E726_E3F8_B6FDL, 0x74FA_1256_44B1_8A26L, + /* 219 */ 0x5A5E_5285_832D_5F31L, 0x43FB_41DE_9D5A_D4EBL, + /* 220 */ 0x484B_7537_9C24_4C27L, 0x4FFC_34B2_177B_DD89L, + /* 221 */ 0x73AB_EEBF_603A_1372L, 0x4CC6_BAB6_8BF9_6274L, + /* 222 */ 0x5C89_8BCC_4CFB_42C2L, 0x0A38_955E_D661_1B90L, + /* 223 */ 0x4A07_A309_D72F_689BL, 0x21C6_DDE5_784D_AFA7L, + /* 224 */ 0x7672_9E76_2518_A75EL, 0x693E_2FD5_8D49_190BL, + /* 225 */ 0x5EC2_185E_8413_B918L, 0x5431_BFDE_0AA0_E0D5L, + /* 226 */ 0x4BCE_79E5_3676_2DADL, 0x29C1_664B_3BB3_E711L, + /* 227 */ 0x794A_5CA1_F0BD_15E2L, 0x0F9B_D6DE_C5EC_A4E8L, + /* 228 */ 0x6108_4A1B_26FD_AB1BL, 0x2616_457F_04BD_50BAL, + /* 229 */ 0x4DA0_3B48_EBFE_227CL, 0x1E78_3798_D097_73C8L, + /* 230 */ 0x7C33_920E_4663_6A60L, 0x30C0_58F4_80F2_52D9L, + /* 231 */ 0x635C_74D8_384F_884DL, 0x0D66_AD90_6728_4247L, + /* 232 */ 0x4F7D_2A46_9372_D370L, 0x711E_F140_5286_9B6CL, + /* 233 */ 0x7F2E_AA0A_8584_8581L, 0x34FE_4ECD_50D7_5F14L, + /* 234 */ 0x65BE_EE6E_D136_D134L, 0x2A65_0BD7_73DF_7F43L, + /* 235 */ 0x5165_8B8B_DA92_40F6L, 0x551D_A312_C319_329CL, + /* 236 */ 0x411E_093C_AEDB_672BL, 0x5DB1_4F42_35AD_C217L, + /* 237 */ 0x6830_0EC7_7E2B_D845L, 0x7C4E_E536_BC49_368AL, + /* 238 */ 0x5359_A56C_64EF_E037L, 0x7D0B_EA92_303A_9208L, + /* 239 */ 0x42AE_1DF0_50BF_E693L, 0x173C_BBA8_2695_41A0L, + /* 240 */ 0x6AB0_2FE6_E799_70EBL, 0x3EC7_92A6_A422_029AL, + /* 241 */ 0x5559_BFEB_EC7A_C0BCL, 0x3239_421E_E9B4_CEE1L, + /* 242 */ 0x4447_CCBC_BD2F_0096L, 0x5B61_01B2_5490_A581L, + /* 243 */ 0x6D3F_ADFA_C84B_3424L, 0x2BCE_691D_541A_A268L, + /* 244 */ 0x5766_24C8_A03C_29B6L, 0x563E_BA7D_DCE2_1B87L, + /* 245 */ 0x45EB_50A0_8030_215EL, 0x7832_2ECB_171B_4939L, + /* 246 */ 0x6FDE_E767_3380_3564L, 0x59E9_E478_24F8_7527L, + /* 247 */ 0x597F_1F85_C2CC_F783L, 0x6187_E9F9_B72D_2A86L, + /* 248 */ 0x4798_E604_9BD7_2C69L, 0x346C_BB2E_2C24_2205L, + /* 249 */ 0x728E_3CD4_2C8B_7A42L, 0x20AD_F849_E039_D007L, + /* 250 */ 0x5BA4_FD76_8A09_2E9BL, 0x33BE_603B_19C7_D99FL, + /* 251 */ 0x4950_CAC5_3B3A_8BAFL, 0x42FE_B362_7B06_47B3L, + /* 252 */ 0x754E_113B_91F7_45E5L, 0x5197_856A_5E70_72B8L, + /* 253 */ 0x5DD8_0DC9_4192_9E51L, 0x27AC_6ABB_7EC0_5BC6L, + /* 254 */ 0x4B13_3E3A_9ADB_B1DAL, 0x52F0_5562_CBCD_1638L, + /* 255 */ 0x781E_C9F7_5E2C_4FC4L, 0x1E4D_556A_DFAE_89F3L, + /* 256 */ 0x6018_A192_B1BD_0C9CL, 0x7EA4_4455_7FBE_D4C3L, + /* 257 */ 0x4CE0_8142_27CA_707DL, 0x4BB6_9D11_32FF_109CL, + /* 258 */ 0x7B00_CED0_3FAA_4D95L, 0x5F8A_94E8_5198_1A93L, + /* 259 */ 0x6267_0BD9_CC88_3E11L, 0x32D5_43ED_0E13_4875L, + /* 260 */ 0x4EB8_D647_D6D3_64DAL, 0x5BDD_CFF0_D80F_6D2BL, + /* 261 */ 0x7DF4_8A0C_8AEB_D491L, 0x12FC_7FE7_C018_AEABL, + /* 262 */ 0x64C3_A1A3_A256_43A7L, 0x28C9_FFEC_99AD_5889L, + /* 263 */ 0x509C_814F_B511_CFB9L, 0x0707_FFF0_7AF1_13A1L, + /* 264 */ 0x407D_343F_C40E_3FC7L, 0x1F39_998D_2F27_42E7L, + /* 265 */ 0x672E_B9FF_A016_CC71L, 0x7EC2_8F48_4B72_04A4L, + /* 266 */ 0x528B_C7FF_B345_705BL, 0x189B_A5D3_6F8E_6A1DL, + /* 267 */ 0x4209_6CCC_8F6A_C048L, 0x7A16_1E42_BFA5_21B1L, + /* 268 */ 0x69A8_AE14_18AA_CD41L, 0x4356_96D1_32A1_CF81L, + /* 269 */ 0x5486_F1A9_AD55_7101L, 0x1C45_4574_2881_72CEL, + /* 270 */ 0x439F_27BA_F111_2734L, 0x169D_D129_BA01_28A5L, + /* 271 */ 0x6C31_D92B_1B4E_A520L, 0x242F_B50F_9001_DAA1L, + /* 272 */ 0x568E_4755_AF72_1DB3L, 0x368C_90D9_4001_7BB4L, + /* 273 */ 0x453E_9F77_BF8E_7E29L, 0x120A_0D7A_999A_C95DL, + /* 274 */ 0x6ECA_98BF_98E3_FD0EL, 0x5010_1590_F5C4_7561L, + /* 275 */ 0x58A2_13CC_7A4F_FDA5L, 0x2673_4473_F7D0_5DE8L, + /* 276 */ 0x46E8_0FD6_C83F_FE1DL, 0x6B8F_69F6_5FD9_E4B9L, + /* 277 */ 0x7173_4C8A_D9FF_FCFCL, 0x45B2_4323_CC8F_D45CL, + /* 278 */ 0x5AC2_A3A2_47FF_FD96L, 0x6AF5_0283_0A0C_A9E3L, + /* 279 */ 0x489B_B61B_6CCC_CADFL, 0x08C4_0202_6E70_87E9L, + /* 280 */ 0x742C_5692_47AE_1164L, 0x746C_D003_E3E7_3FDBL, + /* 281 */ 0x5CF0_4541_D2F1_A783L, 0x76BD_7336_4FEC_3315L, + /* 282 */ 0x4A59_D101_758E_1F9CL, 0x5EFD_F5C5_0CBC_F5ABL, + /* 283 */ 0x76F6_1B35_88E3_65C7L, 0x4B2F_EFA1_ADFB_22ABL, + /* 284 */ 0x5F2B_48F7_A0B5_EB06L, 0x08F3_261A_F195_B555L, + /* 285 */ 0x4C22_A0C6_1A2B_226BL, 0x20C2_84E2_5ADE_2AABL, + /* 286 */ 0x79D1_013C_F6AB_6A45L, 0x1AD0_D49D_5E30_4444L, + /* 287 */ 0x6174_00FD_9222_BB6AL, 0x48A7_107D_E4F3_69D0L, + /* 288 */ 0x4DF6_6731_41B5_62BBL, 0x53B8_D9FE_50C2_BB0DL, + /* 289 */ 0x7CBD_71E8_6922_3792L, 0x52C1_5CCA_1AD1_2B48L, + /* 290 */ 0x63CA_C186_BA81_C60EL, 0x7567_7D6E_7BDA_8906L, + /* 291 */ 0x4FD5_679E_FB9B_04D8L, 0x5DEC_6458_6315_3A6CL, + /* 292 */ 0x7FBB_D8FE_5F5E_6E27L, 0x497A_3A27_04EE_C3DFL, + }; + +} diff --git a/test/jdk/java/lang/String/concat/ImplicitStringConcatBoundaries.java b/test/jdk/java/lang/String/concat/ImplicitStringConcatBoundaries.java --- a/test/jdk/java/lang/String/concat/ImplicitStringConcatBoundaries.java +++ b/test/jdk/java/lang/String/concat/ImplicitStringConcatBoundaries.java @@ -169,8 +169,8 @@ test("foo-2147483648", "foo" + INT_MIN_1); test("foo-2147483648", "foo" + INT_MIN_2); - test("foo1.17549435E-38", "foo" + FLOAT_MIN_NORM_1); - test("foo1.17549435E-38", "foo" + FLOAT_MIN_NORM_2); + test("foo1.1754944E-38", "foo" + FLOAT_MIN_NORM_1); + test("foo1.1754944E-38", "foo" + FLOAT_MIN_NORM_2); test("foo-126.0", "foo" + FLOAT_MIN_EXP_1); test("foo-126.0", "foo" + FLOAT_MIN_EXP_2); test("foo1.4E-45", "foo" + FLOAT_MIN_1); diff --git a/test/jdk/jdk/internal/math/ToDecimal/DoubleToDecimalTest.java b/test/jdk/jdk/internal/math/ToDecimal/DoubleToDecimalTest.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/DoubleToDecimalTest.java @@ -0,0 +1,56 @@ +/* + * Copyright 2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +import jdk.internal.math.DoubleToDecimalChecker; +import jdk.test.lib.RandomFactory; + +/* + * @test + * @bug 8202555 + * @author Raffaello Giulietti + * @key randomness + * + * @modules java.base/jdk.internal.math + * @library /test/lib + * @library java.base + * @build jdk.test.lib.RandomFactory + * @build java.base/jdk.internal.math.* + * @run main DoubleToDecimalTest 1_000_000 + */ +public class DoubleToDecimalTest { + + private static final int RANDOM_COUNT = 100_000; + + public static void main(String[] args) { + int count = RANDOM_COUNT; + if (args.length == 0) { + DoubleToDecimalChecker.test(count, RandomFactory.getRandom()); + return; + } + try { + count = Integer.parseInt(args[0].replace("_", "")); + } catch (NumberFormatException ignored) { + } + DoubleToDecimalChecker.test(count, RandomFactory.getRandom()); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/FloatToDecimalTest.java b/test/jdk/jdk/internal/math/ToDecimal/FloatToDecimalTest.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/FloatToDecimalTest.java @@ -0,0 +1,63 @@ +/* + * Copyright 2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +import jdk.internal.math.FloatToDecimalChecker; +import jdk.test.lib.RandomFactory; + +/* + * @test + * @author Raffaello Giulietti + * @key randomness + * + * @modules java.base/jdk.internal.math + * @library /test/lib + * @library java.base + * @build jdk.test.lib.RandomFactory + * @build java.base/jdk.internal.math.* + * @run main FloatToDecimalTest 1_000_000 + */ +public class FloatToDecimalTest { + + private static final int RANDOM_COUNT = 100_000; + + public static void main(String[] args) { + int count = RANDOM_COUNT; + if (args.length == 0) { + FloatToDecimalChecker.test(count, RandomFactory.getRandom()); + return; + } + if (args[0].equals("all")) { + FloatToDecimalChecker.testAll(); + return; + } + if (args[0].equals("positive")) { + FloatToDecimalChecker.testPositive(); + return; + } + try { + count = Integer.parseInt(args[0].replace("_", "")); + } catch (NumberFormatException ignored) { + } + FloatToDecimalChecker.test(count, RandomFactory.getRandom()); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/MathUtilsTest.java b/test/jdk/jdk/internal/math/ToDecimal/MathUtilsTest.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/MathUtilsTest.java @@ -0,0 +1,40 @@ +/* + * Copyright 2019 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +import jdk.internal.math.MathUtilsChecker; + +/* + * @test + * @author Raffaello Giulietti + * + * @modules java.base/jdk.internal.math + * @library java.base + * @build java.base/jdk.internal.math.* + * @run main MathUtilsTest + */ +public class MathUtilsTest { + + public static void main(String[] args) { + MathUtilsChecker.test(); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/BasicChecker.java b/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/BasicChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/BasicChecker.java @@ -0,0 +1,40 @@ +/* + * Copyright 2018-2020 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +class BasicChecker { + + static final boolean FAILURE_THROWS_EXCEPTION = true; + + static void assertTrue(boolean ok, String valueName) { + if (ok) { + return; + } + String msg = valueName + " is not correct"; + if (FAILURE_THROWS_EXCEPTION) { + throw new RuntimeException(msg); + } + System.err.println(msg); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/DoubleToDecimalChecker.java b/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/DoubleToDecimalChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/DoubleToDecimalChecker.java @@ -0,0 +1,419 @@ +/* + * Copyright 2018-2020 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +import java.math.BigDecimal; +import java.util.Random; + +import static java.lang.Double.*; +import static java.lang.Long.numberOfTrailingZeros; +import static java.lang.StrictMath.scalb; +import static jdk.internal.math.MathUtils.flog10pow2; + +public class DoubleToDecimalChecker extends ToDecimalChecker { + + private static final int P = + numberOfTrailingZeros(doubleToRawLongBits(3)) + 2; + private static final int W = (SIZE - 1) - (P - 1); + private static final int Q_MIN = (-1 << W - 1) - P + 3; + private static final int Q_MAX = (1 << W - 1) - P; + private static final long C_MIN = 1L << P - 1; + private static final long C_MAX = (1L << P) - 1; + + private static final int K_MIN = flog10pow2(Q_MIN); + private static final int K_MAX = flog10pow2(Q_MAX); + private static final int H = flog10pow2(P) + 2; + + private static final double MIN_VALUE = scalb(1.0, Q_MIN); + private static final double MIN_NORMAL = scalb((double) C_MIN, Q_MIN); + private static final double MAX_VALUE = scalb((double) C_MAX, Q_MAX); + + private static final int E_MIN = e(MIN_VALUE); + private static final int E_MAX = e(MAX_VALUE); + + private static final long C_TINY = cTiny(Q_MIN, K_MIN); + + private double v; + private final long originalBits; + + private DoubleToDecimalChecker(double v, String s) { + super(s); + this.v = v; + originalBits = doubleToRawLongBits(v); + } + + @Override + BigDecimal toBigDecimal() { + return new BigDecimal(v); + } + + @Override + boolean recovers(BigDecimal b) { + return b.doubleValue() == v; + } + + @Override + boolean recovers(String s) { + return parseDouble(s) == v; + } + + @Override + String hexBits() { + return String.format("0x%01X__%03X__%01X_%04X_%04X_%04X", + (int) (originalBits >>> 63) & 0x1, + (int) (originalBits >>> 52) & 0x7FF, + (int) (originalBits >>> 48) & 0xF, + (int) (originalBits >>> 32) & 0xFFFF, + (int) (originalBits >>> 16) & 0xFFFF, + (int) originalBits & 0xFFFF); + } + + @Override + int minExp() { + return E_MIN; + } + + @Override + int maxExp() { + return E_MAX; + } + + @Override + int maxLen10() { + return H; + } + + @Override + boolean isZero() { + return v == 0; + } + + @Override + boolean isInfinity() { + return v == POSITIVE_INFINITY; + } + + @Override + void negate() { + v = -v; + } + + @Override + boolean isNegative() { + return originalBits < 0; + } + + @Override + boolean isNaN() { + return Double.isNaN(v); + } + + private static void toDec(double v) { +// String s = Double.toString(v); + String s = DoubleToDecimal.toString(v); + new DoubleToDecimalChecker(v, s).assertTrue(); + } + + private static void testExtremeValues() { + toDec(NEGATIVE_INFINITY); + toDec(-MAX_VALUE); + toDec(-MIN_NORMAL); + toDec(-MIN_VALUE); + toDec(-0.0); + toDec(0.0); + toDec(MIN_VALUE); + toDec(MIN_NORMAL); + toDec(MAX_VALUE); + toDec(POSITIVE_INFINITY); + toDec(NaN); + + /* + Quiet NaNs have the most significant bit of the mantissa as 1, + while signaling NaNs have it as 0. + Exercise 4 combinations of quiet/signaling NaNs and + "positive/negative" NaNs + */ + toDec(longBitsToDouble(0x7FF8_0000_0000_0001L)); + toDec(longBitsToDouble(0x7FF0_0000_0000_0001L)); + toDec(longBitsToDouble(0xFFF8_0000_0000_0001L)); + toDec(longBitsToDouble(0xFFF0_0000_0000_0001L)); + + /* + All values treated specially by Schubfach + */ + for (int c = 1; c < C_TINY; ++c) { + toDec(c * MIN_VALUE); + } + } + + /* + A few "powers of 10" are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf10() { + for (int e = E_MIN; e <= E_MAX; ++e) { + toDec(parseDouble("1e" + e)); + } + } + + /* + Many powers of 2 are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf2() { + for (double v = MIN_VALUE; v <= MAX_VALUE; v *= 2) { + toDec(v); + } + } + + /* + There are tons of doubles that are rendered incorrectly by the JDK. + While the renderings correctly round back to the original value, + they are longer than needed or are not the closest decimal to the double. + Here are just a very few examples. + */ + private static final String[] Anomalies = { + // JDK renders these, and others, with 18 digits! + "2.82879384806159E17", "1.387364135037754E18", + "1.45800632428665E17", + + // JDK renders these longer than needed. + "1.6E-322", "6.3E-322", + "7.3879E20", "2.0E23", "7.0E22", "9.2E22", + "9.5E21", "3.1E22", "5.63E21", "8.41E21", + + // JDK does not render these, and many others, as the closest. + "9.9E-324", "9.9E-323", + "1.9400994884341945E25", "3.6131332396758635E25", + "2.5138990223946153E25", + }; + + private static void testSomeAnomalies() { + for (String dec : Anomalies) { + toDec(parseDouble(dec)); + } + } + + /* + Values are from + Paxson V, "A Program for Testing IEEE Decimal-Binary Conversion" + tables 3 and 4 + */ + private static final double[] PaxsonSignificands = { + 8_511_030_020_275_656L, + 5_201_988_407_066_741L, + 6_406_892_948_269_899L, + 8_431_154_198_732_492L, + 6_475_049_196_144_587L, + 8_274_307_542_972_842L, + 5_381_065_484_265_332L, + 6_761_728_585_499_734L, + 7_976_538_478_610_756L, + 5_982_403_858_958_067L, + 5_536_995_190_630_837L, + 7_225_450_889_282_194L, + 7_225_450_889_282_194L, + 8_703_372_741_147_379L, + 8_944_262_675_275_217L, + 7_459_803_696_087_692L, + 6_080_469_016_670_379L, + 8_385_515_147_034_757L, + 7_514_216_811_389_786L, + 8_397_297_803_260_511L, + 6_733_459_239_310_543L, + 8_091_450_587_292_794L, + + 6_567_258_882_077_402L, + 6_712_731_423_444_934L, + 6_712_731_423_444_934L, + 5_298_405_411_573_037L, + 5_137_311_167_659_507L, + 6_722_280_709_661_868L, + 5_344_436_398_034_927L, + 8_369_123_604_277_281L, + 8_995_822_108_487_663L, + 8_942_832_835_564_782L, + 8_942_832_835_564_782L, + 8_942_832_835_564_782L, + 6_965_949_469_487_146L, + 6_965_949_469_487_146L, + 6_965_949_469_487_146L, + 7_487_252_720_986_826L, + 5_592_117_679_628_511L, + 8_887_055_249_355_788L, + 6_994_187_472_632_449L, + 8_797_576_579_012_143L, + 7_363_326_733_505_337L, + 8_549_497_411_294_502L, + }; + + private static final int[] PaxsonExponents = { + -342, + -824, + 237, + 72, + 99, + 726, + -456, + -57, + 376, + 377, + 93, + 710, + 709, + 117, + -1, + -707, + -381, + 721, + -828, + -345, + 202, + -473, + + 952, + 535, + 534, + -957, + -144, + 363, + -169, + -853, + -780, + -383, + -384, + -385, + -249, + -250, + -251, + 548, + 164, + 665, + 690, + 588, + 272, + -448, + }; + + private static void testPaxson() { + for (int i = 0; i < PaxsonSignificands.length; ++i) { + toDec(scalb(PaxsonSignificands[i], PaxsonExponents[i])); + } + } + + /* + Tests all integers of the form yx_xxx_000_000_000_000_000, y != 0. + These are all exact doubles. + */ + private static void testLongs() { + for (int i = 10_000; i < 100_000; ++i) { + toDec(i * 1e15); + } + } + + /* + Tests all integers up to 1_000_000. + These are all exact doubles and exercise a fast path. + */ + private static void testInts() { + for (int i = 0; i <= 1_000_000; ++i) { + toDec(i); + } + } + + /* + Random doubles over the whole range + */ + private static void testRandom(int randomCount, Random r) { + for (int i = 0; i < randomCount; ++i) { + toDec(longBitsToDouble(r.nextLong())); + } + } + + /* + Random doubles over the integer range [0, 2^52). + These are all exact doubles and exercise the fast path (except 0). + */ + private static void testRandomUnit(int randomCount, Random r) { + for (int i = 0; i < randomCount; ++i) { + toDec(r.nextLong() & (1L << P - 1)); + } + } + + /* + Random doubles over the range [0, 10^15) as "multiples" of 1e-3 + */ + private static void testRandomMilli(int randomCount, Random r) { + for (int i = 0; i < randomCount; ++i) { + toDec(r.nextLong() % 1_000_000_000_000_000_000L / 1e3); + } + } + + /* + Random doubles over the range [0, 10^15) as "multiples" of 1e-6 + */ + private static void testRandomMicro(int randomCount, Random r) { + for (int i = 0; i < randomCount; ++i) { + toDec((r.nextLong() & 0x7FFF_FFFF_FFFF_FFFFL) / 1e6); + } + } + + private static void testConstants() { + assertTrue(P == DoubleToDecimal.P, "P"); + assertTrue((long) (double) C_MIN == C_MIN, "C_MIN"); + assertTrue((long) (double) C_MAX == C_MAX, "C_MAX"); + assertTrue(MIN_VALUE == Double.MIN_VALUE, "MIN_VALUE"); + assertTrue(MIN_NORMAL == Double.MIN_NORMAL, "MIN_NORMAL"); + assertTrue(MAX_VALUE == Double.MAX_VALUE, "MAX_VALUE"); + + assertTrue(Q_MIN == DoubleToDecimal.Q_MIN, "Q_MIN"); + assertTrue(Q_MAX == DoubleToDecimal.Q_MAX, "Q_MAX"); + + assertTrue(K_MIN == DoubleToDecimal.K_MIN, "K_MIN"); + assertTrue(K_MAX == DoubleToDecimal.K_MAX, "K_MAX"); + assertTrue(H == DoubleToDecimal.H, "H"); + + assertTrue(E_MIN == DoubleToDecimal.E_MIN, "E_MIN"); + assertTrue(E_MAX == DoubleToDecimal.E_MAX, "E_MAX"); + assertTrue(C_TINY == DoubleToDecimal.C_TINY, "C_TINY"); + } + + public static void test(int randomCount, Random r) { + testConstants(); + testExtremeValues(); + testSomeAnomalies(); + testPowersOf2(); + testPowersOf10(); + testPaxson(); + testInts(); + testLongs(); + testRandom(randomCount, r); + testRandomUnit(randomCount, r); + testRandomMilli(randomCount, r); + testRandomMicro(randomCount, r); + } + + public static void main(String[] args) { + test(1_000_000, new Random()); + } +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/FloatToDecimalChecker.java b/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/FloatToDecimalChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/FloatToDecimalChecker.java @@ -0,0 +1,365 @@ +/* + * Copyright 2018-2020 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +import java.math.BigDecimal; +import java.util.Random; + +import static java.lang.Float.*; +import static java.lang.Integer.numberOfTrailingZeros; +import static java.lang.StrictMath.scalb; +import static jdk.internal.math.MathUtils.flog10pow2; + +public class FloatToDecimalChecker extends ToDecimalChecker { + + private static final int P = + numberOfTrailingZeros(floatToRawIntBits(3)) + 2; + private static final int W = (SIZE - 1) - (P - 1); + private static final int Q_MIN = (-1 << W - 1) - P + 3; + private static final int Q_MAX = (1 << W - 1) - P; + private static final int C_MIN = 1 << P - 1; + private static final int C_MAX = (1 << P) - 1; + + private static final int K_MIN = flog10pow2(Q_MIN); + private static final int K_MAX = flog10pow2(Q_MAX); + private static final int H = flog10pow2(P) + 2; + + private static final float MIN_VALUE = scalb(1.0f, Q_MIN); + private static final float MIN_NORMAL = scalb((float) C_MIN, Q_MIN); + private static final float MAX_VALUE = scalb((float) C_MAX, Q_MAX); + + private static final int E_MIN = e(MIN_VALUE); + private static final int E_MAX = e(MAX_VALUE); + + private static final long C_TINY = cTiny(Q_MIN, K_MIN); + + private float v; + private final int originalBits; + + private FloatToDecimalChecker(float v, String s) { + super(s); + this.v = v; + originalBits = floatToRawIntBits(v); + } + + @Override + BigDecimal toBigDecimal() { + return new BigDecimal(v); + } + + @Override + boolean recovers(BigDecimal b) { + return b.floatValue() == v; + } + + @Override + String hexBits() { + return String.format("0x%01X__%02X__%02X_%04X", + (originalBits >>> 31) & 0x1, + (originalBits >>> 23) & 0xFF, + (originalBits >>> 16) & 0x7F, + originalBits & 0xFFFF); + } + + @Override + boolean recovers(String s) { + return parseFloat(s) == v; + } + + @Override + int minExp() { + return E_MIN; + } + + @Override + int maxExp() { + return E_MAX; + } + + @Override + int maxLen10() { + return H; + } + + @Override + boolean isZero() { + return v == 0; + } + + @Override + boolean isInfinity() { + return v == POSITIVE_INFINITY; + } + + @Override + void negate() { + v = -v; + } + + @Override + boolean isNegative() { + return originalBits < 0; + } + + @Override + boolean isNaN() { + return Float.isNaN(v); + } + + private static void toDec(float v) { +// String s = Float.toString(v); + String s = FloatToDecimal.toString(v); + new FloatToDecimalChecker(v, s).assertTrue(); + } + + /* + MIN_NORMAL is incorrectly rendered by the JDK. + */ + private static void testExtremeValues() { + toDec(NEGATIVE_INFINITY); + toDec(-MAX_VALUE); + toDec(-MIN_NORMAL); + toDec(-MIN_VALUE); + toDec(-0.0f); + toDec(0.0f); + toDec(MIN_VALUE); + toDec(MIN_NORMAL); + toDec(MAX_VALUE); + toDec(POSITIVE_INFINITY); + toDec(NaN); + + /* + Quiet NaNs have the most significant bit of the mantissa as 1, + while signaling NaNs have it as 0. + Exercise 4 combinations of quiet/signaling NaNs and + "positive/negative" NaNs. + */ + toDec(intBitsToFloat(0x7FC0_0001)); + toDec(intBitsToFloat(0x7F80_0001)); + toDec(intBitsToFloat(0xFFC0_0001)); + toDec(intBitsToFloat(0xFF80_0001)); + + /* + All values treated specially by Schubfach + */ + for (int c = 1; c < C_TINY; ++c) { + toDec(c * MIN_VALUE); + } + } + + /* + Some "powers of 10" are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf10() { + for (int e = E_MIN; e <= E_MAX; ++e) { + toDec(parseFloat("1e" + e)); + } + } + + /* + Many powers of 2 are incorrectly rendered by the JDK. + The rendering is either too long or it is not the closest decimal. + */ + private static void testPowersOf2() { + for (float v = MIN_VALUE; v <= MAX_VALUE; v *= 2) { + toDec(v); + } + } + + /* + There are tons of doubles that are rendered incorrectly by the JDK. + While the renderings correctly round back to the original value, + they are longer than needed or are not the closest decimal to the double. + Here are just a very few examples. + */ + private static final String[] Anomalies = { + // JDK renders these longer than needed. + "1.1754944E-38", "2.2E-44", + "1.0E16", "2.0E16", "3.0E16", "5.0E16", "3.0E17", + "3.2E18", "3.7E18", "3.7E16", "3.72E17", + + // JDK does not render this as the closest. + "9.9E-44", + }; + + private static void testSomeAnomalies() { + for (String dec : Anomalies) { + toDec(parseFloat(dec)); + } + } + + /* + Values are from + Paxson V, "A Program for Testing IEEE Decimal-Binary Conversion" + tables 16 and 17 + */ + private static final float[] PaxsonSignificands = { + 12_676_506, + 15_445_013, + 13_734_123, + 12_428_269, + 12_676_506, + 15_334_037, + 11_518_287, + 12_584_953, + 15_961_084, + 14_915_817, + 10_845_484, + 16_431_059, + + 16_093_626, + 9_983_778, + 12_745_034, + 12_706_553, + 11_005_028, + 15_059_547, + 16_015_691, + 8_667_859, + 14_855_922, + 14_855_922, + 10_144_164, + 13_248_074, + }; + + private static final int[] PaxsonExponents = { + -102, + -103, + 86, + -138, + -130, + -146, + -41, + -145, + -125, + -146, + -102, + -61, + + 69, + 25, + 104, + 72, + 45, + 71, + -99, + 56, + -82, + -83, + -110, + 95, + }; + + private static void testPaxson() { + for (int i = 0; i < PaxsonSignificands.length; ++i) { + toDec(scalb(PaxsonSignificands[i], PaxsonExponents[i])); + } + } + + /* + Tests all positive integers below 2^23. + These are all exact floats and exercise the fast path. + */ + private static void testInts() { + for (int i = 1; i < 1 << P - 1; ++i) { + toDec(i); + } + } + + /* + Random floats over the whole range. + */ + private static void testRandom(int randomCount, Random r) { + for (int i = 0; i < randomCount; ++i) { + toDec(intBitsToFloat(r.nextInt())); + } + } + + /* + All, really all, 2^32 possible floats. Takes between 90 and 120 minutes. + */ + public static void testAll() { + // Avoid wrapping around Integer.MAX_VALUE + int bits = Integer.MIN_VALUE; + for (; bits < Integer.MAX_VALUE; ++bits) { + toDec(intBitsToFloat(bits)); + } + toDec(intBitsToFloat(bits)); + } + + /* + All positive 2^31 floats. + */ + public static void testPositive() { + // Avoid wrapping around Integer.MAX_VALUE + int bits = 0; + for (; bits < Integer.MAX_VALUE; ++bits) { + toDec(intBitsToFloat(bits)); + } + toDec(intBitsToFloat(bits)); + } + + private static void testConstants() { + assertTrue(P == FloatToDecimal.P, "P"); + assertTrue((long) (float) C_MIN == C_MIN, "C_MIN"); + assertTrue((long) (float) C_MAX == C_MAX, "C_MAX"); + assertTrue(MIN_VALUE == Float.MIN_VALUE, "MIN_VALUE"); + assertTrue(MIN_NORMAL == Float.MIN_NORMAL, "MIN_NORMAL"); + assertTrue(MAX_VALUE == Float.MAX_VALUE, "MAX_VALUE"); + + assertTrue(Q_MIN == FloatToDecimal.Q_MIN, "Q_MIN"); + assertTrue(Q_MAX == FloatToDecimal.Q_MAX, "Q_MAX"); + + assertTrue(K_MIN == FloatToDecimal.K_MIN, "K_MIN"); + assertTrue(K_MAX == FloatToDecimal.K_MAX, "K_MAX"); + assertTrue(H == FloatToDecimal.H, "H"); + + assertTrue(E_MIN == FloatToDecimal.E_MIN, "E_MIN"); + assertTrue(E_MAX == FloatToDecimal.E_MAX, "E_MAX"); + assertTrue(C_TINY == FloatToDecimal.C_TINY, "C_TINY"); + } + + public static void test(int randomCount, Random r) { + testConstants(); + testExtremeValues(); + testSomeAnomalies(); + testPowersOf2(); + testPowersOf10(); + testPaxson(); + testInts(); + testRandom(randomCount, r); + } + + public static void main(String[] args) { + if (args.length > 0 && args[0].equals("all")) { + testAll(); + return; + } + if (args.length > 0 && args[0].equals("positive")) { + testPositive(); + return; + } + test(1_000_000, new Random()); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/MathUtilsChecker.java b/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/MathUtilsChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/MathUtilsChecker.java @@ -0,0 +1,471 @@ +/* + * Copyright 2018-2020 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +import java.math.BigInteger; + +import static java.lang.Double.*; +import static java.lang.Long.numberOfTrailingZeros; +import static java.lang.StrictMath.scalb; +import static java.math.BigInteger.*; +import static jdk.internal.math.MathUtils.*; + +public class MathUtilsChecker extends BasicChecker { + + private static final BigInteger THREE = valueOf(3); + + // binary constants + private static final int P = + numberOfTrailingZeros(doubleToRawLongBits(3)) + 2; + private static final int W = (SIZE - 1) - (P - 1); + private static final int Q_MIN = (-1 << W - 1) - P + 3; + private static final int Q_MAX = (1 << W - 1) - P; + private static final long C_MIN = 1L << P - 1; + private static final long C_MAX = (1L << P) - 1; + + // decimal constants + private static final int K_MIN = flog10pow2(Q_MIN); + private static final int K_MAX = flog10pow2(Q_MAX); + private static final int H = flog10pow2(P) + 2; + + /* + Let + 10^(-k) = beta 2^r + for the unique integer r and real beta meeting + 2^125 <= beta < 2^126 + Further, let g = g1 2^63 + g0. + Checks that: + 2^62 <= g1 < 2^63, + 0 <= g0 < 2^63, + g - 1 <= beta < g, (that is, g = floor(beta) + 1) + The last predicate, after multiplying by 2^r, is equivalent to + (g - 1) 2^r <= 10^(-k) < g 2^r + This is the predicate that will be checked in various forms. + */ + private static void testG(int k, long g1, long g0) { + // 2^62 <= g1 < 2^63, 0 <= g0 < 2^63 + assertTrue(g1 << 1 < 0 && g1 >= 0 && g0 >= 0, "g"); + + BigInteger g = valueOf(g1).shiftLeft(63).or(valueOf(g0)); + // double check that 2^125 <= g < 2^126 + assertTrue(g.signum() > 0 && g.bitLength() == 126, "g"); + + // see javadoc of MathUtils.g1(int) + int r = flog2pow10(-k) - 125; + + /* + The predicate + (g - 1) 2^r <= 10^(-k) < g 2^r + is equivalent to + g - 1 <= 10^(-k) 2^(-r) < g + When + k <= 0 & r < 0 + all numerical subexpressions are integer-valued. This is the same as + g - 1 = 10^(-k) 2^(-r) + */ + if (k <= 0 && r < 0) { + assertTrue( + g.subtract(ONE).compareTo(TEN.pow(-k).shiftLeft(-r)) == 0, + "g"); + return; + } + + /* + The predicate + (g - 1) 2^r <= 10^(-k) < g 2^r + is equivalent to + g 10^k - 10^k <= 2^(-r) < g 10^k + When + k > 0 & r < 0 + all numerical subexpressions are integer-valued. + */ + if (k > 0 && r < 0) { + BigInteger pow5 = TEN.pow(k); + BigInteger mhs = ONE.shiftLeft(-r); + BigInteger rhs = g.multiply(pow5); + assertTrue(rhs.subtract(pow5).compareTo(mhs) <= 0 + && mhs.compareTo(rhs) < 0, + "g"); + return; + } + + /* + Finally, when + k <= 0 & r >= 0 + the predicate + (g - 1) 2^r <= 10^(-k) < g 2^r + can be used straightforwardly as all numerical subexpressions are + already integer-valued. + */ + if (k <= 0) { + BigInteger mhs = TEN.pow(-k); + assertTrue(g.subtract(ONE).shiftLeft(r).compareTo(mhs) <= 0 && + mhs.compareTo(g.shiftLeft(r)) < 0, + "g"); + return; + } + + /* + For combinatorial reasons, the only remaining case is + k > 0 & r >= 0 + which, however, cannot arise. Indeed, the predicate + (g - 1) 2^r <= 10^(-k) < g 2^r + has a positive integer left-hand side and a middle side < 1, + which cannot hold. + */ + assertTrue(false, "g"); + } + + /* + Verifies the soundness of the values returned by g1() and g0(). + */ + private static void testG() { + for (int k = MathUtils.K_MIN; k <= MathUtils.K_MAX; ++k) { + testG(k, g1(k), g0(k)); + } + } + + /* + Let + k = floor(log10(3/4 2^e)) + The method verifies that + k = flog10threeQuartersPow2(e), Q_MIN <= e <= Q_MAX + This range covers all binary exponents of doubles and floats. + + The first equation above is equivalent to + 10^k <= 3 2^(e-2) < 10^(k+1) + Equality never holds. Henceforth, the predicate to check is + 10^k < 3 2^(e-2) < 10^(k+1) + This will be transformed in various ways for checking purposes. + + For integer n > 0, let further + b = len2(n) + denote its length in bits. This means exactly the same as + 2^(b-1) <= n < 2^b + */ + private static void testFlog10threeQuartersPow2() { + // First check the case e = 1 + assertTrue(flog10threeQuartersPow2(1) == 0, + "flog10threeQuartersPow2"); + + /* + Now check the range Q_MIN <= e <= 0. + By rewriting, the predicate to check is equivalent to + 3 10^(-k-1) < 2^(2-e) < 3 10^(-k) + As e <= 0, it follows that 2^(2-e) >= 4 and the right inequality + implies k < 0, so the powers of 10 are integers. + + The left inequality is equivalent to + len2(3 10^(-k-1)) <= 2 - e + and the right inequality to + 2 - e < len2(3 10^(-k)) + The original predicate is therefore equivalent to + len2(3 10^(-k-1)) <= 2 - e < len2(3 10^(-k)) + + Starting with e = 0 and decrementing until the lower bound, the code + keeps track of the two powers of 10 to avoid recomputing them. + This is easy because at each iteration k changes at most by 1. A simple + multiplication by 10 computes the next power of 10 when needed. + */ + int e = 0; + int k0 = flog10threeQuartersPow2(e); + assertTrue(k0 < 0, "flog10threeQuartersPow2"); + BigInteger l = THREE.multiply(TEN.pow(-k0 - 1)); + BigInteger u = l.multiply(TEN); + for (;;) { + assertTrue(l.bitLength() <= 2 - e & 2 - e < u.bitLength(), + "flog10threeQuartersPow2"); + --e; + if (e < Q_MIN) { + break; + } + int kp = flog10threeQuartersPow2(e); + assertTrue(kp <= k0, "flog10threeQuartersPow2"); + if (kp < k0) { + // k changes at most by 1 at each iteration, hence: + assertTrue(k0 - kp == 1, "flog10threeQuartersPow2"); + k0 = kp; + l = u; + u = u.multiply(TEN); + } + } + + /* + Finally, check the range 2 <= e <= Q_MAX. + In predicate + 10^k < 3 2^(e-2) < 10^(k+1) + the right inequality shows that k >= 0 as soon as e >= 2. + It is equivalent to + 10^k / 3 < 2^(e-2) < 10^(k+1) / 3 + Both the powers of 10 and the powers of 2 are integers. + The left inequality is therefore equivalent to + floor(10^k / 3) < 2^(e-2) + and thus to + len2(floor(10^k / 3)) <= e - 2 + while the right inequality is equivalent to + 2^(e-2) <= floor(10^(k+1) / 3) + and hence to + e - 2 < len2(floor(10^(k+1) / 3)) + These are summarized as + len2(floor(10^k / 3)) <= e - 2 < len2(floor(10^(k+1) / 3)) + */ + e = 2; + k0 = flog10threeQuartersPow2(e); + assertTrue(k0 >= 0, "flog10threeQuartersPow2"); + BigInteger l10 = TEN.pow(k0); + BigInteger u10 = l10.multiply(TEN); + l = l10.divide(THREE); + u = u10.divide(THREE); + for (;;) { + assertTrue(l.bitLength() <= e - 2 & e - 2 < u.bitLength(), + "flog10threeQuartersPow2"); + ++e; + if (e > Q_MAX) { + break; + } + int kp = flog10threeQuartersPow2(e); + assertTrue(kp >= k0, "flog10threeQuartersPow2"); + if (kp > k0) { + // k changes at most by 1 at each iteration, hence: + assertTrue(kp - k0 == 1, "flog10threeQuartersPow2"); + k0 = kp; + u10 = u10.multiply(TEN); + l = u; + u = u10.divide(THREE); + } + } + } + + /* + Let + k = floor(log10(2^e)) + The method verifies that + k = flog10pow2(e), Q_MIN <= e <= Q_MAX + This range covers all binary exponents of doubles and floats. + + The first equation above is equivalent to + 10^k <= 2^e < 10^(k+1) + Equality holds iff e = k = 0. + Henceforth, the predicates to check are equivalent to + k = 0, if e = 0 + 10^k < 2^e < 10^(k+1), otherwise + The latter will be transformed in various ways for checking purposes. + + For integer n > 0, let further + b = len2(n) + denote its length in bits. This means exactly the same as + 2^(b-1) <= n < 2^b + */ + private static void testFlog10pow2() { + // First check the case e = 0 + assertTrue(flog10pow2(0) == 0, "flog10pow2"); + + /* + Now check the range F * Q_MIN <= e < 0. + By inverting all quantities, the predicate to check is equivalent to + 10^(-k-1) < 2^(-e) < 10^(-k) + As e < 0, it follows that 2^(-e) >= 2 and the right inequality + implies k < 0. + The left inequality means exactly the same as + len2(10^(-k-1)) <= -e + Similarly, the right inequality is equivalent to + -e < len2(10^(-k)) + The original predicate is therefore equivalent to + len2(10^(-k-1)) <= -e < len2(10^(-k)) + The powers of 10 are integers because k < 0. + + Starting with e = -1 and decrementing towards the lower bound, the code + keeps track of the two powers of 10 so as to avoid recomputing them. + This is easy because at each iteration k changes at most by 1. A simple + multiplication by 10 computes the next power of 10 when needed. + */ + int e = -1; + int k = flog10pow2(e); + assertTrue(k < 0, "flog10pow2"); + BigInteger l = TEN.pow(-k - 1); + BigInteger u = l.multiply(TEN); + for (;;) { + assertTrue(l.bitLength() <= -e & -e < u.bitLength(), + "flog10pow2"); + --e; + if (e < Q_MIN) { + break; + } + int kp = flog10pow2(e); + assertTrue(kp <= k, "flog10pow2"); + if (kp < k) { + // k changes at most by 1 at each iteration, hence: + assertTrue(k - kp == 1, "flog10pow2"); + k = kp; + l = u; + u = u.multiply(TEN); + } + } + + /* + Finally, in a similar vein, check the range 0 <= e <= Q_MAX. + In predicate + 10^k < 2^e < 10^(k+1) + the right inequality shows that k >= 0. + The left inequality means the same as + len2(10^k) <= e + and the right inequality holds iff + e < len2(10^(k+1)) + The original predicate is thus equivalent to + len2(10^k) <= e < len2(10^(k+1)) + As k >= 0, the powers of 10 are integers. + */ + e = 1; + k = flog10pow2(e); + assertTrue(k >= 0, "flog10pow2"); + l = TEN.pow(k); + u = l.multiply(TEN); + for (;;) { + assertTrue(l.bitLength() <= e & e < u.bitLength(), + "flog10pow2"); + ++e; + if (e > Q_MAX) { + break; + } + int kp = flog10pow2(e); + assertTrue(kp >= k, "flog10pow2"); + if (kp > k) { + // k changes at most by 1 at each iteration, hence: + assertTrue(kp - k == 1, "flog10pow2"); + k = kp; + l = u; + u = u.multiply(TEN); + } + } + } + + /* + Let + k = floor(log2(10^e)) + The method verifies that + k = flog2pow10(e), -K_MAX <= e <= -K_MIN + This range covers all decimal exponents of doubles and floats. + + The first equation above is equivalent to + 2^k <= 10^e < 2^(k+1) + Equality holds iff e = 0, implying k = 0. + Henceforth, the equivalent predicates to check are + k = 0, if e = 0 + 2^k < 10^e < 2^(k+1), otherwise + The latter will be transformed in various ways for checking purposes. + + For integer n > 0, let further + b = len2(n) + denote its length in bits. This means exactly the same as + 2^(b-1) <= n < 2^b + */ + private static void testFlog2pow10() { + // First check the case e = 0 + assertTrue(flog2pow10(0) == 0, "flog2pow10"); + + /* + Now check the range K_MIN <= e < 0. + By inverting all quantities, the predicate to check is equivalent to + 2^(-k-1) < 10^(-e) < 2^(-k) + As e < 0, this leads to 10^(-e) >= 10 and the right inequality implies + k <= -4. + The above means the same as + len2(10^(-e)) = -k + The powers of 10 are integer values since e < 0. + */ + int e = -1; + int k0 = flog2pow10(e); + assertTrue(k0 <= -4, "flog2pow10"); + BigInteger l = TEN; + for (;;) { + assertTrue(l.bitLength() == -k0, "flog2pow10"); + --e; + if (e < -K_MAX) { + break; + } + k0 = flog2pow10(e); + l = l.multiply(TEN); + } + + /* + Finally check the range 0 < e <= K_MAX. + From the predicate + 2^k < 10^e < 2^(k+1) + as e > 0, it follows that 10^e >= 10 and the right inequality implies + k >= 3. + The above means the same as + len2(10^e) = k + 1 + The powers of 10 are all integer valued, as e > 0. + */ + e = 1; + k0 = flog2pow10(e); + assertTrue(k0 >= 3, "flog2pow10"); + l = TEN; + for (;;) { + assertTrue(l.bitLength() == k0 + 1, "flog2pow10"); + ++e; + if (e > -K_MIN) { + break; + } + k0 = flog2pow10(e); + l = l.multiply(TEN); + } + } + + private static void testBinaryConstants() { + assertTrue((long) (double) C_MIN == C_MIN, "C_MIN"); + assertTrue((long) (double) C_MAX == C_MAX, "C_MAX"); + assertTrue(scalb(1.0, Q_MIN) == MIN_VALUE, "MIN_VALUE"); + assertTrue(scalb((double) C_MIN, Q_MIN) == MIN_NORMAL, "MIN_NORMAL"); + assertTrue(scalb((double) C_MAX, Q_MAX) == MAX_VALUE, "MAX_VALUE"); + } + + private static void testDecimalConstants() { + assertTrue(K_MIN == MathUtils.K_MIN, "K_MIN"); + assertTrue(K_MAX == MathUtils.K_MAX, "K_MAX"); + assertTrue(H == MathUtils.H, "H"); + } + + private static void testPow10() { + int e = 0; + long pow = 1; + for (; e <= H; e += 1, pow *= 10) { + assertTrue(pow == pow10(e), "pow10"); + } + } + + public static void test() { + testBinaryConstants(); + testFlog10pow2(); + testFlog10threeQuartersPow2(); + testDecimalConstants(); + testFlog2pow10(); + testPow10(); + testG(); + } + + public static void main(String[] args) { + test(); + } + +} diff --git a/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/ToDecimalChecker.java b/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/ToDecimalChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/ToDecimalChecker.java @@ -0,0 +1,409 @@ +/* + * Copyright 2018-2020 Raffaello Giulietti + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +package jdk.internal.math; + +import java.io.IOException; +import java.io.StringReader; +import java.math.BigDecimal; +import java.math.BigInteger; + +import static java.math.BigInteger.*; + +/* +A checker for the Javadoc specification. +It just relies on straightforward use of (expensive) BigDecimal arithmetic, +not optimized at all. + */ +abstract class ToDecimalChecker extends BasicChecker { + + // The string to check + private final String s; + + // The decimal parsed from s is c 10^q + private long c; + private int q; + + // The number of digits parsed from s: 10^(len10-1) <= c < 10^len10 + private int len10; + + ToDecimalChecker(String s) { + this.s = s; + } + + /* + Returns e be such that 10^(e-1) <= v < 10^e. + */ + static int e(double v) { + // log10(v) + 1 is a first good approximation of e + int e = (int) Math.floor(Math.log10(v)) + 1; + + // Full precision search for e such that 10^(e-1) <= c 2^q < 10^e. + BigDecimal vp = new BigDecimal(v); + BigDecimal low = new BigDecimal(BigInteger.ONE, -(e - 1)); + while (low.compareTo(vp) > 0) { + e -= 1; + low = new BigDecimal(BigInteger.ONE, -(e - 1)); + } + BigDecimal high = new BigDecimal(BigInteger.ONE, -e); + while (vp.compareTo(high) >= 0) { + e += 1; + high = new BigDecimal(BigInteger.ONE, -e); + } + return e; + } + + static long cTiny(int qMin, int kMin) { + BigInteger[] qr = ONE.shiftLeft(-qMin) + .divideAndRemainder(TEN.pow(-(kMin + 1))); + BigInteger cTiny = qr[1].signum() > 0 ? qr[0].add(ONE) : qr[0]; + assertTrue(cTiny.bitLength() < Long.SIZE, "C_TINY"); + return cTiny.longValue(); + } + + void assertTrue() { + if (isOK()) { + return; + } + String msg = "toString applied to the bits " + + hexBits() + + " returns " + + "\"" + s + "\"" + + ", which is not correct according to the specification."; + if (FAILURE_THROWS_EXCEPTION) { + throw new RuntimeException(msg); + } + System.err.println(msg); + } + + /* + Returns whether s syntactically meets the expected output of + toString. It is restricted to finite positive outputs. + It is an unusually long method but rather straightforward, too. + Many conditionals could be merged, but KISS here. + */ + private boolean parse(String t) { + try { + // first determine interesting boundaries in the string + StringReader r = new StringReader(t); + int ch = r.read(); + + int i = 0; + while (ch == '0') { + ++i; + ch = r.read(); + } + // i is just after zeroes starting the integer + + int p = i; + while ('0' <= ch && ch <= '9') { + c = 10 * c + (ch - '0'); + if (c < 0) { + return false; + } + ++len10; + ++p; + ch = r.read(); + } + // p is just after digits ending the integer + + int fz = p; + if (ch == '.') { + ++fz; + ch = r.read(); + } + // fz is just after a decimal '.' + + int f = fz; + while (ch == '0') { + c = 10 * c + (ch - '0'); + if (c < 0) { + return false; + } + ++len10; + ++f; + ch = r.read(); + } + // f is just after zeroes starting the fraction + + if (c == 0) { + len10 = 0; + } + int x = f; + while ('0' <= ch && ch <= '9') { + c = 10 * c + (ch - '0'); + if (c < 0) { + return false; + } + ++len10; + ++x; + ch = r.read(); + } + // x is just after digits ending the fraction + + int g = x; + if (ch == 'E') { + ++g; + ch = r.read(); + } + // g is just after an exponent indicator 'E' + + int ez = g; + if (ch == '-') { + ++ez; + ch = r.read(); + } + // ez is just after a '-' sign in the exponent + + int e = ez; + while (ch == '0') { + ++e; + ch = r.read(); + } + // e is just after zeroes starting the exponent + + int z = e; + while ('0' <= ch && ch <= '9') { + q = 10 * q + (ch - '0'); + if (q < 0) { + return false; + } + ++z; + ch = r.read(); + } + // z is just after digits ending the exponent + + // No other char after the number + if (z != t.length()) { + return false; + } + + // The integer must be present + if (p == 0) { + return false; + } + + // The decimal '.' must be present + if (fz == p) { + return false; + } + + // The fraction must be present + if (x == fz) { + return false; + } + + // The fraction is not 0 or it consists of exactly one 0 + if (f == x && f - fz > 1) { + return false; + } + + // Plain notation, no exponent + if (x == z) { + // At most one 0 starting the integer + if (i > 1) { + return false; + } + + // If the integer is 0, at most 2 zeroes start the fraction + if (i == 1 && f - fz > 2) { + return false; + } + + // The integer cannot have more than 7 digits + if (p > 7) { + return false; + } + + q = fz - x; + + // OK for plain notation + return true; + } + + // Computerized scientific notation + + // The integer has exactly one nonzero digit + if (i != 0 || p != 1) { + return false; + } + + // + // There must be an exponent indicator + if (x == g) { + return false; + } + + // There must be an exponent + if (ez == z) { + return false; + } + + // The exponent must not start with zeroes + if (ez != e) { + return false; + } + + if (g != ez) { + q = -q; + } + + // The exponent must not lie in [-3, 7) + if (-3 <= q && q < 7) { + return false; + } + + q += fz - x; + + // OK for computerized scientific notation + return true; + } catch (IOException ex) { + // An IOException on a StringReader??? Please... + return false; + } + } + + private boolean isOK() { + if (isNaN()) { + return s.equals("NaN"); + } + String t = s; + if (isNegative()) { + if (s.isEmpty() || s.charAt(0) != '-') { + return false; + } + negate(); + t = s.substring(1); + } + if (isInfinity()) { + return t.equals("Infinity"); + } + if (isZero()) { + return t.equals("0.0"); + } + if (!parse(t)) { + return false; + } + if (len10 < 2) { + c *= 10; + q -= 1; + len10 += 1; + } + if (2 > len10 || len10 > maxLen10()) { + return false; + } + + // The exponent is bounded + if (minExp() > q + len10 || q + len10 > maxExp()) { + return false; + } + + // s must recover v + try { + if (!recovers(t)) { + return false; + } + } catch (NumberFormatException e) { + return false; + } + + // Get rid of trailing zeroes, still ensuring at least 2 digits + while (len10 > 2 && c % 10 == 0) { + c /= 10; + q += 1; + len10 -= 1; + } + + if (len10 > 2) { + // Try with a shorter number less than v... + if (recovers(BigDecimal.valueOf(c / 10, -q - 1))) { + return false; + } + + // ... and with a shorter number greater than v + if (recovers(BigDecimal.valueOf(c / 10 + 1, -q - 1))) { + return false; + } + } + + // Try with the decimal predecessor... + BigDecimal dp = c == 10 ? + BigDecimal.valueOf(99, -q + 1) : + BigDecimal.valueOf(c - 1, -q); + if (recovers(dp)) { + BigDecimal bv = toBigDecimal(); + BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q)); + if (deltav.signum() >= 0) { + return true; + } + BigDecimal delta = dp.subtract(bv); + if (delta.signum() >= 0) { + return false; + } + int cmp = deltav.compareTo(delta); + return cmp > 0 || cmp == 0 && (c & 0x1) == 0; + } + + // ... and with the decimal successor + BigDecimal ds = BigDecimal.valueOf(c + 1, -q); + if (recovers(ds)) { + BigDecimal bv = toBigDecimal(); + BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q)); + if (deltav.signum() <= 0) { + return true; + } + BigDecimal delta = ds.subtract(bv); + if (delta.signum() <= 0) { + return false; + } + int cmp = deltav.compareTo(delta); + return cmp < 0 || cmp == 0 && (c & 0x1) == 0; + } + + return true; + } + + abstract BigDecimal toBigDecimal(); + + abstract boolean recovers(BigDecimal b); + + abstract boolean recovers(String s); + + abstract String hexBits(); + + abstract int minExp(); + + abstract int maxExp(); + + abstract int maxLen10(); + + abstract boolean isZero(); + + abstract boolean isInfinity(); + + abstract void negate(); + + abstract boolean isNegative(); + + abstract boolean isNaN(); + +} -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-4511638.patch Type: text/x-patch Size: 178278 bytes Desc: not available URL: From mik3hall at gmail.com Tue Mar 17 20:04:36 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 17 Mar 2020 15:04:36 -0500 Subject: jpackage and alternate JRE's - OS X In-Reply-To: References: Message-ID: > > > codesign -dv outFastR/FastRGraalHP.app > Executable=/Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHP.app/Contents/MacOS/FastRGraalHP > Identifier=jpackageapplauncher > ? > > It does appear that jpackage is doing some default code signing. > Running verbose I see no indication, other than maybe the above, that jpackage is in fact code signing. If this is something Apple is doing and GraalVM is doing something to violate it then it is definitely not something jpackage can probably do anything about. From andy.herrick at oracle.com Tue Mar 17 20:28:14 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 17 Mar 2020 16:28:14 -0400 Subject: jpackage and alternate JRE's - OS X In-Reply-To: References: Message-ID: <5776b492-c4bf-ea27-5234-7de3b759a4ae@oracle.com> yes jpackage itself will not do any signing unless you use the various signing option(s). But the executables in the jdk itself are signed, including those packaged as a resource like jpackageapplauncher itself. The app executable itself, in your case FastRGraalHP.app/Contents/MacOS/FastRGraalHP, is a copy of jpackageapplauncher /Andy On 3/17/2020 4:04 PM, Michael Hall wrote: > >> >> codesign -dv outFastR/FastRGraalHP.app >> Executable=/Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHP.app/Contents/MacOS/FastRGraalHP >> Identifier=jpackageapplauncher >> ? >> >> It does appear that jpackage is doing some default code signing. >> > Running verbose I see no indication, other than maybe the above, that jpackage is in fact code signing. If this is something Apple is doing and GraalVM is doing something to violate it then it is definitely not something jpackage can probably do anything about. > From mik3hall at gmail.com Tue Mar 17 20:32:08 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 17 Mar 2020 15:32:08 -0500 Subject: jpackage and alternate JRE's - OS X In-Reply-To: <5776b492-c4bf-ea27-5234-7de3b759a4ae@oracle.com> References: <5776b492-c4bf-ea27-5234-7de3b759a4ae@oracle.com> Message-ID: > On Mar 17, 2020, at 3:28 PM, Andy Herrick wrote: > > yes jpackage itself will not do any signing unless you use the various signing option(s). > > But the executables in the jdk itself are signed, including those packaged as a resource like jpackageapplauncher itself. > > The app executable itself, in your case FastRGraalHP.app/Contents/MacOS/FastRGraalHP, is a copy of jpackageapplauncher > > /Andy > > On 3/17/2020 4:04 PM, Michael Hall wrote: >> >>> >>> codesign -dv outFastR/FastRGraalHP.app >>> Executable=/Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHP.app/Contents/MacOS/FastRGraalHP >>> Identifier=jpackageapplauncher >>> ? >>> >>> It does appear that jpackage is doing some default code signing. >>> >> Running verbose I see no indication, other than maybe the above, that jpackage is in fact code signing. If this is something Apple is doing and GraalVM is doing something to violate it then it is definitely not something jpackage can probably do anything about. >> OK thanks. Graal seems to do some access control requiring Context context = Context.newBuilder().allowNativeAccess(true).build(); Or allowAllAccess() Must be some issue of theirs or something I just haven?t figured out being new to it. From mandy.chung at oracle.com Tue Mar 17 20:53:54 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 17 Mar 2020 13:53:54 -0700 Subject: CSR review for 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <88406fa9-e363-d514-35c8-3c1829b9f60c@oracle.com> References: <88406fa9-e363-d514-35c8-3c1829b9f60c@oracle.com> Message-ID: The javadoc and specdiff have been updated in place to reflect the recent discussion [1][2] to change the default of hidden classes that a hidden class may be unloaded even when the defining loader is reachable unless `ClassOption::STRONG` is specified such that the hidden class has the same strong relationship with its defining loader as the normal class has with its own defining loader. javadoc/specdiff: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ JVMS 5.4.4 change: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf Thanks Mandy [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006889.html [2] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006911.html On 3/9/20 2:00 PM, Mandy Chung wrote: > Please review the CSR proposed for JEP 371 Hidden Classes [1]. > > CSR: > ? https://bugs.openjdk.java.net/browse/JDK-8238359 > > javadoc/specdiff: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > > A brief summary of the changes: > > 1. A new Lookup::defineHiddenClass method is the API to create a > hidden class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and WEAK > option that > ?? can be specified when creating a hidden class. > 3. A new Class::isHiddenClass method tests if a class is a hidden class. > 4. Field::setXXX method will throw IAE on a final field of a hidden class > ?? regardless of the value of the accessible flag. > 5. Class::getNestMembers is updated not to throw any exception when it > fails > ?? to validate the nest membership.? Instead this method will return all > ?? members that are listed in `NestMembers` attribute if present and > ?? determined to have the same nest host as this class. > > We uncovered a bug in Lookup::defineClass spec throws LinkageError and > intends > to have the newly created class linked.? However, the implementation > in 14 > does not link the class.? A separate CSR proposes to update the > implementation > to match the spec - please also review: > ?? https://bugs.openjdk.java.net/browse/JDK-8240338 > > This is tracked as a separate JBS issue JDK-8238195 that is fixed in > this patch. > > The code review will be posted separately. > > Thanks > Mandy > [1] https://openjdk.java.net/jeps/371 > [2] JDK-8230502 Add support in JVM TI and JDI for hidden classes > [3] JDK-8219607 Add support in Graal and AOT for hidden and weak class > [4] > https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006872.html > From naoto.sato at oracle.com Tue Mar 17 20:58:25 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 17 Mar 2020 13:58:25 -0700 Subject: [15] RFR: 8241082: Upgrade IANA Language Subtag Registry data to 03-16-2020 version Message-ID: <5b989bf7-ad55-cae0-db89-7670430c933e@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8241082 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8241082/webrev.00/ It is simply updating the data file. Since there is no change in equivalency of language tags, no code change and test change was needed except for the data release date. Instead, I modified the equiv-map source code generator to explicitly specify the initial capacity for hash maps. Naoto From brian.burkhalter at oracle.com Tue Mar 17 21:13:04 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Mar 2020 14:13:04 -0700 Subject: RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results In-Reply-To: <337af475-162d-c942-a6d5-2957c1fb69f2@gmail.com> References: <337af475-162d-c942-a6d5-2957c1fb69f2@gmail.com> Message-ID: <70473E99-A7ED-473F-8413-24189411AD2E@oracle.com> Hi Raffaello, > On Mar 17, 2020, at 12:38 PM, Raffaello Giulietti wrote: > > there's a new version of the documentation [1] for the attached patch to solve the long standing issues described in [2]. The CSR referred to in the subject is in [3]. > > Besides many improvements in the proofs, a couple of simplifications and a better overall organization (this is my hope), I could find an ideal treatment of a special case that in the previous inception had a ugly, yet pragmatic solution in form of rather ad-hoc switch constructs. The new approach is mathematically clean and makes the code some lines shorter. Thanks for cleaning up the background paper. I?ll plan to review initially at least the through the part I read before. > The new code reflects this improvement and also adds a couple of additional tests. > > Passes tier1 tests. A tier 1-3 test run is in progress. > @BrianBurkalter > Brian, can you please upload the patch to webrev? As usual, there's an email attachemnt for your benefit. Thanks. Le voila: http://cr.openjdk.java.net/~bpb/4511638/webrev.04/ Best regards, Brian From brian.burkhalter at oracle.com Tue Mar 17 21:14:44 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Mar 2020 14:14:44 -0700 Subject: RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results In-Reply-To: <70473E99-A7ED-473F-8413-24189411AD2E@oracle.com> References: <337af475-162d-c942-a6d5-2957c1fb69f2@gmail.com> <70473E99-A7ED-473F-8413-24189411AD2E@oracle.com> Message-ID: <1A343EE2-9081-4E6F-AE6A-B2C736B2020F@oracle.com> Raffaello, Is there any change which would necessitate updating the CSR? Thanks, Brian > On Mar 17, 2020, at 2:13 PM, Brian Burkhalter wrote: > >> there's a new version of the documentation [1] for the attached patch to solve the long standing issues described in [2]. The CSR referred to in the subject is in [3]. From huizhe.wang at oracle.com Tue Mar 17 21:49:11 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 17 Mar 2020 14:49:11 -0700 Subject: [15] RFR: 8241082: Upgrade IANA Language Subtag Registry data to 03-16-2020 version In-Reply-To: <5b989bf7-ad55-cae0-db89-7670430c933e@oracle.com> References: <5b989bf7-ad55-cae0-db89-7670430c933e@oracle.com> Message-ID: <0ca5488c-ab36-f061-d5e2-b686a852ae96@oracle.com> Hi Naoto, Looks good to me. -Joe On 3/17/20 1:58 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8241082 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8241082/webrev.00/ > > It is simply updating the data file. Since there is no change in > equivalency of language tags, no code change and test change was > needed except for the data release date. Instead, I modified the > equiv-map source code generator to explicitly specify the initial > capacity for hash maps. > > Naoto From raffaello.giulietti at gmail.com Tue Mar 17 22:05:08 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 17 Mar 2020 23:05:08 +0100 Subject: RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results In-Reply-To: <1A343EE2-9081-4E6F-AE6A-B2C736B2020F@oracle.com> References: <337af475-162d-c942-a6d5-2957c1fb69f2@gmail.com> <70473E99-A7ED-473F-8413-24189411AD2E@oracle.com> <1A343EE2-9081-4E6F-AE6A-B2C736B2020F@oracle.com> Message-ID: <040969a2-2adb-e8c7-2c44-217e064153c1@gmail.com> No, the javadoc is identical, so there's no need to update the CSR. R On 2020-03-17 22:14, Brian Burkhalter wrote: > Raffaello, > > Is there any change which would necessitate updating the CSR? > > Thanks, > > Brian > >> On Mar 17, 2020, at 2:13 PM, Brian Burkhalter >> > wrote: >> >>> there's a new version of the documentation [1] for the attached >>> patch to solve the long standing issues described in [2]. The CSR >>> referred to in the subject is in [3]. > From brian.burkhalter at oracle.com Tue Mar 17 22:05:54 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Mar 2020 15:05:54 -0700 Subject: RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results In-Reply-To: <040969a2-2adb-e8c7-2c44-217e064153c1@gmail.com> References: <337af475-162d-c942-a6d5-2957c1fb69f2@gmail.com> <70473E99-A7ED-473F-8413-24189411AD2E@oracle.com> <1A343EE2-9081-4E6F-AE6A-B2C736B2020F@oracle.com> <040969a2-2adb-e8c7-2c44-217e064153c1@gmail.com> Message-ID: <40177255-6EDF-4F5D-9619-4C58A9C137E6@oracle.com> So much the better! > On Mar 17, 2020, at 3:05 PM, Raffaello Giulietti wrote: > No, the javadoc is identical, so there's no need to update the CSR. > > R > > On 2020-03-17 22:14, Brian Burkhalter wrote: >> Raffaello, >> >> Is there any change which would necessitate updating the CSR? From roger.riggs at oracle.com Tue Mar 17 22:07:45 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 17 Mar 2020 18:07:45 -0400 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: <80722047-3e15-3716-a015-4caf628027e5@oracle.com> References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> <80722047-3e15-3716-a015-4caf628027e5@oracle.com> Message-ID: Hi Magnus, Erik, Thanks for the pointers, I'm not familiar with those early build intricacies. Updated: ? http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-2/ More cleanup: - cleanup of ZipSource.gmk and autoconf/spec.gmk.in and Docs.gmk - The mystery of ActivationGroup_Stub is resolved.? The class needed to be in the spec/javadoc ?? but it also needed to be generated by RMIC, the version in src/java.rmi/share/doc ?? contained the javadoc comments.? I merged the javadoc into the generated stub .java class ?? and added it to the repo. - The NetBeans Jmx build script had targets to build the stubs, they have been removed. Thanks, Roger On 3/17/20 10:06 AM, Magnus Ihse Bursie wrote: > On 2020-03-17 14:17, Erik Joelsson wrote: >> Hello, >> >> That looks better, but there are still some more things to remove. >> This whole block: >> >> ################################################################################ >> >> # Targets for running rmic. >> $(eval $(call DeclareRecipesForPhase, RMIC, \ >> ??? TARGET_SUFFIX := rmic, \ >> ??? FILE_PREFIX := Rmic, \ >> ??? MAKE_SUBDIR := rmic, \ >> ??? CHECK_MODULES := $(ALL_MODULES))) >> >> ALL_TARGETS += $(RMIC_TARGETS) >> >> And all references to $(RMIC_TARGETS) and $(RMIC_MODULES). In most >> cases the whole lines (like the $(foreach) calls that iterate over >> them) can just be removed. > > This also means killing the entire "rmic" phase of the build. So > please also remove the rmic target from Main.gmk line 1015, and > ALL_TARGETs line 1133. And the reference to "rmic" from the phases in > the help in Global.gmk. > > In ZipSource.gmk, there's special handling to include rmic source > code, which is no longer needed. > > In Docs.gmk, you can remove $(SUPPORT_OUTPUTDIR)/rmic/* from > MODULES_SOURCE_PATH. > > (That actually made me notice another weird rmi thingy. How does these > new stubs relate to > src/java.rmi/share/doc/stub/java/rmi/activation/ActivationGroup_Stub.java? > That file has been present for a long time. It is included when > generating Javadoc, but not when compiling the class files for the JDK.) > > ?It is probably a good idea to make a case-insensitive search for > "rmic" in the make directory afterwards, to confirm that all remaining > cases of rmic should be there (i.e. it relates to compiling jdk.rmi, > not running rmic during the build.) > > And btw, I'm eternally grateful to you for removing this. :-) Now the > prospect of a fully warning-free build seems closer than ever! > > /Magnus > > > > > > >> >> /Erik >> >> On 2020-03-16 15:19, Roger Riggs wrote: >>> Hi Erik, >>> >>> Please review a new webrev that adds the change to remove the >>> interim build parts. >>> (Passes Tier 1-3 of CI testing) >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-1/ >>> >>> Thanks, Roger >>> >>> >>> On 3/16/20 12:22 PM, Erik Joelsson wrote: >>>> Hello Roger, >>>> >>>> There is more to be removed in the makefiles. >>>> >>>> This file should also be removed: >>>> >>>> make/CompileInterimRmic.gmk >>>> >>>> In make/Main.gmk, all the targets concerning rmic needs to be >>>> removed as well as any dependencies declared that involves them. >>>> Searching for "rmic" should find all relevant lines. >>>> >>>> /Erik >>>> >>>> On 2020-03-16 09:02, Roger Riggs wrote: >>>>> Please review adding pre-generated RMI stub classes to the jdk repo >>>>> and the removal of make files supporting the specific APIs. >>>>> >>>>> It removes a dependency on build time generation invoking RMIC. >>>>> RMIC was? deprecated in JDK 13 [1]. >>>>> >>>>> The source files have been edited to remove or suppress >>>>> compilation warnings. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ >>>>> >>>>> Issue: >>>>> ?https://bugs.openjdk.java.net/browse/JDK-8241073 >>>>> >>>>> >>>>> Thanks, Roger >>>>> >>>>> p.s. A future change will remove the interim build steps >>>>> >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8217412 >>> > From mandy.chung at oracle.com Tue Mar 17 23:09:36 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 17 Mar 2020 16:09:36 -0700 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> Message-ID: <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> Hi Alan, Thanks for the comment.? See my comments inlined below. Here is the updated webrev: ? http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.01 On 3/16/20 3:47 AM, Alan Bateman wrote: > The difference between the 2 constructors might not be obvious at the > use sites. I'm just wondering if would be better to use static factory > methods instead, e.g. the 2-arg constructor could be replaced with a > trusted(caller, searchLibPath) method that would make it a lot more > obvious in the places where that will eventually be used. > I have similar comment to myself and didn't come up good static factory method names.?? I give it a try again: what about newNativeLibraries and newNativeLibrariesWithNoAutoUnload? > A small inconsistency is that VM.isSystemDomainLoader is used in > constructor whereas the other checks for null and platform class > loader (plus app class loader). > Good catch.? Revised. > The Main test could use Path.of("classes"). In setup, dir could be a > Path and also Path p = Files.createDirectories(...) would allow the > Files.move to be a bit more readable. Adjusted. > I can't quite tell why the test is skipped with -Xcomp but maybe it's > just too slow and times out? > Removed. Cut-n-paste error from an existing test. > A small suggestion for NativeLibrariesTest is that > loadWithCustomLoader might be a better name to load p.Test with a > custom loader. Also noticed libnativeLibrariesTest.c has a 2017 date > on it. Fixed. thanks Mandy > > -Alan. From johan at kaving.se Mon Mar 16 21:48:55 2020 From: johan at kaving.se (Johan Kaving) Date: Mon, 16 Mar 2020 22:48:55 +0100 Subject: [PATCH]: jpackage fails to add DMG volume icon on macOS Message-ID: Hi, The jpackage tool on macOS supports adding a custom volume icon to DMGs that it produces, but this functionality is currently broken. ** Analysis ------------------ A custom volume icon added as "*-volume.icns" in the resource directory gets copied to the temporary DMG when building but is removed when the DMGsetup.scpt script is run. Specifically it is the line: update without registering applications at the end of the script that seems to remove it. It is unclear what this line is for. Many DMG creation scripts found by googling includes it, but not all. The same problem is reported here: https://github.com/andreyvit/create-dmg/issues/57 It was fixed in this commit: https://github.com/andreyvit/create-dmg/commit/bb4651bc1bc8c9e3571ca17fe43e51cf6979e0d2 and according to this comment the fix works for at least macOS 10.9-10.13: https://github.com/andreyvit/create-dmg/issues/57#issuecomment-425031425 I have verified the fix, and an alternative (see below), on macOS 10.15. A Google search for "update without registering applications" turns up the book "AppleScript: A Comprehensive Guide to Scripting and Automation on Mac OS X": https://books.google.se/books?id=t0snCgAAQBAJ&pg=PA33&lpg=PA33&dq=applescript+%22registering+applications%22&source=bl&ots=ffSt6a-J8E&sig=ACfU3U3jG6p0CSqAGr2nQ-TjAwF097Fw7g&hl=en&sa=X&ved=2ahUKEwiIgd_y5JboAhVP-yoKHegLBccQ6AEwAXoECAoQAQ#v=onepage&q=applescript%20%22registering%20applications%22&f=false The book uses the "update" command as an example of the AppleScript dictionary and includes this section: "The optional parameters are _necessity_, which is explained well, and _registering applications_, which I have no idea what it's good for or what it does. The dictionary author either got a bit lazy, or simply didn't know either." The description of the update command is: "Update the display of the specified object(s) to match their on-disk representation" Since the jpackage DMGsetup.scpt script closes the window just after using the update command there doesn't seem to be much point in updating the display of the window. ** Patches ------------------ I have tried two alternative ways to fix this problem and both are attached as patches to this email. Both of these fixes work, but I guess the first one is the simpler approach. - macos_dmg_volume_icon_fix_1.patch This patch simply removes the "update without registering applications" line from DMGsetup.scpt. - macos_dmg_volume_icon_fix_2.patch This patch changes the order of the code in MacDmgBundler.java so that the volume icon is added after running the DMGsetup.scpt script. This also fixes the problem. ** Unit test ------------------ - macos_dmg_volume_icon_test.patch I am attaching a jtreg unit test showing the problem as a separate patch. ** OCA ------------------ I have previously signed an OCA for the OpenJFX project, and if I understand the contribution document correctly that should be enough for OpenJDK as well. -- /Johan Kaving From brian.burkhalter at oracle.com Tue Mar 17 23:42:35 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Mar 2020 16:42:35 -0700 Subject: RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results In-Reply-To: <70473E99-A7ED-473F-8413-24189411AD2E@oracle.com> References: <337af475-162d-c942-a6d5-2957c1fb69f2@gmail.com> <70473E99-A7ED-473F-8413-24189411AD2E@oracle.com> Message-ID: > On Mar 17, 2020, at 2:13 PM, Brian Burkhalter wrote: > >> The new code reflects this improvement and also adds a couple of additional tests. >> >> Passes tier1 tests. > > A tier 1-3 test run is in progress. No failures related to this patch in the usual CI tiers 1-3 test run across the usual four platforms. Brian From roger.riggs at oracle.com Wed Mar 18 00:20:02 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 17 Mar 2020 20:20:02 -0400 Subject: RFR 8214245 : (regex) Case insensitive matching doesn't work correctly for some character classes In-Reply-To: References: <59ccaf4d-02e5-ed11-3800-f75412d16342@oracle.com> <2159961e-d4c8-3e88-be3f-f910d8429021@oracle.com> <08d46255-a535-bd10-556a-6b2954e5c574@oracle.com> Message-ID: <358775ae-3abb-584f-5dcb-305ab51deaa4@oracle.com> Hi Ivan, I see the CSR is approved. I'm fine with the change. Regards, Roger On 2/25/20 3:18 PM, Ivan Gerasimov wrote: > Thank you Roger for reviewing CSR and the release note! > > > On 2/11/20 12:49 PM, Roger Riggs wrote: >> Hi Ivan, >> >> Will this have enough of a compatibility concern to warrant a CSR? >> It will change the behavor of these cases. >> >> In the RegExTest, the failures should print which case is failing. >> (Line 4961, 4990). >> > I agree that many testcases in RegExTest could provide better > diagnostics in a case of a failure. > > I think, it maybe done as a separate cleanup. > > In the added testcase I made sure that both the input string and the > pattern are printed upon failure. > > With kind regards, > > Ivan > > >> Regards, Roger >> >> >> On 2/7/20 3:05 PM, Ivan Gerasimov wrote: >>> Gentle ping. >>> >>> I had to rebase the fix, as the code has diverged since the RFR was >>> sent out 10 months ago. >>> >>> Also, the test was slightly modified to cover more cases. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8214245 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8214245/01/webrev/ >>> >>> Thanks in advance to the volunteer to review the fix! >>> >>> With kind regards, >>> >>> Ivan >>> >>> On 4/21/19 7:50 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> It turns out, that the case-insensitive j.u.regex.Pattern still >>>> pays attention to the characters case when certain char classes are >>>> used. >>>> For example \p{IsLowerCase}, \p{IsUpperCase} and \p{IsTitleCase} >>>> continue to recognize only lower, upper and title case characters, >>>> even in case-insensitive context. >>>> >>>> For example, for POSIX char classes this behavior contradicts this >>>> paragraph: >>>> """ >>>> 9.2 Regular Expression General Requirements >>>> ... >>>> When a standard utility or function that uses regular expressions >>>> specifies that pattern matching shall be performed without regard >>>> to the case (uppercase or lowercase) of either data or patterns, >>>> then when each character in the string is matched against the >>>> pattern, not only the character, but also its case counterpart (if >>>> any), shall be matched. This definition of case-insensitive >>>> processing is intended to allow matching of multi-character >>>> collating elements as well as characters, as each character in the >>>> string is matched using both its cases. >>>> ... >>>> """ >>>> >>>> I also checked how Perl is dealing with in such situation, and yes, >>>> it ignores the case with various \p{} classes when they are used in >>>> case-insensitive context, so all these tests run fine: >>>> 'A' =~ /\p{Lower}/i or die; >>>> 'a' =~ /\p{Upper}/i or die; >>>> 'A' =~ /\p{gc=Lt}/i or die; # title case >>>> 'a' =~ /\p{IsTitlecase}/i or die; >>>> '?' =~ /\p{Lower}/i or die; # title-cased digraph >>>> '?' =~ /\p{Upper}/i or die; >>>> '?' =~ /\p{Lt}/i or die; >>>> >>>> For reference, here's a lengthy document, describing precise rules >>>> used by Perl to deal with \p{} char classes: >>>> https://perldoc.perl.org/perluniprops.html#Properties-accessible-through-%5cp%7b%7d-and-%5cP%7b%7d >>>> >>>> >>>> So, for any Lower, Upper or Title case chars in case-insensitive >>>> context Perl uses set of "Cased Letters", with is just a >>>> combination of these three categories (aka "LC" general category). >>>> >>>> Would you please help review the patch? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8214245 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8214245/00/webrev/ >>>> >> From brent.christian at oracle.com Wed Mar 18 00:52:08 2020 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 17 Mar 2020 17:52:08 -0700 Subject: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings In-Reply-To: References: <56F933F1-63E1-436A-9791-DA89085D0A2D@oracle.com> <032E77D2-A554-473E-AE07-DFB5E512F1B2@oracle.com> Message-ID: <593a23d0-2f3b-ea76-2ee0-082a89eb2c89@oracle.com> Adding -XX:+CompactStrings seems reasonable to me. (And I think it's a betters solution than, say, increasing -Xmx to allow running without compact strings.) -Brent On 3/17/20 10:46 AM, Brian Burkhalter wrote: > OK, I am fine with that. I?ll leave it open for the moment though in case anyone else has a comment. > > Brian > >> On Mar 17, 2020, at 10:39 AM, Andrew Leonard wrote: >> >> I see what you mean, but it's not really the point of the the BigInteger test, which is testing for an Arithmetic exception: >> The problem test is the one for 8021204 which constructs a String of "0"'s 2*31 long! which if you use 2bytes for each "0" is very likely to run out of memory! The problem is a "bug" in the testcase in that it doesn't quite ensure the environment is capable of running the test, by ensuring 1byte per char helps ensure that. Hotspot is that by default. I also suspect OOME is not certain either necessarily. >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> >> >> From: Brian Burkhalter >> To: Andrew Leonard >> Cc: Java Core Libs >> Date: 17/03/2020 15:48 >> Subject: [EXTERNAL] Re: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings >> >> >> >> To clarify, could the compact strings setting be detected and maybe add another @run tag and expect an OOME? Not sure this is critical. >> >> Brian >> >> On Mar 17, 2020, at 8:06 AM, Brian Burkhalter > wrote: >> >> You?re welcome. >> >> I see. Let?s leave this hang out a bit for further comment. Also, is a test possible, or a modification of an existing test? >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From mik3hall at gmail.com Wed Mar 18 03:45:44 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 17 Mar 2020 22:45:44 -0500 Subject: jpackage and alternate JRE's - OS X In-Reply-To: <5776b492-c4bf-ea27-5234-7de3b759a4ae@oracle.com> References: <5776b492-c4bf-ea27-5234-7de3b759a4ae@oracle.com> Message-ID: > On Mar 17, 2020, at 3:28 PM, Andy Herrick wrote: > > But the executables in the jdk itself are signed, including those packaged as a resource like jpackageapplauncher itself. Not that there isn?t good reason to do this but it appears to be the issue for GraalVM. I set up a shell script to launch the app and that works. I had to change it to all access. Context context = Context.newBuilder().allowAllAccess(true).build(); Or it had permission problems it looked like trying to read it?s etc/Renviron file. I guess I?ll try to figure out where to flag this as a possible upcoming concern on the GraalVM project if jpackage becomes the preferred way to prepare applications. Otherwise it seems like jpackage would work fine with their alternate jdk 11. From ivan.gerasimov at oracle.com Wed Mar 18 08:06:36 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 18 Mar 2020 01:06:36 -0700 Subject: RFR 8214245 : (regex) Case insensitive matching doesn't work correctly for some character classes In-Reply-To: <358775ae-3abb-584f-5dcb-305ab51deaa4@oracle.com> References: <59ccaf4d-02e5-ed11-3800-f75412d16342@oracle.com> <2159961e-d4c8-3e88-be3f-f910d8429021@oracle.com> <08d46255-a535-bd10-556a-6b2954e5c574@oracle.com> <358775ae-3abb-584f-5dcb-305ab51deaa4@oracle.com> Message-ID: Thank you Roger! Pushed. With kind regards, Ivan On 3/17/20 5:20 PM, Roger Riggs wrote: > Hi Ivan, > > I see the CSR is approved. > > I'm fine with the change. > > Regards, Roger > > > On 2/25/20 3:18 PM, Ivan Gerasimov wrote: >> Thank you Roger for reviewing CSR and the release note! >> >> >> On 2/11/20 12:49 PM, Roger Riggs wrote: >>> Hi Ivan, >>> >>> Will this have enough of a compatibility concern to warrant a CSR? >>> It will change the behavor of these cases. >>> >>> In the RegExTest, the failures should print which case is failing. >>> (Line 4961, 4990). >>> >> I agree that many testcases in RegExTest could provide better >> diagnostics in a case of a failure. >> >> I think, it maybe done as a separate cleanup. >> >> In the added testcase I made sure that both the input string and the >> pattern are printed upon failure. >> >> With kind regards, >> >> Ivan >> >> >>> Regards, Roger >>> >>> >>> On 2/7/20 3:05 PM, Ivan Gerasimov wrote: >>>> Gentle ping. >>>> >>>> I had to rebase the fix, as the code has diverged since the RFR was >>>> sent out 10 months ago. >>>> >>>> Also, the test was slightly modified to cover more cases. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8214245 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8214245/01/webrev/ >>>> >>>> Thanks in advance to the volunteer to review the fix! >>>> >>>> With kind regards, >>>> >>>> Ivan >>>> >>>> On 4/21/19 7:50 PM, Ivan Gerasimov wrote: >>>>> Hello! >>>>> >>>>> It turns out, that the case-insensitive j.u.regex.Pattern still >>>>> pays attention to the characters case when certain char classes >>>>> are used. >>>>> For example \p{IsLowerCase}, \p{IsUpperCase} and \p{IsTitleCase} >>>>> continue to recognize only lower, upper and title case characters, >>>>> even in case-insensitive context. >>>>> >>>>> For example, for POSIX char classes this behavior contradicts this >>>>> paragraph: >>>>> """ >>>>> 9.2 Regular Expression General Requirements >>>>> ... >>>>> When a standard utility or function that uses regular expressions >>>>> specifies that pattern matching shall be performed without regard >>>>> to the case (uppercase or lowercase) of either data or patterns, >>>>> then when each character in the string is matched against the >>>>> pattern, not only the character, but also its case counterpart (if >>>>> any), shall be matched. This definition of case-insensitive >>>>> processing is intended to allow matching of multi-character >>>>> collating elements as well as characters, as each character in the >>>>> string is matched using both its cases. >>>>> ... >>>>> """ >>>>> >>>>> I also checked how Perl is dealing with in such situation, and >>>>> yes, it ignores the case with various \p{} classes when they are >>>>> used in case-insensitive context, so all these tests run fine: >>>>> 'A' =~ /\p{Lower}/i or die; >>>>> 'a' =~ /\p{Upper}/i or die; >>>>> 'A' =~ /\p{gc=Lt}/i or die; # title case >>>>> 'a' =~ /\p{IsTitlecase}/i or die; >>>>> '?' =~ /\p{Lower}/i or die; # title-cased digraph >>>>> '?' =~ /\p{Upper}/i or die; >>>>> '?' =~ /\p{Lt}/i or die; >>>>> >>>>> For reference, here's a lengthy document, describing precise rules >>>>> used by Perl to deal with \p{} char classes: >>>>> https://perldoc.perl.org/perluniprops.html#Properties-accessible-through-%5cp%7b%7d-and-%5cP%7b%7d >>>>> >>>>> >>>>> So, for any Lower, Upper or Title case chars in case-insensitive >>>>> context Perl uses set of "Cased Letters", with is just a >>>>> combination of these three categories (aka "LC" general category). >>>>> >>>>> Would you please help review the patch? >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8214245 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8214245/00/webrev/ >>>>> >>> > -- With kind regards, Ivan Gerasimov From xu.y.yin at oracle.com Wed Mar 18 08:16:11 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Wed, 18 Mar 2020 16:16:11 +0800 Subject: [15] RFR: 8241130: com.sun.jndi.ldap.EventSupport.removeDeadNotifier: java.lang.NullPointerException Message-ID: Hello Please review following changes to fix corner issue in com.sun.jndi.ldap.EventSupport, thanks Bug: https://bugs.openjdk.java.net/browse/JDK-8241130 Webrev: http://cr.openjdk.java.net/~xyin/8241130/webrev.00/ This is a follow up item which related to 8202117. When testing the second revision fix for 8202117 (http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065270.html ), intermittent failure with java.lang.NullPointerException been observed(Thanks Daniel for additional testing), that exposed another issue in com.sun.jndi.ldap.EventSupport. ?com.sun.jndi.ldap.NamingEventNotifier" is a background thread which been created when addNamingListener with ldap context, per code logic, it will call EventSupport.removeDeadNotifier when encounter NamingException (maybe wrapped a SocketException) in some case, if user closed source ldap context first (EventSupport.cleanup been triggered), the call to EventSupport.removeDeadNotifier will throw NullPointerException since var ?notifiers? already been set to null in previous EventSupport.cleanup. Maybe in real world, it?s hard to get all criteria been satisfied to reproduce, but it?s still a potential multithreading issue and caught by test with repeat run. Combined this change and 8202117 second revision change, run test com/sun/jndi/ldap/RemoveNamingListenerTest.java on 4 platforms for total 2000 times, no failure been observed, also tier1, tier2, tier3 tests passed. Thanks, Chris From daniel.fuchs at oracle.com Wed Mar 18 10:03:47 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 18 Mar 2020 10:03:47 +0000 Subject: [15] RFR: 8202117: com/sun/jndi/ldap/RemoveNamingListenerTest.java fails intermittently: Connection reset In-Reply-To: References: <15783e53-6100-e257-b666-b53f91f8aaff@oracle.com> Message-ID: <0230e649-c5fd-ca18-11c2-dba7d17f5538@oracle.com> Hi Chris, Thanks for that! It looks good to me. best regards, -- daniel On 16/03/2020 07:26, Chris Yin wrote: > Thanks for reviewing, Daniel, Vyom. > > > Hi, Daniel > > I modified the test as you suggested to cover the potential issue with URIBuilder, many thanks. Updated webrev as below: > > http://cr.openjdk.java.net/~xyin/8202117/webrev.01/ > > Regards, > Chris From daniel.fuchs at oracle.com Wed Mar 18 11:24:19 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 18 Mar 2020 11:24:19 +0000 Subject: [15] RFR: 8241130: com.sun.jndi.ldap.EventSupport.removeDeadNotifier: java.lang.NullPointerException In-Reply-To: References: Message-ID: Hi Chris, Thanks for taking care of this followup fix. I see at least three other places where `notifiers` is accessed without a null check. It might be good to fix these three other places too just in case. (two addNamingListener methods and 1 removeNamingListener) All of them are already synchronized so a simple null check should be enough. Also you could had the @bug 8241130 to RemoveNamingListenerTest.java, since the test can be used to verify the fix (if run often enough). best regards, -- daniel On 18/03/2020 08:16, Chris Yin wrote: > Hello > > Please review following changes to fix corner issue > in?com.sun.jndi.ldap.EventSupport, thanks > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241130 > Webrev: http://cr.openjdk.java.net/~xyin/8241130/webrev.00/ > > > This is a follow up item which related to?8202117. When testing the > second revision fix > for?8202117?(http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065270.html), > intermittent failure with java.lang.NullPointerException been > observed(Thanks Daniel for additional testing), that exposed another > issue in com.sun.jndi.ldap.EventSupport. > > ?com.sun.jndi.ldap.NamingEventNotifier" is a background thread which > been created when addNamingListener with ldap context, per code logic, > it will call?EventSupport.removeDeadNotifier when encounter > NamingException (maybe wrapped a SocketException) in some case, if user > closed source ldap context first (EventSupport.cleanup been triggered), > the call to EventSupport.removeDeadNotifier will > throw?NullPointerException since var ?notifiers? already been set to > null in previous EventSupport.cleanup. Maybe in real world, it?s hard to > get all criteria been satisfied to reproduce, but it?s still a potential > multithreading issue and caught by test with repeat run. > > Combined this change and 8202117 second revision change, run test > com/sun/jndi/ldap/RemoveNamingListenerTest.java on 4 platforms for total > 2000 times, no failure been observed, also tier1, tier2, tier3 tests passed. > > Thanks, > Chris From erik.joelsson at oracle.com Wed Mar 18 12:47:32 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Mar 2020 05:47:32 -0700 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> <80722047-3e15-3716-a015-4caf628027e5@oracle.com> Message-ID: This looks good to me. Thanks for hanging in there! /Erik On 2020-03-17 15:07, Roger Riggs wrote: > Hi Magnus, Erik, > > Thanks for the pointers, I'm not familiar with those early build > intricacies. > > Updated: > > http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-2/ > > More cleanup: > > - cleanup of ZipSource.gmk and autoconf/spec.gmk.in and Docs.gmk > > - The mystery of ActivationGroup_Stub is resolved.? The class needed > to be in the spec/javadoc > ?? but it also needed to be generated by RMIC, the version in > src/java.rmi/share/doc > ?? contained the javadoc comments.? I merged the javadoc into the > generated stub .java class > ?? and added it to the repo. > > - The NetBeans Jmx build script had targets to build the stubs, they > have been removed. > > Thanks, Roger > > > On 3/17/20 10:06 AM, Magnus Ihse Bursie wrote: >> On 2020-03-17 14:17, Erik Joelsson wrote: >>> Hello, >>> >>> That looks better, but there are still some more things to remove. >>> This whole block: >>> >>> ################################################################################ >>> >>> # Targets for running rmic. >>> $(eval $(call DeclareRecipesForPhase, RMIC, \ >>> ??? TARGET_SUFFIX := rmic, \ >>> ??? FILE_PREFIX := Rmic, \ >>> ??? MAKE_SUBDIR := rmic, \ >>> ??? CHECK_MODULES := $(ALL_MODULES))) >>> >>> ALL_TARGETS += $(RMIC_TARGETS) >>> >>> And all references to $(RMIC_TARGETS) and $(RMIC_MODULES). In most >>> cases the whole lines (like the $(foreach) calls that iterate over >>> them) can just be removed. >> >> This also means killing the entire "rmic" phase of the build. So >> please also remove the rmic target from Main.gmk line 1015, and >> ALL_TARGETs line 1133. And the reference to "rmic" from the phases in >> the help in Global.gmk. >> >> In ZipSource.gmk, there's special handling to include rmic source >> code, which is no longer needed. >> >> In Docs.gmk, you can remove $(SUPPORT_OUTPUTDIR)/rmic/* from >> MODULES_SOURCE_PATH. >> >> (That actually made me notice another weird rmi thingy. How does >> these new stubs relate to >> src/java.rmi/share/doc/stub/java/rmi/activation/ActivationGroup_Stub.java? >> That file has been present for a long time. It is included when >> generating Javadoc, but not when compiling the class files for the JDK.) >> >> ?It is probably a good idea to make a case-insensitive search for >> "rmic" in the make directory afterwards, to confirm that all >> remaining cases of rmic should be there (i.e. it relates to compiling >> jdk.rmi, not running rmic during the build.) >> >> And btw, I'm eternally grateful to you for removing this. :-) Now the >> prospect of a fully warning-free build seems closer than ever! >> >> /Magnus >> >> >> >> >> >> >>> >>> /Erik >>> >>> On 2020-03-16 15:19, Roger Riggs wrote: >>>> Hi Erik, >>>> >>>> Please review a new webrev that adds the change to remove the >>>> interim build parts. >>>> (Passes Tier 1-3 of CI testing) >>>> >>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-1/ >>>> >>>> Thanks, Roger >>>> >>>> >>>> On 3/16/20 12:22 PM, Erik Joelsson wrote: >>>>> Hello Roger, >>>>> >>>>> There is more to be removed in the makefiles. >>>>> >>>>> This file should also be removed: >>>>> >>>>> make/CompileInterimRmic.gmk >>>>> >>>>> In make/Main.gmk, all the targets concerning rmic needs to be >>>>> removed as well as any dependencies declared that involves them. >>>>> Searching for "rmic" should find all relevant lines. >>>>> >>>>> /Erik >>>>> >>>>> On 2020-03-16 09:02, Roger Riggs wrote: >>>>>> Please review adding pre-generated RMI stub classes to the jdk repo >>>>>> and the removal of make files supporting the specific APIs. >>>>>> >>>>>> It removes a dependency on build time generation invoking RMIC. >>>>>> RMIC was? deprecated in JDK 13 [1]. >>>>>> >>>>>> The source files have been edited to remove or suppress >>>>>> compilation warnings. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ >>>>>> >>>>>> Issue: >>>>>> ?https://bugs.openjdk.java.net/browse/JDK-8241073 >>>>>> >>>>>> >>>>>> Thanks, Roger >>>>>> >>>>>> p.s. A future change will remove the interim build steps >>>>>> >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8217412 >>>> >> > From magnus.ihse.bursie at oracle.com Wed Mar 18 13:01:05 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 18 Mar 2020 14:01:05 +0100 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> <80722047-3e15-3716-a015-4caf628027e5@oracle.com> Message-ID: <113d3c07-9b88-3dbc-5a2c-54e1260e4319@oracle.com> On 2020-03-17 23:07, Roger Riggs wrote: > Hi Magnus, Erik, > > Thanks for the pointers, I'm not familiar with those early build > intricacies. > > Updated: > > http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-2/ Looking much better! Please remove the reference to "rmic" in Global.gmk as well. In Docs.gmk, the comment "# On top of the sources that was used to compile the JDK, we need some extra sources" is no longer relevant. Just remove it. In ZipSource.gmk, there crept in an extra space between the argument and the comma. Please remove it. In spec.gmk.in: - # Interim langtools and rmic modules and arguments + # Interim langtools and arguments Should be "Interim langtools modules and arguments" Apart from this, it looks good. You do not need to re-spin the webrev if you fix these minor nits. /Magnus > > More cleanup: > > - cleanup of ZipSource.gmk and autoconf/spec.gmk.in and Docs.gmk > > - The mystery of ActivationGroup_Stub is resolved.? The class needed > to be in the spec/javadoc > ?? but it also needed to be generated by RMIC, the version in > src/java.rmi/share/doc > ?? contained the javadoc comments.? I merged the javadoc into the > generated stub .java class > ?? and added it to the repo. > > - The NetBeans Jmx build script had targets to build the stubs, they > have been removed. > > Thanks, Roger > > > On 3/17/20 10:06 AM, Magnus Ihse Bursie wrote: >> On 2020-03-17 14:17, Erik Joelsson wrote: >>> Hello, >>> >>> That looks better, but there are still some more things to remove. >>> This whole block: >>> >>> ################################################################################ >>> >>> # Targets for running rmic. >>> $(eval $(call DeclareRecipesForPhase, RMIC, \ >>> ??? TARGET_SUFFIX := rmic, \ >>> ??? FILE_PREFIX := Rmic, \ >>> ??? MAKE_SUBDIR := rmic, \ >>> ??? CHECK_MODULES := $(ALL_MODULES))) >>> >>> ALL_TARGETS += $(RMIC_TARGETS) >>> >>> And all references to $(RMIC_TARGETS) and $(RMIC_MODULES). In most >>> cases the whole lines (like the $(foreach) calls that iterate over >>> them) can just be removed. >> >> This also means killing the entire "rmic" phase of the build. So >> please also remove the rmic target from Main.gmk line 1015, and >> ALL_TARGETs line 1133. And the reference to "rmic" from the phases in >> the help in Global.gmk. >> >> In ZipSource.gmk, there's special handling to include rmic source >> code, which is no longer needed. >> >> In Docs.gmk, you can remove $(SUPPORT_OUTPUTDIR)/rmic/* from >> MODULES_SOURCE_PATH. >> >> (That actually made me notice another weird rmi thingy. How does >> these new stubs relate to >> src/java.rmi/share/doc/stub/java/rmi/activation/ActivationGroup_Stub.java? >> That file has been present for a long time. It is included when >> generating Javadoc, but not when compiling the class files for the JDK.) >> >> ?It is probably a good idea to make a case-insensitive search for >> "rmic" in the make directory afterwards, to confirm that all >> remaining cases of rmic should be there (i.e. it relates to compiling >> jdk.rmi, not running rmic during the build.) >> >> And btw, I'm eternally grateful to you for removing this. :-) Now the >> prospect of a fully warning-free build seems closer than ever! >> >> /Magnus >> >> >> >> >> >> >>> >>> /Erik >>> >>> On 2020-03-16 15:19, Roger Riggs wrote: >>>> Hi Erik, >>>> >>>> Please review a new webrev that adds the change to remove the >>>> interim build parts. >>>> (Passes Tier 1-3 of CI testing) >>>> >>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-1/ >>>> >>>> Thanks, Roger >>>> >>>> >>>> On 3/16/20 12:22 PM, Erik Joelsson wrote: >>>>> Hello Roger, >>>>> >>>>> There is more to be removed in the makefiles. >>>>> >>>>> This file should also be removed: >>>>> >>>>> make/CompileInterimRmic.gmk >>>>> >>>>> In make/Main.gmk, all the targets concerning rmic needs to be >>>>> removed as well as any dependencies declared that involves them. >>>>> Searching for "rmic" should find all relevant lines. >>>>> >>>>> /Erik >>>>> >>>>> On 2020-03-16 09:02, Roger Riggs wrote: >>>>>> Please review adding pre-generated RMI stub classes to the jdk repo >>>>>> and the removal of make files supporting the specific APIs. >>>>>> >>>>>> It removes a dependency on build time generation invoking RMIC. >>>>>> RMIC was? deprecated in JDK 13 [1]. >>>>>> >>>>>> The source files have been edited to remove or suppress >>>>>> compilation warnings. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ >>>>>> >>>>>> Issue: >>>>>> ?https://bugs.openjdk.java.net/browse/JDK-8241073 >>>>>> >>>>>> >>>>>> Thanks, Roger >>>>>> >>>>>> p.s. A future change will remove the interim build steps >>>>>> >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8217412 >>>> >> > From jorn.vernee at oracle.com Wed Mar 18 14:08:35 2020 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Wed, 18 Mar 2020 15:08:35 +0100 Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable Message-ID: Hi, Can someone please sponsor this patch that makes Boolean, Character, Byte, and Short implement Constable? Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 Webrev: http://cr.openjdk.java.net/~jvernee/8241100/webrev.00/ Having the other box types implement Constable makes them easier to use with APIs that accept any Constable. Though I'm mostly interesting in boolean, for which I'm currently falling back to "true" & "false" strings, but the downside is that this also requires parsing the string again and having to deal with random other strings. This patch also adds the ConstantBootstraps::convert method that is used to facilitate the conversion from int to (short|char|byte). This currently takes a source type explicitly. In practice, it seems that Object can always be used as a source type for the same behavior, but explicitly specifying source and destination types seems more robust to me in case this behavior ever changes, or we want to expand on the supported kinds of conversion. (for instance it is currently not possible to convert from an int to a Long directly, or from Short to Integer, but maybe those cases could be supported in the future as well). Testing: tier1-3 & downstream testing for my particular use case Thanks, Jorn From roger.riggs at oracle.com Wed Mar 18 14:42:30 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 18 Mar 2020 10:42:30 -0400 Subject: [15] RFR: 8241082: Upgrade IANA Language Subtag Registry data to 03-16-2020 version In-Reply-To: <5b989bf7-ad55-cae0-db89-7670430c933e@oracle.com> References: <5b989bf7-ad55-cae0-db89-7670430c933e@oracle.com> Message-ID: Hi Naoto, EquivMapsGenerator.java: 242 It looks odd to put the warning about being an auto-generated file in the middle of the declarations. Perhaps add it to the headerText. The existing maps are not pre-sized, is it important to pre-size the new ones. There's no particular reason to pre-concatinate the new source lines.? Separate writes would be fine too. Roger On 3/17/20 4:58 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8241082 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8241082/webrev.00/ > > It is simply updating the data file. Since there is no change in > equivalency of language tags, no code change and test change was > needed except for the data release date. Instead, I modified the > equiv-map source code generator to explicitly specify the initial > capacity for hash maps. > > Naoto From Alan.Bateman at oracle.com Wed Mar 18 15:46:17 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Mar 2020 15:46:17 +0000 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> Message-ID: <401741d6-cb99-d170-9a1f-a8793a8b1dd8@oracle.com> On 13/03/2020 14:54, Denghui Dong wrote: > Good suggestion, moved. > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.03/ > This looks much better. What would you think about renaming the JFR event to "DirectBufferStatistics"? The concern I have with the proposed naming is that it will be really awkward to extend it to support mapped buffers. The implementation changes look okay, hopefully Erik will skim over them. One small suggestion for for ManagementFactoryHelper is that you can stream().collect(Collectors.toList()) to create the value for bufferPools. You could even change it to volatile so that getBufferMXBeans isn't a synchronized method. -Alan. From brian.goetz at oracle.com Wed Mar 18 15:54:25 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 18 Mar 2020 11:54:25 -0400 Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable In-Reply-To: References: Message-ID: Overall, the approach seems sound, and I like that you are introducing only one new bootstrap that is usable for a range of things. A few comments and questions. 1. Not sure the explicit source type carries its weight, but whether it does or not is probably informed by whatever we do for (3) below. 2. Naming: ?convert? seems kind of general; the name should suggest some sort of asType conversion. asType is pretty rich, and will get richer in the future, so aligning with that is probably a good move. 3. The spec on convert() needs to be fleshed out, as to exactly which set of conversions are supported. ?Exactly the same set as asType? is OK; ?similar to asType? is kind of vague. Similarly, the spec on parameters and exceptions could be fleshed out a bit too. I suspect you?ll want to iterate on (3) a few times before we have a spec that is solid enough that it says exactly what it does and doesn?t do. > On Mar 18, 2020, at 10:08 AM, Jorn Vernee wrote: > > Hi, > > Can someone please sponsor this patch that makes Boolean, Character, Byte, and Short implement Constable? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 > Webrev: http://cr.openjdk.java.net/~jvernee/8241100/webrev.00/ > > Having the other box types implement Constable makes them easier to use with APIs that accept any Constable. Though I'm mostly interesting in boolean, for which I'm currently falling back to "true" & "false" strings, but the downside is that this also requires parsing the string again and having to deal with random other strings. > > This patch also adds the ConstantBootstraps::convert method that is used to facilitate the conversion from int to (short|char|byte). This currently takes a source type explicitly. In practice, it seems that Object can always be used as a source type for the same behavior, but explicitly specifying source and destination types seems more robust to me in case this behavior ever changes, or we want to expand on the supported kinds of conversion. (for instance it is currently not possible to convert from an int to a Long directly, or from Short to Integer, but maybe those cases could be supported in the future as well). > > Testing: tier1-3 & downstream testing for my particular use case > > Thanks, > Jorn > From naoto.sato at oracle.com Wed Mar 18 15:57:10 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 18 Mar 2020 08:57:10 -0700 Subject: [15] RFR: 8241082: Upgrade IANA Language Subtag Registry data to 03-16-2020 version In-Reply-To: References: <5b989bf7-ad55-cae0-db89-7670430c933e@oracle.com> Message-ID: <92e789d0-9e2f-17f6-cf08-db499567c700@oracle.com> Hi Roger, thanks for the review. On 3/18/20 7:42 AM, Roger Riggs wrote: > Hi Naoto, > > EquivMapsGenerator.java: 242 > It looks odd to put the warning about being an auto-generated file in > the middle of the declarations. > Perhaps add it to the headerText. > > The existing maps are not pre-sized, is it important to pre-size the new > ones. > There's no particular reason to pre-concatinate the new source lines. > Separate writes would be fine too. Since we know the exact size of the map, specifying the size at the source creation time will save the map size increase (from the default 16) at runtime. I would not call it as "important", but it would not hurt. As to the warning message, yes it would be less odd if it were in the header text. Since I have already pushed the change, I'd like to correct it at the next opportunity. Would it be OK? Naoto > > Roger > > On 3/17/20 4:58 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8241082 >> >> The proposed changeset is located at: >> >> http://cr.openjdk.java.net/~naoto/8241082/webrev.00/ >> >> It is simply updating the data file. Since there is no change in >> equivalency of language tags, no code change and test change was >> needed except for the data release date. Instead, I modified the >> equiv-map source code generator to explicitly specify the initial >> capacity for hash maps. >> >> Naoto > From Alan.Bateman at oracle.com Wed Mar 18 15:59:49 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Mar 2020 15:59:49 +0000 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> Message-ID: <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> On 17/03/2020 23:09, Mandy Chung wrote: > > I have similar comment to myself and didn't come up good static > factory method names.?? I give it a try again: what about > newNativeLibraries and newNativeLibrariesWithNoAutoUnload? Would newTrustedNativeLibraries work? Everything else in the updated webrev looks good. -Alan From roger.riggs at oracle.com Wed Mar 18 16:23:18 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 18 Mar 2020 12:23:18 -0400 Subject: [15] RFR: 8241082: Upgrade IANA Language Subtag Registry data to 03-16-2020 version In-Reply-To: <92e789d0-9e2f-17f6-cf08-db499567c700@oracle.com> References: <5b989bf7-ad55-cae0-db89-7670430c933e@oracle.com> <92e789d0-9e2f-17f6-cf08-db499567c700@oracle.com> Message-ID: Hi Naoto, ok to correct some time later. The bug hasn't been updated, it still appears to be in progress. (They are working to fix hgupdater) I think waiting more than an hour for reviews is a good idea, 24hrs might be a minimum unless its urgent to fix a broken build. Regards, Roger On 3/18/20 11:57 AM, naoto.sato at oracle.com wrote: > Hi Roger, thanks for the review. > > On 3/18/20 7:42 AM, Roger Riggs wrote: >> Hi Naoto, >> >> EquivMapsGenerator.java: 242 >> It looks odd to put the warning about being an auto-generated file in >> the middle of the declarations. >> Perhaps add it to the headerText. >> >> The existing maps are not pre-sized, is it important to pre-size the >> new ones. >> There's no particular reason to pre-concatinate the new source lines. >> Separate writes would be fine too. > > Since we know the exact size of the map, specifying the size at the > source creation time will save the map size increase (from the default > 16) at runtime. I would not call it as "important", but it would not > hurt. > > As to the warning message, yes it would be less odd if it were in the > header text. Since I have already pushed the change, I'd like to > correct it at the next opportunity. Would it be OK? > > Naoto > >> >> Roger >> >> On 3/17/20 4:58 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8241082 >>> >>> The proposed changeset is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8241082/webrev.00/ >>> >>> It is simply updating the data file. Since there is no change in >>> equivalency of language tags, no code change and test change was >>> needed except for the data release date. Instead, I modified the >>> equiv-map source code generator to explicitly specify the initial >>> capacity for hash maps. >>> >>> Naoto >> From mandy.chung at oracle.com Wed Mar 18 16:32:43 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Mar 2020 09:32:43 -0700 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> Message-ID: <11be7843-a805-5bdd-25ea-8dc30445eb7c@oracle.com> On 3/18/20 8:59 AM, Alan Bateman wrote: > On 17/03/2020 23:09, Mandy Chung wrote: >> >> I have similar comment to myself and didn't come up good static >> factory method names.?? I give it a try again: what about >> newNativeLibraries and newNativeLibrariesWithNoAutoUnload? > Would newTrustedNativeLibraries work? Everything else in the updated > webrev looks good. "no auto unload" is also important.? what about "newTrustedNativeLibrariesNoAutoUnload" a bit long? Mandy From maurizio.cimadamore at oracle.com Wed Mar 18 18:16:36 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 18 Mar 2020 18:16:36 +0000 (UTC) Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: <11be7843-a805-5bdd-25ea-8dc30445eb7c@oracle.com> References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> <11be7843-a805-5bdd-25ea-8dc30445eb7c@oracle.com> Message-ID: <5b72c1d8-25b8-70b7-cd90-0b02e7827052@oracle.com> So, maybe I'm saying something naive, but isn't the difference between the two mechanisms mostly there to distinguish between JNI libraries and non-JNI libraries? E.g. maybe we should add JNI somewhere in one of the factory (the one used by System.loadLibrary) and then document what are the differences between JNI and non-JNI libraries. We could even have different NativeLibrary impl for these two cases. Seems to me that JNI libs feature: * extra restrictions (cannot load same library in multiple loaders) * auto-unloading guarantees (classloader-driven) Or are there cases where you envision more mix and match? E.g. JNI libraries w/o auto-unloading? Maurizio On 18/03/2020 16:32, Mandy Chung wrote: > > > On 3/18/20 8:59 AM, Alan Bateman wrote: >> On 17/03/2020 23:09, Mandy Chung wrote: >>> >>> I have similar comment to myself and didn't come up good static >>> factory method names.?? I give it a try again: what about >>> newNativeLibraries and newNativeLibrariesWithNoAutoUnload? >> Would newTrustedNativeLibraries work? Everything else in the updated >> webrev looks good. > > "no auto unload" is also important.? what about > "newTrustedNativeLibrariesNoAutoUnload" a bit long? > > Mandy From mandy.chung at oracle.com Wed Mar 18 18:40:40 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Mar 2020 11:40:40 -0700 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: <5b72c1d8-25b8-70b7-cd90-0b02e7827052@oracle.com> References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> <11be7843-a805-5bdd-25ea-8dc30445eb7c@oracle.com> <5b72c1d8-25b8-70b7-cd90-0b02e7827052@oracle.com> Message-ID: On 3/18/20 11:16 AM, Maurizio Cimadamore wrote: > So, maybe I'm saying something naive, but isn't the difference between > the two mechanisms mostly there to distinguish between JNI libraries > and non-JNI libraries? > I think such distinction is kind of blurry at the moment.?? One thing for sure is that JNI native method binding won't happen with the native libraries loaded through this new mechanism. OTOH, should JNI_OnLoad and JNI_Unload be invoked if it is a non-JNI library?? The new mechanism still does.? I expect that this will be cleared up from panama specification. However, you raise a good point that this is not only about auto-unloading (which I got trapped as this patch is all about). No JNI native method binding is another significant part. > E.g. maybe we should add JNI somewhere in one of the factory (the one > used by System.loadLibrary) and then document what are the differences > between JNI and non-JNI libraries. We could even have different > NativeLibrary impl for these two cases. > > Seems to me that JNI libs feature: > > * extra restrictions (cannot load same library in multiple loaders) > * auto-unloading guarantees (classloader-driven) > JNI native method binding will lookup methods from these libraries. > Or are there cases where you envision more mix and match? E.g. JNI > libraries w/o auto-unloading? No as unloading is important for native library loaded by custom loaders. I can't really think of a good static factory method name. would newNonJavaNativeLIbraries be slightly clearer? Mandy > > Maurizio > > On 18/03/2020 16:32, Mandy Chung wrote: >> >> >> On 3/18/20 8:59 AM, Alan Bateman wrote: >>> On 17/03/2020 23:09, Mandy Chung wrote: >>>> >>>> I have similar comment to myself and didn't come up good static >>>> factory method names.?? I give it a try again: what about >>>> newNativeLibraries and newNativeLibrariesWithNoAutoUnload? >>> Would newTrustedNativeLibraries work? Everything else in the updated >>> webrev looks good. >> >> "no auto unload" is also important.? what about >> "newTrustedNativeLibrariesNoAutoUnload" a bit long? >> >> Mandy From maurizio.cimadamore at oracle.com Wed Mar 18 19:13:25 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 18 Mar 2020 19:13:25 +0000 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> <11be7843-a805-5bdd-25ea-8dc30445eb7c@oracle.com> <5b72c1d8-25b8-70b7-cd90-0b02e7827052@oracle.com> Message-ID: On 18/03/2020 18:40, Mandy Chung wrote: > > > On 3/18/20 11:16 AM, Maurizio Cimadamore wrote: >> So, maybe I'm saying something naive, but isn't the difference >> between the two mechanisms mostly there to distinguish between JNI >> libraries and non-JNI libraries? >> > > I think such distinction is kind of blurry at the moment.?? One thing > for sure is that JNI native method binding won't happen with the > native libraries loaded through this new mechanism. > > OTOH, should JNI_OnLoad and JNI_Unload be invoked if it is a non-JNI > library?? The new mechanism still does.? I expect that this will be > cleared up from panama specification. Should defo not happen in Panama-loaded libraries > > However, you raise a good point that this is not only about > auto-unloading (which I got trapped as this patch is all about).??? No > JNI native method binding is another significant part. Yes > >> E.g. maybe we should add JNI somewhere in one of the factory (the one >> used by System.loadLibrary) and then document what are the >> differences between JNI and non-JNI libraries. We could even have >> different NativeLibrary impl for these two cases. >> >> Seems to me that JNI libs feature: >> >> * extra restrictions (cannot load same library in multiple loaders) >> * auto-unloading guarantees (classloader-driven) >> > > JNI native method binding will lookup methods from these libraries. Yeah that too > >> Or are there cases where you envision more mix and match? E.g. JNI >> libraries w/o auto-unloading? > > No as unloading is important for native library loaded by custom loaders. > > I can't really think of a good static factory method name. > > would newNonJavaNativeLIbraries be slightly clearer? newJavaNativeInterfaceLibraries vs. newRawNativeLibraries could be an option. Another option, in case we do care about mix and match, would be to use a builder - which would allow us to specify whether we want: * auto-unloading * classloader restrictions * calling JNI hooks * support linking of JNI methods But I don't think we need such level of granularity for now. Maurizio > > Mandy >> >> Maurizio >> >> On 18/03/2020 16:32, Mandy Chung wrote: >>> >>> >>> On 3/18/20 8:59 AM, Alan Bateman wrote: >>>> On 17/03/2020 23:09, Mandy Chung wrote: >>>>> >>>>> I have similar comment to myself and didn't come up good static >>>>> factory method names.?? I give it a try again: what about >>>>> newNativeLibraries and newNativeLibrariesWithNoAutoUnload? >>>> Would newTrustedNativeLibraries work? Everything else in the >>>> updated webrev looks good. >>> >>> "no auto unload" is also important.? what about >>> "newTrustedNativeLibrariesNoAutoUnload" a bit long? >>> >>> Mandy > From roger.riggs at oracle.com Wed Mar 18 21:24:45 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 18 Mar 2020 17:24:45 -0400 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: <113d3c07-9b88-3dbc-5a2c-54e1260e4319@oracle.com> References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> <80722047-3e15-3716-a015-4caf628027e5@oracle.com> <113d3c07-9b88-3dbc-5a2c-54e1260e4319@oracle.com> Message-ID: Hi, Some small updates to the source files to minimize the changes to javadoc of the _Stub classes. And fixes to the points Magnus raises below. http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-4/ Thanks, Roger On 3/18/20 9:01 AM, Magnus Ihse Bursie wrote: > > > On 2020-03-17 23:07, Roger Riggs wrote: >> Hi Magnus, Erik, >> >> Thanks for the pointers, I'm not familiar with those early build >> intricacies. >> >> Updated: >> >> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-2/ > Looking much better! > > Please remove the reference to "rmic" in Global.gmk as well. > > In Docs.gmk, the comment "# On top of the sources that was used to > compile the JDK, we need some extra sources" is no longer relevant. > Just remove it. > > In ZipSource.gmk, there crept in an extra space between the argument > and the comma. Please remove it. > > In spec.gmk.in: > - # Interim langtools and rmic modules and arguments > + # Interim langtools and arguments > > Should be "Interim langtools modules and arguments" > > Apart from this, it looks good. You do not need to re-spin the webrev > if you fix these minor nits. > > /Magnus > > > >> >> More cleanup: >> >> - cleanup of ZipSource.gmk and autoconf/spec.gmk.in and Docs.gmk >> >> - The mystery of ActivationGroup_Stub is resolved.? The class needed >> to be in the spec/javadoc >> ?? but it also needed to be generated by RMIC, the version in >> src/java.rmi/share/doc >> ?? contained the javadoc comments.? I merged the javadoc into the >> generated stub .java class >> ?? and added it to the repo. >> >> - The NetBeans Jmx build script had targets to build the stubs, they >> have been removed. >> >> Thanks, Roger >> >> >> On 3/17/20 10:06 AM, Magnus Ihse Bursie wrote: >>> On 2020-03-17 14:17, Erik Joelsson wrote: >>>> Hello, >>>> >>>> That looks better, but there are still some more things to remove. >>>> This whole block: >>>> >>>> ################################################################################ >>>> >>>> # Targets for running rmic. >>>> $(eval $(call DeclareRecipesForPhase, RMIC, \ >>>> ??? TARGET_SUFFIX := rmic, \ >>>> ??? FILE_PREFIX := Rmic, \ >>>> ??? MAKE_SUBDIR := rmic, \ >>>> ??? CHECK_MODULES := $(ALL_MODULES))) >>>> >>>> ALL_TARGETS += $(RMIC_TARGETS) >>>> >>>> And all references to $(RMIC_TARGETS) and $(RMIC_MODULES). In most >>>> cases the whole lines (like the $(foreach) calls that iterate over >>>> them) can just be removed. >>> >>> This also means killing the entire "rmic" phase of the build. So >>> please also remove the rmic target from Main.gmk line 1015, and >>> ALL_TARGETs line 1133. And the reference to "rmic" from the phases >>> in the help in Global.gmk. >>> >>> In ZipSource.gmk, there's special handling to include rmic source >>> code, which is no longer needed. >>> >>> In Docs.gmk, you can remove $(SUPPORT_OUTPUTDIR)/rmic/* from >>> MODULES_SOURCE_PATH. >>> >>> (That actually made me notice another weird rmi thingy. How does >>> these new stubs relate to >>> src/java.rmi/share/doc/stub/java/rmi/activation/ActivationGroup_Stub.java? >>> That file has been present for a long time. It is included when >>> generating Javadoc, but not when compiling the class files for the >>> JDK.) >>> >>> ?It is probably a good idea to make a case-insensitive search for >>> "rmic" in the make directory afterwards, to confirm that all >>> remaining cases of rmic should be there (i.e. it relates to >>> compiling jdk.rmi, not running rmic during the build.) >>> >>> And btw, I'm eternally grateful to you for removing this. :-) Now >>> the prospect of a fully warning-free build seems closer than ever! >>> >>> /Magnus >>> >>> >>> >>> >>> >>> >>>> >>>> /Erik >>>> >>>> On 2020-03-16 15:19, Roger Riggs wrote: >>>>> Hi Erik, >>>>> >>>>> Please review a new webrev that adds the change to remove the >>>>> interim build parts. >>>>> (Passes Tier 1-3 of CI testing) >>>>> >>>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-1/ >>>>> >>>>> Thanks, Roger >>>>> >>>>> >>>>> On 3/16/20 12:22 PM, Erik Joelsson wrote: >>>>>> Hello Roger, >>>>>> >>>>>> There is more to be removed in the makefiles. >>>>>> >>>>>> This file should also be removed: >>>>>> >>>>>> make/CompileInterimRmic.gmk >>>>>> >>>>>> In make/Main.gmk, all the targets concerning rmic needs to be >>>>>> removed as well as any dependencies declared that involves them. >>>>>> Searching for "rmic" should find all relevant lines. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2020-03-16 09:02, Roger Riggs wrote: >>>>>>> Please review adding pre-generated RMI stub classes to the jdk repo >>>>>>> and the removal of make files supporting the specific APIs. >>>>>>> >>>>>>> It removes a dependency on build time generation invoking RMIC. >>>>>>> RMIC was? deprecated in JDK 13 [1]. >>>>>>> >>>>>>> The source files have been edited to remove or suppress >>>>>>> compilation warnings. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ >>>>>>> >>>>>>> Issue: >>>>>>> ?https://bugs.openjdk.java.net/browse/JDK-8241073 >>>>>>> >>>>>>> >>>>>>> Thanks, Roger >>>>>>> >>>>>>> p.s. A future change will remove the interim build steps >>>>>>> >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8217412 >>>>> >>> >> > From brian.burkhalter at oracle.com Wed Mar 18 21:29:45 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 18 Mar 2020 14:29:45 -0700 Subject: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings In-Reply-To: <593a23d0-2f3b-ea76-2ee0-082a89eb2c89@oracle.com> References: <56F933F1-63E1-436A-9791-DA89085D0A2D@oracle.com> <032E77D2-A554-473E-AE07-DFB5E512F1B2@oracle.com> <593a23d0-2f3b-ea76-2ee0-082a89eb2c89@oracle.com> Message-ID: The change has been pushed [1]. Brian [1] http://hg.openjdk.java.net/jdk/jdk/rev/af221c1b1671 > On Mar 17, 2020, at 5:52 PM, Brent Christian wrote: > > Adding -XX:+CompactStrings seems reasonable to me. (And I think it's a betters solution than, say, increasing -Xmx to allow running without compact strings.) > > -Brent > > On 3/17/20 10:46 AM, Brian Burkhalter wrote: >> OK, I am fine with that. I?ll leave it open for the moment though in case anyone else has a comment. >> Brian >>> On Mar 17, 2020, at 10:39 AM, Andrew Leonard wrote: >>> >>> I see what you mean, but it's not really the point of the the BigInteger test, which is testing for an Arithmetic exception: >>> The problem test is the one for 8021204 which constructs a String of "0"'s 2*31 long! which if you use 2bytes for each "0" is very likely to run out of memory! The problem is a "bug" in the testcase in that it doesn't quite ensure the environment is capable of running the test, by ensuring 1byte per char helps ensure that. Hotspot is that by default. I also suspect OOME is not certain either necessarily. >>> >>> Andrew Leonard >>> Java Runtimes Development >>> IBM Hursley >>> IBM United Kingdom Ltd >>> internet email: andrew_m_leonard at uk.ibm.com >>> >>> >>> >>> >>> From: Brian Burkhalter >>> To: Andrew Leonard >>> Cc: Java Core Libs >>> Date: 17/03/2020 15:48 >>> Subject: [EXTERNAL] Re: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings >>> >>> >>> >>> To clarify, could the compact strings setting be detected and maybe add another @run tag and expect an OOME? Not sure this is critical. >>> >>> Brian >>> >>> On Mar 17, 2020, at 8:06 AM, Brian Burkhalter > wrote: >>> >>> You?re welcome. >>> >>> I see. Let?s leave this hang out a bit for further comment. Also, is a test possible, or a modification of an existing test? >>> >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From david.holmes at oracle.com Wed Mar 18 21:59:53 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Mar 2020 07:59:53 +1000 Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable In-Reply-To: References: Message-ID: <2e10bbbe-1faf-f4a8-d04b-88151a4e1122@oracle.com> Hi Jorn, This needs a CSR request before it can be pushed. Thanks, David On 19/03/2020 12:08 am, Jorn Vernee wrote: > Hi, > > Can someone please sponsor this patch that makes Boolean, Character, > Byte, and Short implement Constable? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 > Webrev: http://cr.openjdk.java.net/~jvernee/8241100/webrev.00/ > > Having the other box types implement Constable makes them easier to use > with APIs that accept any Constable. Though I'm mostly interesting in > boolean, for which I'm currently falling back to "true" & "false" > strings, but the downside is that this also requires parsing the string > again and having to deal with random other strings. > > This patch also adds the ConstantBootstraps::convert method that is used > to facilitate the conversion from int to (short|char|byte). This > currently takes a source type explicitly. In practice, it seems that > Object can always be used as a source type for the same behavior, but > explicitly specifying source and destination types seems more robust to > me in case this behavior ever changes, or we want to expand on the > supported kinds of conversion. (for instance it is currently not > possible to convert from an int to a Long directly, or from Short to > Integer, but maybe those cases could be supported in the future as well). > > Testing: tier1-3 & downstream testing for my particular use case > > Thanks, > Jorn > From john.r.rose at oracle.com Wed Mar 18 22:01:26 2020 From: john.r.rose at oracle.com (John Rose) Date: Wed, 18 Mar 2020 15:01:26 -0700 Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable In-Reply-To: References: Message-ID: On Mar 18, 2020, at 8:54 AM, Brian Goetz wrote: > > Overall, the approach seems sound, and I like that you are introducing only one new bootstrap that is usable for a range of things. A few comments and questions. > > 1. Not sure the explicit source type carries its weight, but whether it does or not is probably informed by whatever we do for (3) below. It seems true to me that Object is an acceptable universal source type. You can convert anything in the CP to Object without loss of information. IIRC this is true even for the asType rules; they are designed to take most of their information (when deciding which conversions to apply) from the target type, not the source type. > 2. Naming: ?convert? seems kind of general; the name should suggest some sort of asType conversion. asType is pretty rich, and will get richer in the future, so aligning with that is probably a good move. +1 Suggest ?convertAsType?. > 3. The spec on convert() needs to be fleshed out, as to exactly which set of conversions are supported. ?Exactly the same set as asType? is OK; ?similar to asType? is kind of vague. Similarly, the spec on parameters and exceptions could be fleshed out a bit too. +1 I suggest a formal semantics along these lines: var id = identity(sourceType); // could be destType also var mt = methodType(destType, sourceType); var conv = explicitCastArguments(id, mt); return conv.invoke(x); The explicitCastArguments is linked to asType but adjusts the handling of interfaces and of subword types (char and boolean, byte and short) to more closely match the conventions used by JVM bytecodes, when that differs from the conventions used in the Java language. I think it covers the conversions of JVM-level values you are likely to encounter in the constant pool. ? John From john.r.rose at oracle.com Wed Mar 18 22:06:44 2020 From: john.r.rose at oracle.com (John Rose) Date: Wed, 18 Mar 2020 15:06:44 -0700 Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable In-Reply-To: References: Message-ID: <1E26FBB6-172B-4BDD-A286-2C0BB6E5B1CE@oracle.com> On Mar 18, 2020, at 3:01 PM, John Rose wrote: > > explicitCastArguments P.S. That method has an intentionally scary name, but behind the name, it?s just ?asType, the JVM edition, plus narrowing primitive conversions?. The design center for asType is safe and sane conversions as allowed by variable assignment in Java, while the other guy adds all the other conversions that might be useful. If you know statically what is the input value type, as with BSMs working on CP data, then ?explicitCastArguments? is just as safe as ?asType? but it does more tricks for you. From erik.joelsson at oracle.com Wed Mar 18 22:43:13 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Mar 2020 15:43:13 -0700 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> <80722047-3e15-3716-a015-4caf628027e5@oracle.com> <113d3c07-9b88-3dbc-5a2c-54e1260e4319@oracle.com> Message-ID: <033e2926-04c3-95ec-3c94-e49507891506@oracle.com> Looks good. /Erik On 2020-03-18 14:24, Roger Riggs wrote: > Hi, > > Some small updates to the source files to minimize the changes to javadoc > of the _Stub classes. > > And fixes to the points Magnus raises below. > > http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-4/ > > Thanks, Roger > > > On 3/18/20 9:01 AM, Magnus Ihse Bursie wrote: >> >> >> On 2020-03-17 23:07, Roger Riggs wrote: >>> Hi Magnus, Erik, >>> >>> Thanks for the pointers, I'm not familiar with those early build >>> intricacies. >>> >>> Updated: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-2/ >> Looking much better! >> >> Please remove the reference to "rmic" in Global.gmk as well. >> >> In Docs.gmk, the comment "# On top of the sources that was used to >> compile the JDK, we need some extra sources" is no longer relevant. >> Just remove it. >> >> In ZipSource.gmk, there crept in an extra space between the argument >> and the comma. Please remove it. >> >> In spec.gmk.in: >> - # Interim langtools and rmic modules and arguments >> + # Interim langtools and arguments >> >> Should be "Interim langtools modules and arguments" >> >> Apart from this, it looks good. You do not need to re-spin the webrev >> if you fix these minor nits. >> >> /Magnus >> >> >> >>> >>> More cleanup: >>> >>> - cleanup of ZipSource.gmk and autoconf/spec.gmk.in and Docs.gmk >>> >>> - The mystery of ActivationGroup_Stub is resolved.? The class needed >>> to be in the spec/javadoc >>> ?? but it also needed to be generated by RMIC, the version in >>> src/java.rmi/share/doc >>> ?? contained the javadoc comments.? I merged the javadoc into the >>> generated stub .java class >>> ?? and added it to the repo. >>> >>> - The NetBeans Jmx build script had targets to build the stubs, they >>> have been removed. >>> >>> Thanks, Roger >>> >>> >>> On 3/17/20 10:06 AM, Magnus Ihse Bursie wrote: >>>> On 2020-03-17 14:17, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> That looks better, but there are still some more things to remove. >>>>> This whole block: >>>>> >>>>> ################################################################################ >>>>> >>>>> # Targets for running rmic. >>>>> $(eval $(call DeclareRecipesForPhase, RMIC, \ >>>>> ??? TARGET_SUFFIX := rmic, \ >>>>> ??? FILE_PREFIX := Rmic, \ >>>>> ??? MAKE_SUBDIR := rmic, \ >>>>> ??? CHECK_MODULES := $(ALL_MODULES))) >>>>> >>>>> ALL_TARGETS += $(RMIC_TARGETS) >>>>> >>>>> And all references to $(RMIC_TARGETS) and $(RMIC_MODULES). In most >>>>> cases the whole lines (like the $(foreach) calls that iterate over >>>>> them) can just be removed. >>>> >>>> This also means killing the entire "rmic" phase of the build. So >>>> please also remove the rmic target from Main.gmk line 1015, and >>>> ALL_TARGETs line 1133. And the reference to "rmic" from the phases >>>> in the help in Global.gmk. >>>> >>>> In ZipSource.gmk, there's special handling to include rmic source >>>> code, which is no longer needed. >>>> >>>> In Docs.gmk, you can remove $(SUPPORT_OUTPUTDIR)/rmic/* from >>>> MODULES_SOURCE_PATH. >>>> >>>> (That actually made me notice another weird rmi thingy. How does >>>> these new stubs relate to >>>> src/java.rmi/share/doc/stub/java/rmi/activation/ActivationGroup_Stub.java? >>>> That file has been present for a long time. It is included when >>>> generating Javadoc, but not when compiling the class files for the >>>> JDK.) >>>> >>>> ?It is probably a good idea to make a case-insensitive search for >>>> "rmic" in the make directory afterwards, to confirm that all >>>> remaining cases of rmic should be there (i.e. it relates to >>>> compiling jdk.rmi, not running rmic during the build.) >>>> >>>> And btw, I'm eternally grateful to you for removing this. :-) Now >>>> the prospect of a fully warning-free build seems closer than ever! >>>> >>>> /Magnus >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> /Erik >>>>> >>>>> On 2020-03-16 15:19, Roger Riggs wrote: >>>>>> Hi Erik, >>>>>> >>>>>> Please review a new webrev that adds the change to remove the >>>>>> interim build parts. >>>>>> (Passes Tier 1-3 of CI testing) >>>>>> >>>>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-1/ >>>>>> >>>>>> Thanks, Roger >>>>>> >>>>>> >>>>>> On 3/16/20 12:22 PM, Erik Joelsson wrote: >>>>>>> Hello Roger, >>>>>>> >>>>>>> There is more to be removed in the makefiles. >>>>>>> >>>>>>> This file should also be removed: >>>>>>> >>>>>>> make/CompileInterimRmic.gmk >>>>>>> >>>>>>> In make/Main.gmk, all the targets concerning rmic needs to be >>>>>>> removed as well as any dependencies declared that involves them. >>>>>>> Searching for "rmic" should find all relevant lines. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2020-03-16 09:02, Roger Riggs wrote: >>>>>>>> Please review adding pre-generated RMI stub classes to the jdk >>>>>>>> repo >>>>>>>> and the removal of make files supporting the specific APIs. >>>>>>>> >>>>>>>> It removes a dependency on build time generation invoking RMIC. >>>>>>>> RMIC was? deprecated in JDK 13 [1]. >>>>>>>> >>>>>>>> The source files have been edited to remove or suppress >>>>>>>> compilation warnings. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ >>>>>>>> >>>>>>>> Issue: >>>>>>>> ?https://bugs.openjdk.java.net/browse/JDK-8241073 >>>>>>>> >>>>>>>> >>>>>>>> Thanks, Roger >>>>>>>> >>>>>>>> p.s. A future change will remove the interim build steps >>>>>>>> >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8217412 >>>>>> >>>> >>> >> > From mandy.chung at oracle.com Thu Mar 19 00:39:25 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Mar 2020 17:39:25 -0700 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> <11be7843-a805-5bdd-25ea-8dc30445eb7c@oracle.com> <5b72c1d8-25b8-70b7-cd90-0b02e7827052@oracle.com> Message-ID: <8c429a87-fbeb-475d-472b-4f23df3716da@oracle.com> On 3/18/20 12:13 PM, Maurizio Cimadamore wrote: > > On 18/03/2020 18:40, Mandy Chung wrote: >> >> >> On 3/18/20 11:16 AM, Maurizio Cimadamore wrote: >>> So, maybe I'm saying something naive, but isn't the difference >>> between the two mechanisms mostly there to distinguish between JNI >>> libraries and non-JNI libraries? >>> >> >> I think such distinction is kind of blurry at the moment.?? One thing >> for sure is that JNI native method binding won't happen with the >> native libraries loaded through this new mechanism. >> >> OTOH, should JNI_OnLoad and JNI_Unload be invoked if it is a non-JNI >> library?? The new mechanism still does.? I expect that this will be >> cleared up from panama specification. > Should defo not happen in Panama-loaded libraries OK, I will make some adjustment to ignore JNI_OnLoad and JNI_Unload.?? I think this is a clean distinction of these two mechanisms. Will send an updated webrev later. >> >>> Or are there cases where you envision more mix and match? E.g. JNI >>> libraries w/o auto-unloading? >> >> No as unloading is important for native library loaded by custom >> loaders. >> >> I can't really think of a good static factory method name. >> >> would newNonJavaNativeLIbraries be slightly clearer? > > newJavaNativeInterfaceLibraries > > vs. > > newRawNativeLibraries > Both are good to me. > could be an option. > > Another option, in case we do care about mix and match, would be to > use a builder - which would allow us to specify whether we want: > > * auto-unloading > * classloader restrictions > * calling JNI hooks > * support linking of JNI methods > > But I don't think we need such level of granularity for now. > I don't think we need that neither. Mandy > Maurizio > >> >> Mandy >>> >>> Maurizio >>> >>> On 18/03/2020 16:32, Mandy Chung wrote: >>>> >>>> >>>> On 3/18/20 8:59 AM, Alan Bateman wrote: >>>>> On 17/03/2020 23:09, Mandy Chung wrote: >>>>>> >>>>>> I have similar comment to myself and didn't come up good static >>>>>> factory method names.?? I give it a try again: what about >>>>>> newNativeLibraries and newNativeLibrariesWithNoAutoUnload? >>>>> Would newTrustedNativeLibraries work? Everything else in the >>>>> updated webrev looks good. >>>> >>>> "no auto unload" is also important.? what about >>>> "newTrustedNativeLibrariesNoAutoUnload" a bit long? >>>> >>>> Mandy >> From xu.y.yin at oracle.com Thu Mar 19 03:40:38 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Thu, 19 Mar 2020 11:40:38 +0800 Subject: [15] RFR: 8202117: com/sun/jndi/ldap/RemoveNamingListenerTest.java fails intermittently: Connection reset In-Reply-To: <0230e649-c5fd-ca18-11c2-dba7d17f5538@oracle.com> References: <15783e53-6100-e257-b666-b53f91f8aaff@oracle.com> <0230e649-c5fd-ca18-11c2-dba7d17f5538@oracle.com> Message-ID: <4233A38B-775A-49A4-A6DC-1674B0947970@oracle.com> Thank you, Daniel, Vyom Pushed. Regards, Chris > On 18 Mar 2020, at 6:03 PM, Daniel Fuchs wrote: > > Hi Chris, > > Thanks for that! > > It looks good to me. > > best regards, > > -- daniel > > On 16/03/2020 07:26, Chris Yin wrote: >> Thanks for reviewing, Daniel, Vyom. >> Hi, Daniel >> I modified the test as you suggested to cover the potential issue with URIBuilder, many thanks. Updated webrev as below: >> http://cr.openjdk.java.net/~xyin/8202117/webrev.01/ >> Regards, >> Chris From xu.y.yin at oracle.com Thu Mar 19 07:23:41 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Thu, 19 Mar 2020 15:23:41 +0800 Subject: [15] RFR: 8241130: com.sun.jndi.ldap.EventSupport.removeDeadNotifier: java.lang.NullPointerException In-Reply-To: References: Message-ID: Hi, Daniel Thank you for reviewing this, inline > On 18 Mar 2020, at 7:24 PM, Daniel Fuchs wrote: > > Hi Chris, > > Thanks for taking care of this followup fix. > > I see at least three other places where `notifiers` is accessed > without a null check. It might be good to fix these three other > places too just in case. > (two addNamingListener methods and 1 removeNamingListener) > All of them are already synchronized so a simple null check should > be enough. Yes, that's reasonable to handle the 3 places as you mentioned, just the situation seems more complex as below. I considered a lot, but no good idea yet, so finally decided to leave them untouched for now since it?s no harm to current bug, we could have some discussion if you have some idea or suggestions, then maybe create a follow up - follow up item to track it. Current fix change is trying to handle the potential multithreading issue which caused by background thread that out of user?s control (EventSupport.removeDeadNotifier and EventSupport.queueEvent may been called and only been called by background thread such as ?com.sun.jndi.ldap.NamingEventNotifier?) For the 3 other places (two addNamingListener methods and 1 removeNamingListener), searching the usages, they could only been called from ?com.sun.jndi.ldap.LdapCtx? which is controlled by user, that means to hit NullPointerException, user need to close ldap context then try to add/remove namingListener with previous closed ldap context, that sounds like a user programing error. Per javadoc from EventContext and EventDirContext interface which implemented by LdapCtx that will call EventSupport, "NamingException should be thrown if a problem was encountered" when add/remove NamingListener, that requires us to construct a meaningful NamingException and get back to user to indicate problem encountered instead of 'simple null check? + skip (like current fix), certainly, where is the suitable place to put the logic (maybe LdapCtx or EventSupport) still to be determined. Even worse, if some legacy user code already follow original NullPointerException way to handle special case, well, incredible. > > Also you could had the @bug 8241130 > to RemoveNamingListenerTest.java, since the test can be used > to verify the fix (if run often enough). Sure, updated webrev as below, thanks http://cr.openjdk.java.net/~xyin/8241130/webrev.01/ Regards, Chris > > best regards, > > -- daniel > > On 18/03/2020 08:16, Chris Yin wrote: >> Hello >> Please review following changes to fix corner issue in com.sun.jndi.ldap.EventSupport, thanks >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241130 >> Webrev: http://cr.openjdk.java.net/~xyin/8241130/webrev.00/ >> This is a follow up item which related to 8202117. When testing the second revision fix for 8202117 (http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065270.html), intermittent failure with java.lang.NullPointerException been observed(Thanks Daniel for additional testing), that exposed another issue in com.sun.jndi.ldap.EventSupport. >> ?com.sun.jndi.ldap.NamingEventNotifier" is a background thread which been created when addNamingListener with ldap context, per code logic, it will call EventSupport.removeDeadNotifier when encounter NamingException (maybe wrapped a SocketException) in some case, if user closed source ldap context first (EventSupport.cleanup been triggered), the call to EventSupport.removeDeadNotifier will throw NullPointerException since var ?notifiers? already been set to null in previous EventSupport.cleanup. Maybe in real world, it?s hard to get all criteria been satisfied to reproduce, but it?s still a potential multithreading issue and caught by test with repeat run. >> Combined this change and 8202117 second revision change, run test com/sun/jndi/ldap/RemoveNamingListenerTest.java on 4 platforms for total 2000 times, no failure been observed, also tier1, tier2, tier3 tests passed. >> Thanks, >> Chris > From magnus.ihse.bursie at oracle.com Thu Mar 19 07:32:10 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 19 Mar 2020 08:32:10 +0100 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> <80722047-3e15-3716-a015-4caf628027e5@oracle.com> <113d3c07-9b88-3dbc-5a2c-54e1260e4319@oracle.com> Message-ID: On 2020-03-18 22:24, Roger Riggs wrote: > Hi, > > Some small updates to the source files to minimize the changes to javadoc > of the _Stub classes. > > And fixes to the points Magnus raises below. > > http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-4/ Looks good! Thank you for getting this the whole way. /Magnus > > Thanks, Roger > > > On 3/18/20 9:01 AM, Magnus Ihse Bursie wrote: >> >> >> On 2020-03-17 23:07, Roger Riggs wrote: >>> Hi Magnus, Erik, >>> >>> Thanks for the pointers, I'm not familiar with those early build >>> intricacies. >>> >>> Updated: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-2/ >> Looking much better! >> >> Please remove the reference to "rmic" in Global.gmk as well. >> >> In Docs.gmk, the comment "# On top of the sources that was used to >> compile the JDK, we need some extra sources" is no longer relevant. >> Just remove it. >> >> In ZipSource.gmk, there crept in an extra space between the argument >> and the comma. Please remove it. >> >> In spec.gmk.in: >> - # Interim langtools and rmic modules and arguments >> + # Interim langtools and arguments >> >> Should be "Interim langtools modules and arguments" >> >> Apart from this, it looks good. You do not need to re-spin the webrev >> if you fix these minor nits. >> >> /Magnus >> >> >> >>> >>> More cleanup: >>> >>> - cleanup of ZipSource.gmk and autoconf/spec.gmk.in and Docs.gmk >>> >>> - The mystery of ActivationGroup_Stub is resolved.? The class needed >>> to be in the spec/javadoc >>> ?? but it also needed to be generated by RMIC, the version in >>> src/java.rmi/share/doc >>> ?? contained the javadoc comments.? I merged the javadoc into the >>> generated stub .java class >>> ?? and added it to the repo. >>> >>> - The NetBeans Jmx build script had targets to build the stubs, they >>> have been removed. >>> >>> Thanks, Roger >>> >>> >>> On 3/17/20 10:06 AM, Magnus Ihse Bursie wrote: >>>> On 2020-03-17 14:17, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> That looks better, but there are still some more things to remove. >>>>> This whole block: >>>>> >>>>> ################################################################################ >>>>> >>>>> # Targets for running rmic. >>>>> $(eval $(call DeclareRecipesForPhase, RMIC, \ >>>>> ??? TARGET_SUFFIX := rmic, \ >>>>> ??? FILE_PREFIX := Rmic, \ >>>>> ??? MAKE_SUBDIR := rmic, \ >>>>> ??? CHECK_MODULES := $(ALL_MODULES))) >>>>> >>>>> ALL_TARGETS += $(RMIC_TARGETS) >>>>> >>>>> And all references to $(RMIC_TARGETS) and $(RMIC_MODULES). In most >>>>> cases the whole lines (like the $(foreach) calls that iterate over >>>>> them) can just be removed. >>>> >>>> This also means killing the entire "rmic" phase of the build. So >>>> please also remove the rmic target from Main.gmk line 1015, and >>>> ALL_TARGETs line 1133. And the reference to "rmic" from the phases >>>> in the help in Global.gmk. >>>> >>>> In ZipSource.gmk, there's special handling to include rmic source >>>> code, which is no longer needed. >>>> >>>> In Docs.gmk, you can remove $(SUPPORT_OUTPUTDIR)/rmic/* from >>>> MODULES_SOURCE_PATH. >>>> >>>> (That actually made me notice another weird rmi thingy. How does >>>> these new stubs relate to >>>> src/java.rmi/share/doc/stub/java/rmi/activation/ActivationGroup_Stub.java? >>>> That file has been present for a long time. It is included when >>>> generating Javadoc, but not when compiling the class files for the >>>> JDK.) >>>> >>>> ?It is probably a good idea to make a case-insensitive search for >>>> "rmic" in the make directory afterwards, to confirm that all >>>> remaining cases of rmic should be there (i.e. it relates to >>>> compiling jdk.rmi, not running rmic during the build.) >>>> >>>> And btw, I'm eternally grateful to you for removing this. :-) Now >>>> the prospect of a fully warning-free build seems closer than ever! >>>> >>>> /Magnus >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> /Erik >>>>> >>>>> On 2020-03-16 15:19, Roger Riggs wrote: >>>>>> Hi Erik, >>>>>> >>>>>> Please review a new webrev that adds the change to remove the >>>>>> interim build parts. >>>>>> (Passes Tier 1-3 of CI testing) >>>>>> >>>>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-1/ >>>>>> >>>>>> Thanks, Roger >>>>>> >>>>>> >>>>>> On 3/16/20 12:22 PM, Erik Joelsson wrote: >>>>>>> Hello Roger, >>>>>>> >>>>>>> There is more to be removed in the makefiles. >>>>>>> >>>>>>> This file should also be removed: >>>>>>> >>>>>>> make/CompileInterimRmic.gmk >>>>>>> >>>>>>> In make/Main.gmk, all the targets concerning rmic needs to be >>>>>>> removed as well as any dependencies declared that involves them. >>>>>>> Searching for "rmic" should find all relevant lines. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2020-03-16 09:02, Roger Riggs wrote: >>>>>>>> Please review adding pre-generated RMI stub classes to the jdk >>>>>>>> repo >>>>>>>> and the removal of make files supporting the specific APIs. >>>>>>>> >>>>>>>> It removes a dependency on build time generation invoking RMIC. >>>>>>>> RMIC was? deprecated in JDK 13 [1]. >>>>>>>> >>>>>>>> The source files have been edited to remove or suppress >>>>>>>> compilation warnings. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073/ >>>>>>>> >>>>>>>> Issue: >>>>>>>> ?https://bugs.openjdk.java.net/browse/JDK-8241073 >>>>>>>> >>>>>>>> >>>>>>>> Thanks, Roger >>>>>>>> >>>>>>>> p.s. A future change will remove the interim build steps >>>>>>>> >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8217412 >>>>>> >>>> >>> >> > From Alan.Bateman at oracle.com Thu Mar 19 07:39:38 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Mar 2020 07:39:38 +0000 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> <80722047-3e15-3716-a015-4caf628027e5@oracle.com> <113d3c07-9b88-3dbc-5a2c-54e1260e4319@oracle.com> Message-ID: <0d08a004-c930-652c-8ef4-5300fd8fe1fd@oracle.com> On 18/03/2020 21:24, Roger Riggs wrote: > Hi, > > Some small updates to the source files to minimize the changes to javadoc > of the _Stub classes. All looks good but the updated ActivationGroup_Stub should probably get a one-pass to eliminate the inconsistencies, e.g. the new version imports some java.rmi.* classes but uses qualified class names in several places. There is unusual formatting in several places, e.g. L90/91. So just nits but since the entire line is changed then maybe run get the IDE to tidy it up before pushing. -Alan From denghui.ddh at alibaba-inc.com Thu Mar 19 08:35:15 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 19 Mar 2020 16:35:15 +0800 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: <401741d6-cb99-d170-9a1f-a8793a8b1dd8@oracle.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> <401741d6-cb99-d170-9a1f-a8793a8b1dd8@oracle.com> Message-ID: <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com> Hi, > On Mar 18, 2020, at 11:46 PM, Alan Bateman wrote: > > > > On 13/03/2020 14:54, Denghui Dong wrote: >> Good suggestion, moved. >> Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.03/ > This looks much better. > > What would you think about renaming the JFR event to "DirectBufferStatistics"? The concern I have with the proposed naming is that it will be really awkward to extend it to support mapped buffers. It?s ok for me. > > The implementation changes look okay, hopefully Erik will skim over them. One small suggestion for for ManagementFactoryHelper is that you can stream().collect(Collectors.toList()) to create the value for bufferPools. You could even change it to volatile so that getBufferMXBeans isn't a synchronized method. > Make sense, updated. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.04/ @Erik, could you help review it? > -Alan. Denghui Dong From andrew_m_leonard at uk.ibm.com Thu Mar 19 10:06:21 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 19 Mar 2020 10:06:21 +0000 Subject: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings In-Reply-To: References: <56F933F1-63E1-436A-9791-DA89085D0A2D@oracle.com> <032E77D2-A554-473E-AE07-DFB5E512F1B2@oracle.com> <593a23d0-2f3b-ea76-2ee0-082a89eb2c89@oracle.com> Message-ID: Many thanks Brian Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Brian Burkhalter To: Brent Christian , Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 18/03/2020 21:30 Subject: [EXTERNAL] Re: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings The change has been pushed [1]. Brian [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_af221c1b1671&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=pveHg-Ji0W2vERDjaC2vTsHmLjJ5SE0v7hCoWeE3-JI&s=nEulAw34f29rBdVYwXJON3kDy7DsfSTI_vyhDBlCG8E&e= > On Mar 17, 2020, at 5:52 PM, Brent Christian wrote: > > Adding -XX:+CompactStrings seems reasonable to me. (And I think it's a betters solution than, say, increasing -Xmx to allow running without compact strings.) > > -Brent > > On 3/17/20 10:46 AM, Brian Burkhalter wrote: >> OK, I am fine with that. I?ll leave it open for the moment though in case anyone else has a comment. >> Brian >>> On Mar 17, 2020, at 10:39 AM, Andrew Leonard wrote: >>> >>> I see what you mean, but it's not really the point of the the BigInteger test, which is testing for an Arithmetic exception: >>> The problem test is the one for 8021204 which constructs a String of "0"'s 2*31 long! which if you use 2bytes for each "0" is very likely to run out of memory! The problem is a "bug" in the testcase in that it doesn't quite ensure the environment is capable of running the test, by ensuring 1byte per char helps ensure that. Hotspot is that by default. I also suspect OOME is not certain either necessarily. >>> >>> Andrew Leonard >>> Java Runtimes Development >>> IBM Hursley >>> IBM United Kingdom Ltd >>> internet email: andrew_m_leonard at uk.ibm.com >>> >>> >>> >>> >>> From: Brian Burkhalter >>> To: Andrew Leonard >>> Cc: Java Core Libs >>> Date: 17/03/2020 15:48 >>> Subject: [EXTERNAL] Re: Sponsor Request: 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings >>> >>> >>> >>> To clarify, could the compact strings setting be detected and maybe add another @run tag and expect an OOME? Not sure this is critical. >>> >>> Brian >>> >>> On Mar 17, 2020, at 8:06 AM, Brian Burkhalter > wrote: >>> >>> You?re welcome. >>> >>> I see. Let?s leave this hang out a bit for further comment. Also, is a test possible, or a modification of an existing test? >>> >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From daniel.fuchs at oracle.com Thu Mar 19 11:54:01 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 19 Mar 2020 11:54:01 +0000 Subject: [15] RFR: 8241130: com.sun.jndi.ldap.EventSupport.removeDeadNotifier: java.lang.NullPointerException In-Reply-To: References: Message-ID: Hi Chris, On 19/03/2020 07:23, Chris Yin wrote: > [...] Per javadoc from EventContext and EventDirContext interface which implemented by LdapCtx that will call EventSupport, "NamingException should be thrown if a problem was encountered" when add/remove NamingListener, that requires us to construct a meaningful NamingException and get back to user to indicate problem encountered instead of 'simple null check? + skip (like current fix), certainly, where is the suitable place to put the logic (maybe LdapCtx or EventSupport) still to be determined. [...] OK, I can see where you're going. Let's handle that separately then. I could verify that your patch indeed solves the intermittent test failure. You have my review! best regards, -- daniel >> Also you could had the @bug 8241130 >> to RemoveNamingListenerTest.java, since the test can be used >> to verify the fix (if run often enough). > Sure, updated webrev as below, thanks > > http://cr.openjdk.java.net/~xyin/8241130/webrev.01/ From brian.burkhalter at oracle.com Thu Mar 19 14:43:16 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 19 Mar 2020 07:43:16 -0700 Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF In-Reply-To: <05887BD3-F7F1-4DA6-86EA-82929BC26874@oracle.com> References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com> <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com> <14E6EF7F-C01F-4407-B865-32089266DC28@oracle.com> <665e81fc-5136-2cf6-748b-6c6f448cfc16@oracle.com> <575CE79A-D60C-4550-B74D-EDA1FAFBAF2F@oracle.com> <05887BD3-F7F1-4DA6-86EA-82929BC26874@oracle.com> Message-ID: <7B4443ED-626F-4273-8604-336CA2E868ED@oracle.com> Another webrev [1] which is adjusted from the previous one per the comments on the CSR [2] is available for review. The only change is to the class-level specification: --- a/src/java.base/share/classes/java/io/LineNumberReader.java +++ b/src/java.base/share/classes/java/io/LineNumberReader.java @@ -41,7 +41,8 @@ * *

        A line is considered to be terminated by any one of a * line feed ('\n'), a carriage return ('\r'), or a carriage return followed - * immediately by a linefeed. + * immediately by a linefeed, or any of the previous terminators followed by + * end of stream, or end of stream not preceded by another terminator. * Thanks, Brian > On Mar 13, 2020, at 10:28 AM, Brian Burkhalter wrote: > > An updated webrev is at [1] and a CSR has been filed [2]. [1] http://cr.openjdk.java.net/~bpb/8235792/webrev.02/ [2] https://bugs.openjdk.java.net/browse/JDK-8241020 From roger.riggs at oracle.com Thu Mar 19 15:14:07 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 19 Mar 2020 11:14:07 -0400 Subject: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming In-Reply-To: <0d08a004-c930-652c-8ef4-5300fd8fe1fd@oracle.com> References: <5fdd130c-2e72-e535-a6f3-aa0c7f74c1b9@oracle.com> <3694adbb-a574-a2ee-293b-bd952c0f2d92@oracle.com> <80722047-3e15-3716-a015-4caf628027e5@oracle.com> <113d3c07-9b88-3dbc-5a2c-54e1260e4319@oracle.com> <0d08a004-c930-652c-8ef4-5300fd8fe1fd@oracle.com> Message-ID: Hi Alan, The mismatches are due to the combination of generated Stub and old stub source. I'll clean it up a bit before pushing.? As pretty static code it didn't seem worth much investment. Thanks, Roger On 3/19/20 3:39 AM, Alan Bateman wrote: > > > On 18/03/2020 21:24, Roger Riggs wrote: >> Hi, >> >> Some small updates to the source files to minimize the changes to >> javadoc >> of the _Stub classes. > All looks good but the updated ActivationGroup_Stub should probably > get a one-pass to eliminate the inconsistencies, e.g. the new version > imports some java.rmi.* classes but uses qualified class names in > several places. There is unusual formatting in several places, e.g. > L90/91. So just nits but since the entire line is changed then maybe > run get the IDE to tidy it up before pushing. > > -Alan From magnus.ihse.bursie at oracle.com Thu Mar 19 16:53:09 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 19 Mar 2020 17:53:09 +0100 Subject: RFR: JDK-8241310 Fix warnings in jdk buildtools Message-ID: <99c00548-f01a-dacc-ef41-bab6e4942e09@oracle.com> The buildtools (java tools needed to be run during the build) have long been plagued by warnings, includuing deprecations and unchecked warnings, which cannot be silenced during the build. This patch fixes all buildtool warnings. Most of the warnings are fixed properly, but a few have had their warnings suppressed locally. For two tools, cldrconverter and tzdb, I gave up to get them fully fixed, and instead suppressed warnings in some places. Common for both these tools were that they used collections of some kind, with a mixed bag of data types (e.g. a Map from String to either String, HashMap, ArrayList and String[]). I'm frankly not sure how this could ever have worked :-) but I assume that the data files being parsed has a structure that "guarantees" that this works. Two files in generatecharacter were missing a proper copyright header. I noticed this when I were about to update the copyright year, and when I checked the other files I noted another one without header. While I did not need to change this file, I thought it was suitable to fix the missing header for both files. I have verified that the code generated by the build is identical with and without this patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8241310 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241310-fix-warnings-in-buildtools/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Mar 19 17:54:17 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 Mar 2020 10:54:17 -0700 Subject: RFR: JDK-8241310 Fix warnings in jdk buildtools In-Reply-To: <99c00548-f01a-dacc-ef41-bab6e4942e09@oracle.com> References: <99c00548-f01a-dacc-ef41-bab6e4942e09@oracle.com> Message-ID: Looks good to me. I love the WrapperGenerator using Vector and Hashtable! /Erik On 2020-03-19 09:53, Magnus Ihse Bursie wrote: > The buildtools (java tools needed to be run during the build) have > long been plagued by warnings, includuing deprecations and unchecked > warnings, which cannot be silenced during the build. > > This patch fixes all buildtool warnings. Most of the warnings are > fixed properly, but a few have had their warnings suppressed locally. > > For two tools, cldrconverter and tzdb, I gave up to get them fully > fixed, and instead suppressed warnings in some places. Common for both > these tools were that they used collections of some kind, with a mixed > bag of data types (e.g. a Map from String to either String, HashMap, > ArrayList and String[]). I'm frankly not sure how this could ever have > worked :-) but I assume that the data files being parsed has a > structure that "guarantees" that this works. > > Two files in generatecharacter were missing a proper copyright header. > I noticed this when I were about to update the copyright year, and > when I checked the other files I noted another one without header. > While I did not need to change this file, I thought it was suitable to > fix the missing header for both files. > > I have verified that the code generated by the build is identical with > and without this patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241310 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241310-fix-warnings-in-buildtools/webrev.01 > > /Magnus From forax at univ-mlv.fr Thu Mar 19 18:12:54 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 19 Mar 2020 19:12:54 +0100 (CET) Subject: RFR: JDK-8241310 Fix warnings in jdk buildtools In-Reply-To: <99c00548-f01a-dacc-ef41-bab6e4942e09@oracle.com> References: <99c00548-f01a-dacc-ef41-bab6e4942e09@oracle.com> Message-ID: <1352849480.610522.1584641574288.JavaMail.zimbra@u-pem.fr> Hi Magnus, please try not to use @SuppressWarnings("unchecked") on methods, but on local variable instead to reduce the scope, you can introduce a local variable for that. In Bundle, your patch declare @SuppressWarnings("unchecked") on the method while you already have a local variable with a @SuppressWarnings("unchecked"). Also, usually you don't need @SuppressWarnings("rawtype") apart when you use Object.getClass, otherwise using a wilcard solve the issue. By example in PluralsParseHandle, instead of Entry entry = (Entry)currentContainer; the code should be Entry entry = (Entry)currentContainer; BTW, in this method, you have an Arrays.stream(array).forEach() which is an antipattern, a simple loop should be used instead. regards, R?mi ----- Mail original ----- > De: "Magnus Ihse Bursie" > ?: "build-dev" , "core-libs-dev" > Envoy?: Jeudi 19 Mars 2020 17:53:09 > Objet: RFR: JDK-8241310 Fix warnings in jdk buildtools > The buildtools (java tools needed to be run during the build) have long > been plagued by warnings, includuing deprecations and unchecked > warnings, which cannot be silenced during the build. > > This patch fixes all buildtool warnings. Most of the warnings are fixed > properly, but a few have had their warnings suppressed locally. > > For two tools, cldrconverter and tzdb, I gave up to get them fully > fixed, and instead suppressed warnings in some places. Common for both > these tools were that they used collections of some kind, with a mixed > bag of data types (e.g. a Map from String to either String, HashMap, > ArrayList and String[]). I'm frankly not sure how this could ever have > worked :-) but I assume that the data files being parsed has a structure > that "guarantees" that this works. > > Two files in generatecharacter were missing a proper copyright header. I > noticed this when I were about to update the copyright year, and when I > checked the other files I noted another one without header. While I did > not need to change this file, I thought it was suitable to fix the > missing header for both files. > > I have verified that the code generated by the build is identical with > and without this patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241310 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241310-fix-warnings-in-buildtools/webrev.01 > > /Magnus From paul.sandoz at oracle.com Thu Mar 19 19:46:46 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 19 Mar 2020 12:46:46 -0700 Subject: RFR JEP 338: Vector API (Incubator), JDK-8223347 Integration of Vector API (Incubator): Vector API Message-ID: Hi, This email is intended to kick start the review of JEP 338: Vector API (Incubator). For ease of review we intend to split this up into separate parts for review of the Java API, Java implementation, Java unit tests, Java jmh tests, shared hotspot code, and platform specific hotspot code. Emails will be sent for review hopefully all during this month (given global events though our productivity may be impacted as I might also anticipate for those reviewing). First up for review is the Vector API itself. JavaDoc and specdiff may be found here: http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/ http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/docs/api/jdk.incubator.vector/jdk/incubator/vector/package-summary.html http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/docs/api/jdk.incubator.vector/jdk/incubator/vector/Vector.html The CSR issue (https://bugs.openjdk.java.net/browse/JDK-8223348 ) has also been moved to proposed. For a holistic sense during this split review one can go directly to the Panama dev repository and checkout the (confusingly named) vector-unstable branch (it was just conveniently there separate from the vectorIntrinsics branch where ongoing work will happen). https://hg.openjdk.java.net/panama/dev/shortlog/vector-unstable Paul. From xu.y.yin at oracle.com Fri Mar 20 02:18:47 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Fri, 20 Mar 2020 10:18:47 +0800 Subject: [15] RFR: 8241130: com.sun.jndi.ldap.EventSupport.removeDeadNotifier: java.lang.NullPointerException In-Reply-To: References: Message-ID: <4C32122B-AE04-4295-BBA4-3E3CF301AF0D@oracle.com> Thank you, Daniel Regards, Chris > On 19 Mar 2020, at 7:54 PM, Daniel Fuchs wrote: > > Hi Chris, > > On 19/03/2020 07:23, Chris Yin wrote: >> [...] Per javadoc from EventContext and EventDirContext interface which implemented by LdapCtx that will call EventSupport, "NamingException should be thrown if a problem was encountered" when add/remove NamingListener, that requires us to construct a meaningful NamingException and get back to user to indicate problem encountered instead of 'simple null check? + skip (like current fix), certainly, where is the suitable place to put the logic (maybe LdapCtx or EventSupport) still to be determined. [...] > > OK, I can see where you're going. Let's handle that separately then. > > I could verify that your patch indeed solves the intermittent > test failure. > > You have my review! > > best regards, > > -- daniel > >>> Also you could had the @bug 8241130 >>> to RemoveNamingListenerTest.java, since the test can be used >>> to verify the fix (if run often enough). >> Sure, updated webrev as below, thanks >> http://cr.openjdk.java.net/~xyin/8241130/webrev.01/ > From mandy.chung at oracle.com Fri Mar 20 03:43:13 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Mar 2020 20:43:13 -0700 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: <8c429a87-fbeb-475d-472b-4f23df3716da@oracle.com> References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> <11be7843-a805-5bdd-25ea-8dc30445eb7c@oracle.com> <5b72c1d8-25b8-70b7-cd90-0b02e7827052@oracle.com> <8c429a87-fbeb-475d-472b-4f23df3716da@oracle.com> Message-ID: <47c811c9-b096-ba06-94a7-10c8b8ea173c@oracle.com> Alan, Maurizio, New webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.02/ newJavaNativeInterfaceLibraries? creates a NativeLIbraries for loading JNI native libraries. ? - native libraries are unloaded when the class loader is reclaimed. ? - Support of linking of native method as specified in the JNI spec. ? - Restriction on a native library that can only be loaded by one class loader. newRawNativeLibraries creates? a raw NativeLibraries for loading non-JNI native libraries. ? ? -? non-JNI native library.? So JNI_OnLoad and JNI_OnUnload will be ignored.? No support for linking of native method. ??? - Native libraries not auto-unloaded.? They may be explicitly unloaded via NativeLibraries::unload. ??? - No relationship with class loaders. The test is updated to show that JNI_OnLoad and JNI_OnUnload are ignored. thanks Mandy On 3/18/20 5:39 PM, Mandy Chung wrote: > > > On 3/18/20 12:13 PM, Maurizio Cimadamore wrote: >> >> On 18/03/2020 18:40, Mandy Chung wrote: >>> >>> >>> On 3/18/20 11:16 AM, Maurizio Cimadamore wrote: >>>> So, maybe I'm saying something naive, but isn't the difference >>>> between the two mechanisms mostly there to distinguish between JNI >>>> libraries and non-JNI libraries? >>>> >>> >>> I think such distinction is kind of blurry at the moment. One thing >>> for sure is that JNI native method binding won't happen with the >>> native libraries loaded through this new mechanism. >>> >>> OTOH, should JNI_OnLoad and JNI_Unload be invoked if it is a non-JNI >>> library?? The new mechanism still does.? I expect that this will be >>> cleared up from panama specification. >> Should defo not happen in Panama-loaded libraries > > OK, I will make some adjustment to ignore JNI_OnLoad and JNI_Unload.?? > I think this is a clean distinction of these two mechanisms. > > > Will send an updated webrev later. > >>> >>>> Or are there cases where you envision more mix and match? E.g. JNI >>>> libraries w/o auto-unloading? >>> >>> No as unloading is important for native library loaded by custom >>> loaders. >>> >>> I can't really think of a good static factory method name. >>> >>> would newNonJavaNativeLIbraries be slightly clearer? >> >> newJavaNativeInterfaceLibraries >> >> vs. >> >> newRawNativeLibraries >> > > Both are good to me. > >> could be an option. >> >> Another option, in case we do care about mix and match, would be to >> use a builder - which would allow us to specify whether we want: >> >> * auto-unloading >> * classloader restrictions >> * calling JNI hooks >> * support linking of JNI methods >> >> But I don't think we need such level of granularity for now. >> > > I don't think we need that neither. > > Mandy >> Maurizio >> >>> >>> Mandy >>>> >>>> Maurizio >>>> >>>> On 18/03/2020 16:32, Mandy Chung wrote: >>>>> >>>>> >>>>> On 3/18/20 8:59 AM, Alan Bateman wrote: >>>>>> On 17/03/2020 23:09, Mandy Chung wrote: >>>>>>> >>>>>>> I have similar comment to myself and didn't come up good static >>>>>>> factory method names.?? I give it a try again: what about >>>>>>> newNativeLibraries and newNativeLibrariesWithNoAutoUnload? >>>>>> Would newTrustedNativeLibraries work? Everything else in the >>>>>> updated webrev looks good. >>>>> >>>>> "no auto unload" is also important.? what about >>>>> "newTrustedNativeLibrariesNoAutoUnload" a bit long? >>>>> >>>>> Mandy >>> > From magnus.ihse.bursie at oracle.com Fri Mar 20 11:42:48 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 20 Mar 2020 12:42:48 +0100 Subject: RFR: JDK-8241310 Fix warnings in jdk buildtools In-Reply-To: <1352849480.610522.1584641574288.JavaMail.zimbra@u-pem.fr> References: <99c00548-f01a-dacc-ef41-bab6e4942e09@oracle.com> <1352849480.610522.1584641574288.JavaMail.zimbra@u-pem.fr> Message-ID: <4f22e7ca-994e-8e20-e709-236ee9625d7e@oracle.com> On 2020-03-19 19:12, Remi Forax wrote: > Hi Magnus, > > please try not to use @SuppressWarnings("unchecked") on methods, but on local variable instead to reduce the scope, > you can introduce a local variable for that. Aha, I did not know that possibility existed! (My Java skills is becoming somewhat rusty after spending too much time in the build system.) That's much better, I fully agree. > > In Bundle, your patch declare @SuppressWarnings("unchecked") on the method while you already have a local variable with a @SuppressWarnings("unchecked"). > > Also, usually you don't need @SuppressWarnings("rawtype") apart when you use Object.getClass, otherwise using a wilcard solve the issue. > By example in PluralsParseHandle, > instead of > Entry entry = (Entry)currentContainer; > the code should be > Entry entry = (Entry)currentContainer; Thank you. I'm still struggling with the capturing mechanics. > BTW, in this method, you have an Arrays.stream(array).forEach() which is an antipattern, a simple loop should be used instead. I'm sure the code is full of ugliness; however it is not "my" code -- I'm merely trying to fix the compiler warnings, and I will not do any further cleanups. If I started to walk on that path, there will be no end. Here is an updated webrev. Now I'm down to just four SuppressWarnings, all of them localized, and three of them (in Bundle.java) are modeled after similar patterns in the same function. http://cr.openjdk.java.net/~ihse/JDK-8241310-fix-warnings-in-buildtools/webrev.02 /Magnus > > regards, > R?mi > > ----- Mail original ----- >> De: "Magnus Ihse Bursie" >> ?: "build-dev" , "core-libs-dev" >> Envoy?: Jeudi 19 Mars 2020 17:53:09 >> Objet: RFR: JDK-8241310 Fix warnings in jdk buildtools >> The buildtools (java tools needed to be run during the build) have long >> been plagued by warnings, includuing deprecations and unchecked >> warnings, which cannot be silenced during the build. >> >> This patch fixes all buildtool warnings. Most of the warnings are fixed >> properly, but a few have had their warnings suppressed locally. >> >> For two tools, cldrconverter and tzdb, I gave up to get them fully >> fixed, and instead suppressed warnings in some places. Common for both >> these tools were that they used collections of some kind, with a mixed >> bag of data types (e.g. a Map from String to either String, HashMap, >> ArrayList and String[]). I'm frankly not sure how this could ever have >> worked :-) but I assume that the data files being parsed has a structure >> that "guarantees" that this works. >> >> Two files in generatecharacter were missing a proper copyright header. I >> noticed this when I were about to update the copyright year, and when I >> checked the other files I noted another one without header. While I did >> not need to change this file, I thought it was suitable to fix the >> missing header for both files. >> >> I have verified that the code generated by the build is identical with >> and without this patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241310 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8241310-fix-warnings-in-buildtools/webrev.01 >> >> /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 20 11:46:26 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 20 Mar 2020 12:46:26 +0100 Subject: RFR: JDK-8241310 Fix warnings in jdk buildtools In-Reply-To: References: <99c00548-f01a-dacc-ef41-bab6e4942e09@oracle.com> Message-ID: On 2020-03-19 18:54, Erik Joelsson wrote: > Looks good to me. Thanks. > > I love the WrapperGenerator using Vector and Hashtable! Yeah. State of the art. I'm still trying to wrap my head around this piece of beauty: ??????????????? assert !(currentContainer instanceof Entry); ??????????????? Entry entry = (Entry)currentContainer; ... /Magnus > > /Erik > > On 2020-03-19 09:53, Magnus Ihse Bursie wrote: >> The buildtools (java tools needed to be run during the build) have >> long been plagued by warnings, includuing deprecations and unchecked >> warnings, which cannot be silenced during the build. >> >> This patch fixes all buildtool warnings. Most of the warnings are >> fixed properly, but a few have had their warnings suppressed locally. >> >> For two tools, cldrconverter and tzdb, I gave up to get them fully >> fixed, and instead suppressed warnings in some places. Common for >> both these tools were that they used collections of some kind, with a >> mixed bag of data types (e.g. a Map from String to either String, >> HashMap, ArrayList and String[]). I'm frankly not sure how this could >> ever have worked :-) but I assume that the data files being parsed >> has a structure that "guarantees" that this works. >> >> Two files in generatecharacter were missing a proper copyright >> header. I noticed this when I were about to update the copyright >> year, and when I checked the other files I noted another one without >> header. While I did not need to change this file, I thought it was >> suitable to fix the missing header for both files. >> >> I have verified that the code generated by the build is identical >> with and without this patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241310 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8241310-fix-warnings-in-buildtools/webrev.01 >> >> /Magnus From erik.joelsson at oracle.com Fri Mar 20 13:11:34 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 20 Mar 2020 06:11:34 -0700 Subject: RFR: JDK-8241310 Fix warnings in jdk buildtools In-Reply-To: <4f22e7ca-994e-8e20-e709-236ee9625d7e@oracle.com> References: <99c00548-f01a-dacc-ef41-bab6e4942e09@oracle.com> <1352849480.610522.1584641574288.JavaMail.zimbra@u-pem.fr> <4f22e7ca-994e-8e20-e709-236ee9625d7e@oracle.com> Message-ID: <297f5e98-f8c5-28cb-4c4f-97a943e539a5@oracle.com> Looks even better. /Erik On 2020-03-20 04:42, Magnus Ihse Bursie wrote: > On 2020-03-19 19:12, Remi Forax wrote: >> Hi Magnus, >> >> please try not to use @SuppressWarnings("unchecked") on methods, but >> on local variable instead to reduce the scope, >> you can introduce a local variable for that. > Aha, I did not know that possibility existed! (My Java skills is > becoming somewhat rusty after spending too much time in the build > system.) That's much better, I fully agree. >> >> In Bundle, your patch declare @SuppressWarnings("unchecked") on the >> method while you already have a local variable with a >> @SuppressWarnings("unchecked"). >> >> Also, usually you don't need @SuppressWarnings("rawtype") apart when >> you use Object.getClass, otherwise using a wilcard solve the issue. >> By example in PluralsParseHandle, >> ?? instead of >> ???? Entry entry = (Entry)currentContainer; >> ?? the code should be >> ???? Entry entry = (Entry)currentContainer; > Thank you. I'm still struggling with the capturing mechanics. >> BTW, in this method, you have an Arrays.stream(array).forEach() which >> is an antipattern, a simple loop should be used instead. > I'm sure the code is full of ugliness; however it is not "my" code -- > I'm merely trying to fix the compiler warnings, and I will not do any > further cleanups. If I started to walk on that path, there will be no > end. > > Here is an updated webrev. Now I'm down to just four SuppressWarnings, > all of them localized, and three of them (in Bundle.java) are modeled > after similar patterns in the same function. > > http://cr.openjdk.java.net/~ihse/JDK-8241310-fix-warnings-in-buildtools/webrev.02 > > > /Magnus >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "Magnus Ihse Bursie" >>> ?: "build-dev" , "core-libs-dev" >>> >>> Envoy?: Jeudi 19 Mars 2020 17:53:09 >>> Objet: RFR: JDK-8241310 Fix warnings in jdk buildtools >>> The buildtools (java tools needed to be run during the build) have long >>> been plagued by warnings, includuing deprecations and unchecked >>> warnings, which cannot be silenced during the build. >>> >>> This patch fixes all buildtool warnings. Most of the warnings are fixed >>> properly, but a few have had their warnings suppressed locally. >>> >>> For two tools, cldrconverter and tzdb, I gave up to get them fully >>> fixed, and instead suppressed warnings in some places. Common for both >>> these tools were that they used collections of some kind, with a mixed >>> bag of data types (e.g. a Map from String to either String, HashMap, >>> ArrayList and String[]). I'm frankly not sure how this could ever have >>> worked :-) but I assume that the data files being parsed has a >>> structure >>> that "guarantees" that this works. >>> >>> Two files in generatecharacter were missing a proper copyright >>> header. I >>> noticed this when I were about to update the copyright year, and when I >>> checked the other files I noted another one without header. While I did >>> not need to change this file, I thought it was suitable to fix the >>> missing header for both files. >>> >>> I have verified that the code generated by the build is identical with >>> and without this patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241310 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8241310-fix-warnings-in-buildtools/webrev.01 >>> >>> >>> /Magnus > From Alan.Bateman at oracle.com Fri Mar 20 13:51:53 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Mar 2020 13:51:53 +0000 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: <47c811c9-b096-ba06-94a7-10c8b8ea173c@oracle.com> References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> <11be7843-a805-5bdd-25ea-8dc30445eb7c@oracle.com> <5b72c1d8-25b8-70b7-cd90-0b02e7827052@oracle.com> <8c429a87-fbeb-475d-472b-4f23df3716da@oracle.com> <47c811c9-b096-ba06-94a7-10c8b8ea173c@oracle.com> Message-ID: <2540bb7d-55fa-c65c-9ed3-45e3f498de21@oracle.com> On 20/03/2020 03:43, Mandy Chung wrote: > Alan, Maurizio, > > New webrev: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.02/ > > newJavaNativeInterfaceLibraries? creates a NativeLIbraries for loading > JNI native libraries. > ? - native libraries are unloaded when the class loader is reclaimed. > ? - Support of linking of native method as specified in the JNI spec. > ? - Restriction on a native library that can only be loaded by one > class loader. > > newRawNativeLibraries creates? a raw NativeLibraries for loading > non-JNI native libraries. > ? ? -? non-JNI native library.? So JNI_OnLoad and JNI_OnUnload will be > ignored.? No support for linking of native method. > ??? - Native libraries not auto-unloaded.? They may be explicitly > unloaded via NativeLibraries::unload. > ??? - No relationship with class loaders. > > The test is updated to show that JNI_OnLoad and JNI_OnUnload are ignored. "raw" seems okay for now, its internal so can easily be changed if there is a better name or changed further if finer control on the behavior is needed. If you are looking for a shorter name for the factory methods then maybe jniNativeLibraries and rawNativeLibraries would be better. -Alan From mandy.chung at oracle.com Fri Mar 20 16:17:21 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 Mar 2020 09:17:21 -0700 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: <2540bb7d-55fa-c65c-9ed3-45e3f498de21@oracle.com> References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> <11be7843-a805-5bdd-25ea-8dc30445eb7c@oracle.com> <5b72c1d8-25b8-70b7-cd90-0b02e7827052@oracle.com> <8c429a87-fbeb-475d-472b-4f23df3716da@oracle.com> <47c811c9-b096-ba06-94a7-10c8b8ea173c@oracle.com> <2540bb7d-55fa-c65c-9ed3-45e3f498de21@oracle.com> Message-ID: <90ab9f58-c5ac-89f1-c723-ea3847e0d48c@oracle.com> On 3/20/20 6:51 AM, Alan Bateman wrote: > On 20/03/2020 03:43, Mandy Chung wrote: >> Alan, Maurizio, >> >> New webrev: >> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.02/ >> >> newJavaNativeInterfaceLibraries? creates a NativeLIbraries for >> loading JNI native libraries. >> ? - native libraries are unloaded when the class loader is reclaimed. >> ? - Support of linking of native method as specified in the JNI spec. >> ? - Restriction on a native library that can only be loaded by one >> class loader. >> >> newRawNativeLibraries creates? a raw NativeLibraries for loading >> non-JNI native libraries. >> ? ? -? non-JNI native library.? So JNI_OnLoad and JNI_OnUnload will >> be ignored.? No support for linking of native method. >> ??? - Native libraries not auto-unloaded.? They may be explicitly >> unloaded via NativeLibraries::unload. >> ??? - No relationship with class loaders. >> >> The test is updated to show that JNI_OnLoad and JNI_OnUnload are >> ignored. > "raw" seems okay for now, its internal so can easily be changed if > there is a better name or changed further if finer control on the > behavior is needed. If you are looking for a shorter name for the > factory methods then maybe jniNativeLibraries and rawNativeLibraries > would be better. I like these shorter names. Updated webrev.02 in place. Mandy From naoto.sato at oracle.com Fri Mar 20 16:21:16 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 20 Mar 2020 09:21:16 -0700 Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8241311 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8241311/webrev.04/ This is simply to move some test cases that have been in closed repository into open repository. Naoto From maurizio.cimadamore at oracle.com Fri Mar 20 16:49:41 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 20 Mar 2020 16:49:41 +0000 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: <90ab9f58-c5ac-89f1-c723-ea3847e0d48c@oracle.com> References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> <11be7843-a805-5bdd-25ea-8dc30445eb7c@oracle.com> <5b72c1d8-25b8-70b7-cd90-0b02e7827052@oracle.com> <8c429a87-fbeb-475d-472b-4f23df3716da@oracle.com> <47c811c9-b096-ba06-94a7-10c8b8ea173c@oracle.com> <2540bb7d-55fa-c65c-9ed3-45e3f498de21@oracle.com> <90ab9f58-c5ac-89f1-c723-ea3847e0d48c@oracle.com> Message-ID: Looks good! Thanks! Maurizio On 20/03/2020 16:17, Mandy Chung wrote: > > > On 3/20/20 6:51 AM, Alan Bateman wrote: >> On 20/03/2020 03:43, Mandy Chung wrote: >>> Alan, Maurizio, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.02/ >>> >>> newJavaNativeInterfaceLibraries? creates a NativeLIbraries for >>> loading JNI native libraries. >>> ? - native libraries are unloaded when the class loader is reclaimed. >>> ? - Support of linking of native method as specified in the JNI spec. >>> ? - Restriction on a native library that can only be loaded by one >>> class loader. >>> >>> newRawNativeLibraries creates? a raw NativeLibraries for loading >>> non-JNI native libraries. >>> ? ? -? non-JNI native library.? So JNI_OnLoad and JNI_OnUnload will >>> be ignored.? No support for linking of native method. >>> ??? - Native libraries not auto-unloaded.? They may be explicitly >>> unloaded via NativeLibraries::unload. >>> ??? - No relationship with class loaders. >>> >>> The test is updated to show that JNI_OnLoad and JNI_OnUnload are >>> ignored. >> "raw" seems okay for now, its internal so can easily be changed if >> there is a better name or changed further if finer control on the >> behavior is needed. If you are looking for a shorter name for the >> factory methods then maybe jniNativeLibraries and rawNativeLibraries >> would be better. > > I like these shorter names. > > Updated webrev.02 in place. > > Mandy From paul.sandoz at oracle.com Fri Mar 20 17:16:30 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 Mar 2020 10:16:30 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> Message-ID: <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java @@ -1379,12 +1379,12 @@ /** * This implementation returns {@code true} if {@code obj} is another - * {@code WeakEntry} whose referent is equals to this referent, or - * if {@code obj} is equals to the referent of this. This allows + * {@code WeakEntry} whose referent equals to this referent, or + * if {@code obj} equals to the referent of this. This allows * lookups to be made without wrapping in a {@code WeakEntry}. * * @param obj the object to compare - * @return true if {@code obj} is equals to this or the referent of this + * @return true if {@code obj} equals to this or the referent of this * @see MethodType#equals(Object) * @see Object#equals(Object) Use either: whose referent is equal to this referent, or whose referent equals this referent, The former is easier just delete the ?s?. Other bits look good. Paul. > On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov wrote: > > Hi Pavel! > > Can this please be combined with my collection of typos? > > http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ > > Just to save cycles on reviewing :) > > With kind regards, > > Ivan > > > On 3/13/20 8:42 AM, Pavel Rappo wrote: >> Hello, >> >> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >> >> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >> >> This is a documentation cleanup. There are no code changes involved, >> and the changes in documentation are mostly trivial. >> >> The following packages are affected: >> >> java.lang, >> java.nio.file, >> java.nio.file.attribute, >> java.security, >> java.time.chrono, >> java.time.temporal, >> java.util, >> java.util.regex, >> java.util.stream, >> javax.crypto, >> javax.security.cert, >> javax.tools >> >> That said, there are two changes that I'd prefer to be carefully reviewed by >> the experts in the corresponding areas. >> >> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >> supported for the sake of backward compatibility. Sadly, we have a number of >> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >> should better be verified by the security folk. >> >> The second one is for the doc comment for the java.util.stream.Stream.collect method. >> >> @apiNote >> The following will accumulate strings into an ArrayList: >> >> List asList = stringStream.collect(Collectors.toList()); >> >> Given that the spec for Collectors.toList() clearly says that >> >> ...There are no guarantees on the type, mutability, serializability, or >> thread-safety of the List returned;... >> >> I'd assume that @apiNote should be fixed as proposed. >> >> -Pavel >> >> P.S. Apologies for spamming multiple mailing lists. >> > -- > With kind regards, > Ivan Gerasimov > From paul.sandoz at oracle.com Fri Mar 20 17:22:12 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 Mar 2020 10:22:12 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: <4278B6CA-34D5-4857-A5A7-D885C69CDB9E@oracle.com> +1 Paul. > On Mar 13, 2020, at 8:42 AM, Pavel Rappo wrote: > > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > From jorn.vernee at oracle.com Fri Mar 20 17:49:09 2020 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 20 Mar 2020 18:49:09 +0100 Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable In-Reply-To: <1E26FBB6-172B-4BDD-A286-2C0BB6E5B1CE@oracle.com> References: <1E26FBB6-172B-4BDD-A286-2C0BB6E5B1CE@oracle.com> Message-ID: <90afbea3-ebbb-8da2-605c-6c4393cfc1fa@oracle.com> W.r.t. the source type being needed, I see the following 4 major cases: 1. src=Prim & dst=Prim -> cast convert. For boolean the least-significant-bit is used to convert it to/from an integer type. 2. src=Prim & dst=Ref?? -> box the source value and potentially cast 3. src=Ref?? & dst=Prim -> apply an unboxing conversion if possible and then a casting conversion (with same trick for boolean as (1)) 4. src=Ref?? & dst=Ref?? -> reference cast Without the source type we can't disambiguate between cases (2) and (4), or (1) and (3) because the bootstrap takes Object as an input. For (2) and (4) the bootstrap invocation mechanism takes care of the boxing for us, and the cast is performed by (4). For (1) and (3) the conversion code for the latter handles conversion of wrapper types to Number and then to the target primitive per (1). In the end things seems to work out to the same result (though maybe I'm missing some subtle difference in a failure case). What I'm mostly worried about is that the source type already affects _how_ the conversion is done, and the fact that this difference is not observable seems somewhat incidental.... Coupled with the fact that asType and explicitCastArguments also have access to both the source and destination type, I think maybe the new bootstrap method should as well. After all, what if the set of cases is extended (valhalla?) and/or not being able to disambiguate starts to matter? --- I've written a more in-depth specification for the bootstrap, and re-implemented it using explicitCastArguments, since that helps to catch discrepancies between the input value and the source type. Here is the next iteration: http://cr.openjdk.java.net/~jvernee/8241100/webrev.01 I've kept the source type for now, if it should be removed the specification can be trimmed down (since there would be less cases to specify). As for the name; I think "asType" might be confusing since the applied conversion is not quite the same as MethodHandle::asType. Since the bootstrap is implemented in terms of explicitCastArguments I went with "explicitCast", how is that? Thanks, Jorn From Alan.Bateman at oracle.com Fri Mar 20 18:21:00 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Mar 2020 18:21:00 +0000 Subject: Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading In-Reply-To: <90ab9f58-c5ac-89f1-c723-ea3847e0d48c@oracle.com> References: <6ae16476-a5a3-b1b5-e339-024b83252ebb@oracle.com> <6b044c54-2338-246e-b536-82519e7e04fd@oracle.com> <023f2c19-8788-3244-d12e-2ff0cae27faa@oracle.com> <11be7843-a805-5bdd-25ea-8dc30445eb7c@oracle.com> <5b72c1d8-25b8-70b7-cd90-0b02e7827052@oracle.com> <8c429a87-fbeb-475d-472b-4f23df3716da@oracle.com> <47c811c9-b096-ba06-94a7-10c8b8ea173c@oracle.com> <2540bb7d-55fa-c65c-9ed3-45e3f498de21@oracle.com> <90ab9f58-c5ac-89f1-c723-ea3847e0d48c@oracle.com> Message-ID: On 20/03/2020 16:17, Mandy Chung wrote: > : > > I like these shorter names. > > Updated webrev.02 in place. Looks good. From ivan.gerasimov at oracle.com Fri Mar 20 20:11:57 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 20 Mar 2020 13:11:57 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> Message-ID: Thank you Paul! grep found a few more occurrences of? 'equals to'? across java.base, so I fixed them as well. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/01/webrev/ Pavel, I checked your portion of correction, everything looks good to me! One minor nit:? In src/java.base/share/classes/java/util/StringJoiner.java can you please wrap the modified line, so it won't be that long? With kind regards, Ivan On 3/20/20 10:16 AM, Paul Sandoz wrote: > --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java > +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java > @@ -1379,12 +1379,12 @@ > > /** > * This implementation returns {@code true} if {@code obj} is another > - * {@code WeakEntry} whose referent is equals to this referent, or > - * if {@code obj} is equals to the referent of this. This allows > + * {@code WeakEntry} whose referent equals to this referent, or > + * if {@code obj} equals to the referent of this. This allows > * lookups to be made without wrapping in a {@code WeakEntry}. > * > * @param obj the object to compare > - * @return true if {@code obj} is equals to this or the referent of this > + * @return true if {@code obj} equals to this or the referent of this > * @see MethodType#equals(Object) > * @see Object#equals(Object) > > Use either: > > whose referent is equal to this referent, > > or > > whose referent equals this referent, > > The former is easier just delete the ?s?. > > Other bits look good. > > Paul. > >> On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov wrote: >> >> Hi Pavel! >> >> Can this please be combined with my collection of typos? >> >> http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ >> >> Just to save cycles on reviewing :) >> >> With kind regards, >> >> Ivan >> >> >> On 3/13/20 8:42 AM, Pavel Rappo wrote: >>> Hello, >>> >>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >>> >>> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >>> >>> This is a documentation cleanup. There are no code changes involved, >>> and the changes in documentation are mostly trivial. >>> >>> The following packages are affected: >>> >>> java.lang, >>> java.nio.file, >>> java.nio.file.attribute, >>> java.security, >>> java.time.chrono, >>> java.time.temporal, >>> java.util, >>> java.util.regex, >>> java.util.stream, >>> javax.crypto, >>> javax.security.cert, >>> javax.tools >>> >>> That said, there are two changes that I'd prefer to be carefully reviewed by >>> the experts in the corresponding areas. >>> >>> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >>> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >>> supported for the sake of backward compatibility. Sadly, we have a number of >>> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >>> should better be verified by the security folk. >>> >>> The second one is for the doc comment for the java.util.stream.Stream.collect method. >>> >>> @apiNote >>> The following will accumulate strings into an ArrayList: >>> >>> List asList = stringStream.collect(Collectors.toList()); >>> >>> Given that the spec for Collectors.toList() clearly says that >>> >>> ...There are no guarantees on the type, mutability, serializability, or >>> thread-safety of the List returned;... >>> >>> I'd assume that @apiNote should be fixed as proposed. >>> >>> -Pavel >>> >>> P.S. Apologies for spamming multiple mailing lists. >>> >> -- >> With kind regards, >> Ivan Gerasimov >> -- With kind regards, Ivan Gerasimov From pavel.rappo at oracle.com Fri Mar 20 21:00:29 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 20 Mar 2020 21:00:29 +0000 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> Message-ID: <1EE3B1EB-15AA-4BCC-9A60-37CAC906E244@oracle.com> Thanks Ivan, I merged your changes with mine and pushed the resulting changeset. > On 20 Mar 2020, at 20:11, Ivan Gerasimov wrote: > > Thank you Paul! > > grep found a few more occurrences of 'equals to' across java.base, so I fixed them as well. > > Here's the updated webrev: > > http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/01/webrev/ > > > Pavel, I checked your portion of correction, everything looks good to me! > > One minor nit: In src/java.base/share/classes/java/util/StringJoiner.java can you please wrap the modified line, so it won't be that long? > > > With kind regards, > > Ivan > > > On 3/20/20 10:16 AM, Paul Sandoz wrote: >> --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java >> +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java >> @@ -1379,12 +1379,12 @@ >> /** >> * This implementation returns {@code true} if {@code obj} is another >> - * {@code WeakEntry} whose referent is equals to this referent, or >> - * if {@code obj} is equals to the referent of this. This allows >> + * {@code WeakEntry} whose referent equals to this referent, or >> + * if {@code obj} equals to the referent of this. This allows >> * lookups to be made without wrapping in a {@code WeakEntry}. >> * >> * @param obj the object to compare >> - * @return true if {@code obj} is equals to this or the referent of this >> + * @return true if {@code obj} equals to this or the referent of this >> * @see MethodType#equals(Object) >> * @see Object#equals(Object) >> Use either: >> >> whose referent is equal to this referent, >> >> or >> >> whose referent equals this referent, >> >> The former is easier just delete the ?s?. >> >> Other bits look good. >> >> Paul. >> >>> On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov wrote: >>> >>> Hi Pavel! >>> >>> Can this please be combined with my collection of typos? >>> >>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ >>> >>> Just to save cycles on reviewing :) >>> >>> With kind regards, >>> >>> Ivan >>> >>> >>> On 3/13/20 8:42 AM, Pavel Rappo wrote: >>>> Hello, >>>> >>>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >>>> >>>> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >>>> >>>> This is a documentation cleanup. There are no code changes involved, >>>> and the changes in documentation are mostly trivial. >>>> >>>> The following packages are affected: >>>> >>>> java.lang, >>>> java.nio.file, >>>> java.nio.file.attribute, >>>> java.security, >>>> java.time.chrono, >>>> java.time.temporal, >>>> java.util, >>>> java.util.regex, >>>> java.util.stream, >>>> javax.crypto, >>>> javax.security.cert, >>>> javax.tools >>>> >>>> That said, there are two changes that I'd prefer to be carefully reviewed by >>>> the experts in the corresponding areas. >>>> >>>> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >>>> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >>>> supported for the sake of backward compatibility. Sadly, we have a number of >>>> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >>>> should better be verified by the security folk. >>>> >>>> The second one is for the doc comment for the java.util.stream.Stream.collect method. >>>> >>>> @apiNote >>>> The following will accumulate strings into an ArrayList: >>>> >>>> List asList = stringStream.collect(Collectors.toList()); >>>> >>>> Given that the spec for Collectors.toList() clearly says that >>>> >>>> ...There are no guarantees on the type, mutability, serializability, or >>>> thread-safety of the List returned;... >>>> >>>> I'd assume that @apiNote should be fixed as proposed. >>>> >>>> -Pavel >>>> >>>> P.S. Apologies for spamming multiple mailing lists. >>>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> > -- > With kind regards, > Ivan Gerasimov > From john.r.rose at oracle.com Sat Mar 21 05:08:05 2020 From: john.r.rose at oracle.com (John Rose) Date: Fri, 20 Mar 2020 22:08:05 -0700 Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable In-Reply-To: <90afbea3-ebbb-8da2-605c-6c4393cfc1fa@oracle.com> References: <1E26FBB6-172B-4BDD-A286-2C0BB6E5B1CE@oracle.com> <90afbea3-ebbb-8da2-605c-6c4393cfc1fa@oracle.com> Message-ID: On Mar 20, 2020, at 10:49 AM, Jorn Vernee wrote: > > W.r.t. the source type being needed, I see the following 4 major cases: > > 1. src=Prim & dst=Prim -> cast convert. For boolean the least-significant-bit is used to convert it to/from an integer type. > 2. src=Prim & dst=Ref -> box the source value and potentially cast > 3. src=Ref & dst=Prim -> apply an unboxing conversion if possible and then a casting conversion (with same trick for boolean as (1)) > 4. src=Ref & dst=Ref -> reference cast > > Without the source type we can't disambiguate between cases (2) and (4), or (1) and (3) because the bootstrap takes Object as an input. I think that if you box the src=Prim from 1 or 2 and then hand the resulting src=Ref to 3 or 4 you will get the same thing. The basic design here is that dst=Prim is the key signal that unlocks the primitive conversions. The type of the src (Ref or Prim) doesn?t change the access to the primitive conversions. > For (2) and (4) the bootstrap invocation mechanism takes care of the boxing for us, and the cast is performed by (4). For (1) and (3) the conversion code for the latter handles conversion of wrapper types to Number and then to the target primitive per (1). In the end things seems to work out to the same result (though maybe I'm missing some subtle difference in a failure case). Indeed they do. That?s how I designed it. The upshot is that Object is a reliable carrier even of primitive values, for these APIs. > What I'm mostly worried about is that the source type already affects _how_ the conversion is done, and the fact that this difference is not observable seems somewhat incidental.... Coupled with the fact that asType and explicitCastArguments also have access to both the source and destination type, I think maybe the new bootstrap method should as well. After all, what if the set of cases is extended (valhalla?) and/or not being able to disambiguate starts to matter? You shouldn?t be appealing to an internal function here for designing the semantics. The dual arguments to the internal function are excess information; the shape of that function predates the design decision described above. Instead, appeal to some pseudocode, such as: var id = identity(Object.class); var mt = methodType(dst, Object.class); var conv = explicitCastArguments(id, mt); return conv.invoke(x); I think that will give us all conversions we will need. > > --- > > I've written a more in-depth specification for the bootstrap, and re-implemented it using explicitCastArguments, since that helps to catch discrepancies between the input value and the source type. Here is the next iteration: http://cr.openjdk.java.net/~jvernee/8241100/webrev.01 > > I've kept the source type for now, if it should be removed the specification can be trimmed down (since there would be less cases to specify). > > As for the name; I think "asType" might be confusing since the applied conversion is not quite the same as MethodHandle::asType. Since the bootstrap is implemented in terms of explicitCastArguments I went with "explicitCast", how is that? Yes, I like that name. ? John From ivan.gerasimov at oracle.com Sat Mar 21 07:15:14 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 21 Mar 2020 00:15:14 -0700 Subject: RFR 8237599 : Greedy matching against supplementary chars fails to respect the region In-Reply-To: <88a8bdd6-0791-0539-ff46-cf6441b13f3c@oracle.com> References: <88a8bdd6-0791-0539-ff46-cf6441b13f3c@oracle.com> Message-ID: Gentle ping. The webrev was rebased to accommodate recent changes in RegExTest.java. The fix is to handle an edge case situation, which is supposedly not too common. Nevertheless, I think, it is important to handle it correctly. Thanks in advance! Ivan On 1/22/20 8:23 PM, Ivan Gerasimov wrote: > Hello everyone! > > When the input of a j.u.regex.Matcher is restricted with .region() > method, it can possibly cut off a half of a surrogate pair. > > It turns out that greedy matching implemented in the > Pattern.CharPropertyGreedy class fails to recognize this edge case in > two scenarios: > > 1) When it greedily consumes the input and meets a higher half of a > surrogate pair that was cut off at the end of input, and > > 2) When it backs off and meets a lower half of a surrogate pair at the > very beginning of input. > > In both cases, the engine reads the entire codepoint, crossing the > boundaries of the set region. > > Instead, it should only read the half of the surrogate pair that lies > inside the region and ignore the other half. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8237599 > WEBREV: http://cr.openjdk.java.net/~igerasim/8237599/00/webrev/ > > Thanks in advance! > -- With kind regards, Ivan Gerasimov From jorn.vernee at oracle.com Sat Mar 21 11:56:53 2020 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Sat, 21 Mar 2020 12:56:53 +0100 Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable In-Reply-To: References: <1E26FBB6-172B-4BDD-A286-2C0BB6E5B1CE@oracle.com> <90afbea3-ebbb-8da2-605c-6c4393cfc1fa@oracle.com> Message-ID: <55036db2-3a4d-e7f5-e3cd-efe2b8132e2e@oracle.com> Ok, thanks for explaining this. I hadn't realized the conversions were designed to work without a source type. I've removed the source type in the next revision: http://cr.openjdk.java.net/~jvernee/8241100/webrev.02/ Jorn On 21/03/2020 06:08, John Rose wrote: > On Mar 20, 2020, at 10:49 AM, Jorn Vernee wrote: >> W.r.t. the source type being needed, I see the following 4 major cases: >> >> 1. src=Prim & dst=Prim -> cast convert. For boolean the least-significant-bit is used to convert it to/from an integer type. >> 2. src=Prim & dst=Ref -> box the source value and potentially cast >> 3. src=Ref & dst=Prim -> apply an unboxing conversion if possible and then a casting conversion (with same trick for boolean as (1)) >> 4. src=Ref & dst=Ref -> reference cast >> >> Without the source type we can't disambiguate between cases (2) and (4), or (1) and (3) because the bootstrap takes Object as an input. > I think that if you box the src=Prim from 1 or 2 and then > hand the resulting src=Ref to 3 or 4 you will get the same > thing. The basic design here is that dst=Prim is the key > signal that unlocks the primitive conversions. The type > of the src (Ref or Prim) doesn?t change the access to the > primitive conversions. > >> For (2) and (4) the bootstrap invocation mechanism takes care of the boxing for us, and the cast is performed by (4). For (1) and (3) the conversion code for the latter handles conversion of wrapper types to Number and then to the target primitive per (1). In the end things seems to work out to the same result (though maybe I'm missing some subtle difference in a failure case). > Indeed they do. That?s how I designed it. The upshot is that > Object is a reliable carrier even of primitive values, for these > APIs. > >> What I'm mostly worried about is that the source type already affects _how_ the conversion is done, and the fact that this difference is not observable seems somewhat incidental.... Coupled with the fact that asType and explicitCastArguments also have access to both the source and destination type, I think maybe the new bootstrap method should as well. After all, what if the set of cases is extended (valhalla?) and/or not being able to disambiguate starts to matter? > You shouldn?t be appealing to an internal function here for > designing the semantics. The dual arguments to the internal > function are excess information; the shape of that function > predates the design decision described above. > > Instead, appeal to some pseudocode, such as: > > var id = identity(Object.class); > var mt = methodType(dst, Object.class); > var conv = explicitCastArguments(id, mt); > return conv.invoke(x); > > I think that will give us all conversions we will need. > >> --- >> >> I've written a more in-depth specification for the bootstrap, and re-implemented it using explicitCastArguments, since that helps to catch discrepancies between the input value and the source type. Here is the next iteration: http://cr.openjdk.java.net/~jvernee/8241100/webrev.01 >> >> I've kept the source type for now, if it should be removed the specification can be trimmed down (since there would be less cases to specify). >> >> As for the name; I think "asType" might be confusing since the applied conversion is not quite the same as MethodHandle::asType. Since the bootstrap is implemented in terms of explicitCastArguments I went with "explicitCast", how is that? > Yes, I like that name. > > ? John From philipp.kunz at paratix.ch Sat Mar 21 12:19:32 2020 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sat, 21 Mar 2020 13:19:32 +0100 Subject: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes In-Reply-To: References: <44EE1961-6729-4F96-8885-439FED393A81@oracle.com> <026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch> Message-ID: Hi Naoto and everyone, There are almost as many occurrences of Locale.ROOT as Locale.US which made me wonder which one is more appropriately locale-independent and which is probably another topic and not actually relevant here because BreakIterator.getCharacterInstance is locale-agnostic as far as I can tell. See attached patch with another attempt to fix bug 6202130. Regards, Philipp On Tue, 2020-03-10 at 10:45 -0700, naoto.sato at oracle.com wrote: > Hi Philipp, > > ..., so using BreakIterator (with > Locale.US) is more preferred solution to me. > > Naoto -------------- next part -------------- A non-text attachment was scrubbed... Name: 20200321-bug6202130-manifestutf8.patch Type: text/x-patch Size: 50106 bytes Desc: not available URL: From philipp.kunz at paratix.ch Sat Mar 21 14:58:38 2020 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sat, 21 Mar 2020 15:58:38 +0100 Subject: RFR: 8241055: Regex Grapheme Matcher Performance Depends too much on Total Input Sequence Size Message-ID: <76d3dbae877bf81bf3841fbefe01c4b956832074.camel@paratix.ch> Hi, Any opinions on the attached patch or someone tempted to sponsor it? Regards, Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: 20200321-8241055-graphemebreakcomplexity.patch Type: text/x-patch Size: 16354 bytes Desc: not available URL: From matthias.baesken at sap.com Mon Mar 23 07:44:51 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 23 Mar 2020 07:44:51 +0000 Subject: 8241415: tools/jpackage/share/RuntimePackageTest.java fails because of systemPrefs files Message-ID: Hello, we noticed the following issue in tools/jpackage/share/RuntimePackageTest.java . See also https://bugs.openjdk.java.net/browse/JDK-8241415 . When running a whole jdk jtreg test suite we see failures of the the tools/jpackage/share/RuntimePackageTest.java test. Failures are like this : TRACE: Missing 3 files: TRACE: .systemPrefs TRACE: .systemPrefs/.system.lock TRACE: .systemPrefs/.systemRootModFile TRACE: Done ERROR: Failed: Check there are no missing files in installed image Looking into the jdk under test, we notice the mentioned files were created inside the jdk under test (by previous jtreg tests, this is indicated by the time stamps of those files). my estimation is that some other tests using FileSystemPreferences might created those files. The RuntimePackageTest.java test however does not expect those files in the jdk image under test. Any comments ? Should we check for these files at just delete them at the beginning of tools/jpackage/share/RuntimePackageTest.java (or skip the test in case the files exist) ? Otherwise we might tolerate those 3 files . Any suggestions ? Thanks, Matthias From Alan.Bateman at oracle.com Mon Mar 23 08:10:54 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Mar 2020 08:10:54 +0000 Subject: 8241415: tools/jpackage/share/RuntimePackageTest.java fails because of systemPrefs files In-Reply-To: References: Message-ID: On 23/03/2020 07:44, Baesken, Matthias wrote: > Hello, we noticed the following issue in tools/jpackage/share/RuntimePackageTest.java . > See also https://bugs.openjdk.java.net/browse/JDK-8241415 . > > When running a whole jdk jtreg test suite we see failures of the the tools/jpackage/share/RuntimePackageTest.java test. > Failures are like this : > > TRACE: Missing 3 files: > TRACE: .systemPrefs > TRACE: .systemPrefs/.system.lock > TRACE: .systemPrefs/.systemRootModFile > TRACE: Done > ERROR: Failed: Check there are no missing files in installed image > > Looking into the jdk under test, we notice the mentioned files were created inside the jdk under test > (by previous jtreg tests, this is indicated by the time stamps of those files). > my estimation is that some other tests using FileSystemPreferences might created those files. > The RuntimePackageTest.java test however does not expect those files in the jdk image under test. > > Any comments ? Should we check for these files at just delete them at the beginning of tools/jpackage/share/RuntimePackageTest.java (or skip the test in case the files exist) ? > Otherwise we might tolerate those 3 files . > Tests should never modify the "JDK under test". It should be possible to test a JDK that is on a read-only file system for example. There are a small number of tests that need? edit configuration files and they are supposed to replicate the JDK to another location so it doesn't interfere with other tests running at the same time or later. For the prefs API, there are system properties (java.util.prefs.systemRoot and java.util.prefs.userRoot) to configure where the system and user prefs are stored. There were several issues in the past with userRoot and I think all those tests were fixed to run the tests with the system property set. We might have to do a similar exercise for the systemRoot. -Alan From takiguc at linux.vnet.ibm.com Mon Mar 23 12:48:21 2020 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 23 Mar 2020 21:48:21 +0900 Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open In-Reply-To: References: Message-ID: <240d73307297109f271fdd325ad057f9@linux.vnet.ibm.com> Hello Naoto. I'm not reviewer, but I have a concern about following code on test/jdk/sun/nio/cs/mapping/TestConv.java ====== 98 } catch (Exception ex) { 99 System.out.println("Exception thrown while testing " + encoding); 100 ex.printStackTrace(); 101 return; 102 } ====== 3 stack trace (java.io.UnsupportedEncodingException) were displayed against following encodings: MS50221_0208, MS50221_0212, MS932_0208 I think only UnsupportedEncodingException should be caught. The other exception should be handled as error. What do you think ? Thanks, Ichiroh Takiguchi On 2020-03-21 01:21, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8241311 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8241311/webrev.04/ > > This is simply to move some test cases that have been in closed > repository into open repository. > > Naoto From matthias.baesken at sap.com Mon Mar 23 13:20:38 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 23 Mar 2020 13:20:38 +0000 Subject: 8241415: tools/jpackage/share/RuntimePackageTest.java fails because of systemPrefs files In-Reply-To: References: Message-ID: Hi Alan, >Tests should never modify the "JDK under test". That was my assumption too. >It should be possible to >test a JDK that is on a read-only file system for example. There are a >small number of tests that need? edit configuration files and they are >supposed to replicate the JDK to another location so it doesn't >interfere with other tests running at the same time or later. For the >prefs API, there are system properties (java.util.prefs.systemRoot and >java.util.prefs.userRoot) to configure where the system and user prefs >are stored. There were several issues in the past with userRoot and I >think all those tests were fixed to run the tests with the system >property set. We might have to do a similar exercise for the systemRoot. Hopefully we can identify the "bad guys" in the test set without too much effort ?? ! Best regards, Matthias From shade at redhat.com Mon Mar 23 14:02:02 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 23 Mar 2020 15:02:02 +0100 Subject: RFR (XS/T) 8241445: Fix copyrights after JDK-8240629 change Message-ID: This change in JDK-8240629 was not correct and slipped the review? https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2#l2.5 Also, other file has not updated the copyright line. Fix: diff -r 35ff74547c64 src/java.base/share/native/libjli/args.c --- a/src/java.base/share/native/libjli/args.c Mon Mar 23 14:10:58 2020 +0100 +++ b/src/java.base/share/native/libjli/args.c Mon Mar 23 15:00:46 2020 +0100 @@ -1,4 +1,4 @@ /* - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * diff -r 35ff74547c64 test/jdk/tools/launcher/ArgFileSyntax.java --- a/test/jdk/tools/launcher/ArgFileSyntax.java Mon Mar 23 14:10:58 2020 +0100 +++ b/test/jdk/tools/launcher/ArgFileSyntax.java Mon Mar 23 15:00:46 2020 +0100 @@ -1,4 +1,4 @@ /* - * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * Testing: none. -- Thanks, -Aleksey From Alan.Bateman at oracle.com Mon Mar 23 14:13:27 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Mar 2020 14:13:27 +0000 Subject: 8241415: tools/jpackage/share/RuntimePackageTest.java fails because of systemPrefs files In-Reply-To: References: Message-ID: On 23/03/2020 13:20, Baesken, Matthias wrote: > : > Hopefully we can identify the "bad guys" in the test set without too much effort ?? ! > It would be to put the JDK on read-only file system and see if any tests fail. As to the "bad guys", the tests in test/jdk/java/util/prefs would be good place to start. -Alan From naoto.sato at oracle.com Mon Mar 23 16:05:18 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 23 Mar 2020 09:05:18 -0700 Subject: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes In-Reply-To: References: <44EE1961-6729-4F96-8885-439FED393A81@oracle.com> <026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch> Message-ID: <10485888-3ac8-c967-0131-08fe52d2694d@oracle.com> Hi Philipp, Right, Locale.ROOT is more appropriate here by definition, though the implementation is the same. Naoto On 3/21/20 5:19 AM, Philipp Kunz wrote: > Hi Naoto and everyone, > > There are almost as many occurrences of Locale.ROOT as Locale.US which > made me wonder which one is more appropriately locale-independent and > which is probably another topic and not actually relevant here because > BreakIterator.getCharacterInstance is locale-agnostic as far as I can tell. > > See attached patch with another attempt to fix bug 6202130. > > Regards, > Philipp > > > On Tue, 2020-03-10 at 10:45 -0700, naoto.sato at oracle.com wrote: >> Hi Philipp, >> >> ..., so using BreakIterator (with >> Locale.US) is more preferred solution to me. >> >> Naoto > From naoto.sato at oracle.com Mon Mar 23 16:07:16 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 23 Mar 2020 09:07:16 -0700 Subject: RFR: 8241055: Regex Grapheme Matcher Performance Depends too much on Total Input Sequence Size In-Reply-To: <76d3dbae877bf81bf3841fbefe01c4b956832074.camel@paratix.ch> References: <76d3dbae877bf81bf3841fbefe01c4b956832074.camel@paratix.ch> Message-ID: I am planning to work on it. Naoto On 3/21/20 7:58 AM, Philipp Kunz wrote: > Hi, > > Any opinions on the attached patch or someone tempted to sponsor it? > > Regards, > Philipp From adinn at redhat.com Mon Mar 23 17:56:50 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 23 Mar 2020 17:56:50 +0000 Subject: RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode Message-ID: <2763b3c6-6305-46be-5223-c0a0e47c9359@redhat.com> Could I please have a review for this trivial fix to the module make file which ensures that javadoc is generated for new module jdk.nio.mapmode created as part of the implementation of JEP 352. The original patch added the module to the BOOT_MODULES list but was not to the DOCS_MODULES list. JIRA: https://bugs.openjdk.java.net/browse/JDK-8241144 webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev Testing: Built image and compiled + ran Hello World. Built make target docs-jdk-api-javadoc and checked module jdk.nio.mapmode was included in output regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From martin.doerr at sap.com Mon Mar 23 18:07:02 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 23 Mar 2020 18:07:02 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") Message-ID: Hi, I'd like to backport JDK-8223326 from jdk/jdk. 11u backport issue: https://bugs.openjdk.java.net/browse/JDK-8241460 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc 11u backport webrev: http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/ I had to integrate the change manually due to context changes. However, the new code fits to the 11u versions. Please review. Best regards, Martin From hohensee at amazon.com Mon Mar 23 18:28:34 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 23 Mar 2020 18:28:34 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") Message-ID: <16C954D4-75BC-4296-ACAF-66ACB8B7716D@amazon.com> The changeset references JDK-8223326, which is private. If possible, ask Oracle to make it public so we can do a normal backport rather than file an 11u-specific issue. The backport itself looks fine. Thanks, Paul ?On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin" wrote: Hi, I'd like to backport JDK-8223326 from jdk/jdk. 11u backport issue: https://bugs.openjdk.java.net/browse/JDK-8241460 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc 11u backport webrev: http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/ I had to integrate the change manually due to context changes. However, the new code fits to the 11u versions. Please review. Best regards, Martin From martin.doerr at sap.com Mon Mar 23 18:32:56 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 23 Mar 2020 18:32:56 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: <16C954D4-75BC-4296-ACAF-66ACB8B7716D@amazon.com> References: <16C954D4-75BC-4296-ACAF-66ACB8B7716D@amazon.com> Message-ID: Hi Paul, thanks for the review. We had already asked, but this one can't get opened up. I would have preferred a normal backport, too. Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Montag, 23. M?rz 2020 19:29 > To: Doerr, Martin ; core-libs- > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync: > java.security.AccessControlException: access denied > ("java.net.NetPermission" "setSocketImpl") > > The changeset references JDK-8223326, which is private. If possible, ask > Oracle to make it public so we can do a normal backport rather than file an > 11u-specific issue. The backport itself looks fine. > > Thanks, > Paul > > ?On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin" updates-dev-bounces at openjdk.java.net on behalf of > martin.doerr at sap.com> wrote: > > > Hi, > > I'd like to backport JDK-8223326 from jdk/jdk. > > 11u backport issue: > https://bugs.openjdk.java.net/browse/JDK-8241460 > > Original change: > https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc > > 11u backport webrev: > > http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/ > > I had to integrate the change manually due to context changes. However, > the new code fits to the 11u versions. > > Please review. > > Best regards, > Martin > > From erik.joelsson at oracle.com Mon Mar 23 18:38:29 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Mar 2020 11:38:29 -0700 Subject: RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode In-Reply-To: <2763b3c6-6305-46be-5223-c0a0e47c9359@redhat.com> References: <2763b3c6-6305-46be-5223-c0a0e47c9359@redhat.com> Message-ID: Looks good. /Erik On 2020-03-23 10:56, Andrew Dinn wrote: > Could I please have a review for this trivial fix to the module make > file which ensures that javadoc is generated for new module > jdk.nio.mapmode created as part of the implementation of JEP 352. The > original patch added the module to the BOOT_MODULES list but was not to > the DOCS_MODULES list. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8241144 > webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev > > Testing: > > Built image and compiled + ran Hello World. > > Built make target docs-jdk-api-javadoc and checked module > jdk.nio.mapmode was included in output > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From magnus.ihse.bursie at oracle.com Mon Mar 23 19:03:26 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 23 Mar 2020 20:03:26 +0100 Subject: RFR: JDK-8241463 Move build tools to respective modules Message-ID: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so anymore. Instead, the build tools source code should move the the module that needs them. For instance, compilefontconfig should move to java.desktop, etc. There are multiple reasons for this: * Currently we build *all* build tools at once, which mean that we cannot compile java.base until e.g. the compilefontconfig tool is compiled, even though it is not needed. * If a build tool, e.g. compilefontconfig is modified, all build tools are recompiled, which triggers a rebuild of more or less the entire JDK. This makes development of the build tools unnecessary tedious. * When the build tools are modified, the group owning the corresponding module is the proper review instance, not the build team. But since they reside under "make", the review mails often include build-dev, but this is mostly noise for us. With this move, the ownership is made clear. In this patch, I have not modified how and when the build tools are compiled, but this shuffle is the prerequisite for continuing with that in a follow-up patch. I have also moved the build tools to the org.openjdk.buildtools.* package name space (inspired by Skara), instead of the strangely named build.tools.* name space. A few build tools are not moved in this patch. Two of them, charsetmapping and cldrconverter, are shared between two modules. (I think they should move to modules nevertheless, but they need some more thought to make sure I do this right.) The rest are tools that are needed for the build in general, like linking or javadoc support. I'll move this to a better location too, but in a separate patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 /Magnus From Alan.Bateman at oracle.com Mon Mar 23 19:18:43 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Mar 2020 19:18:43 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: References: Message-ID: <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com> On 23/03/2020 18:07, Doerr, Martin wrote: > Hi, > > I'd like to backport JDK-8223326 from jdk/jdk. > > 11u backport issue: > https://bugs.openjdk.java.net/browse/JDK-8241460 > > Original change: > https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc > > 11u backport webrev: > http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/ > > I had to integrate the change manually due to context changes. However, the new code fits to the 11u versions. > > Please review. > Socket(SocketImpl) is only specified to do a permission check when the impl is non-null. The socket adaptor in JDK 12 and older releases doesn't have a dummy impl so the change should not be needed. If there is a security exception thrownhere then it suggests something may be broken elsewhere, do you have a stack trace? -Alan From shade at redhat.com Mon Mar 23 19:22:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 23 Mar 2020 20:22:34 +0100 Subject: RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays Message-ID: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8241462 In some of my testing pipelines that deal with huge .so-s due to specific build configuration, tests that use the StripNativeDebugSymbols plugin fail with OOME. It can be fixed by using the method that copies the InputStream straight to destination file without instantiating the huge array. The only wrinkle is that we need to close the InputStream after we are done. diff -r c456587e7ef4 src/jdk.jlink/linux/classes/jdk/tools/jlink/internal/plugins/StripNativeDebugSymbolsPlugin.java --- a/src/jdk.jlink/linux/classes/jdk/tools/jlink/internal/plugins/StripNativeDebugSymbolsPlugin.java Mon Mar 23 19:14:01 2020 +0100 +++ b/src/jdk.jlink/linux/classes/jdk/tools/jlink/internal/plugins/StripNativeDebugSymbolsPlugin.java Mon Mar 23 20:13:15 2020 +0100 @@ -1,4 +1,4 @@ /* - * Copyright (c) 2019, Red Hat, Inc. + * Copyright (c) 2019, 2020, Red Hat, Inc. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * @@ -25,4 +25,5 @@ package jdk.tools.jlink.internal.plugins; +import java.io.InputStream; import java.io.IOException; import java.lang.ProcessBuilder.Redirect; @@ -314,5 +315,8 @@ String relativeDbgFileName = relativeFileName + "." + debugExt; - Files.write(resourceFileBinary, resource.contentBytes()); + try (InputStream in = resource.content()) { + Files.copy(in, resourceFileBinary); + } + Path resourceFileDebugSymbols; if (includeDebug) { Testing: tools/jlink, tools/jpackage, jdk-submit (running) -- Thanks, -Aleksey From chris.hegarty at oracle.com Mon Mar 23 19:39:56 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 Mar 2020 19:39:56 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com> References: <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com> Message-ID: <32493F42-5A85-40DE-A151-018C63FF753E@oracle.com> > On 23 Mar 2020, at 19:18, Alan Bateman wrote: > >> ... >> > Socket(SocketImpl) is only specified to do a permission check when the impl is non-null. The socket adaptor in JDK 12 and older releases doesn't have a dummy impl so the change should not be needed. If there is a security exception thrownhere then it suggests something may be broken elsewhere, do you have a stack trace? I suspect that only the ServerSocketAdapter part of the change is needed, since ServerSocket(SocketImpl) does a security check regardless of the value of the given SocketImpl. -Chris. From Alan.Bateman at oracle.com Mon Mar 23 19:44:56 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Mar 2020 19:44:56 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: References: Message-ID: On 23/03/2020 18:07, Doerr, Martin wrote: > Hi, > > I'd like to backport JDK-8223326 from jdk/jdk. > One other thing on this. It looks like the spec changes that were part of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by mistake. Is that part of the issue that you are trying to fix? -Alan From Alan.Bateman at oracle.com Mon Mar 23 19:51:34 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Mar 2020 19:51:34 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: <32493F42-5A85-40DE-A151-018C63FF753E@oracle.com> References: <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com> <32493F42-5A85-40DE-A151-018C63FF753E@oracle.com> Message-ID: <08eb5aec-9508-69c5-5661-c4c91fce5b78@oracle.com> On 23/03/2020 19:39, Chris Hegarty wrote: > >> On 23 Mar 2020, at 19:18, Alan Bateman > > wrote: >> >>> ... >>> >> Socket(SocketImpl) is only specified to do a permission check when >> the impl is non-null. The socket adaptor in JDK 12 and older releases >> doesn't have a dummy impl so the change should not be needed. If >> there is a security exception thrownhere then it suggests something >> may be broken elsewhere, do you have a stack trace? > > I suspect that only the ServerSocketAdapter part of the change is > needed, since ServerSocket(SocketImpl) does a security check > regardless of the value of the given SocketImpl. > The old ServerSocketAdapter implementation pre-dates that protected constructor. I don't have cycles to dig into what is going on in the update releases but if there is a security exception bring thrown in either case then it suggests that something is broken elsewhere. -Alan From erik.joelsson at oracle.com Mon Mar 23 19:54:44 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Mar 2020 12:54:44 -0700 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: References: Message-ID: <705f74a1-8f64-166c-63d1-7174c89443cd@oracle.com> Looks good. /Erik On 2020-03-23 12:03, Magnus Ihse Bursie wrote: > The build tools (small java tools that are run during the build to > generate source code, or data, needed in the JDK) have historically > been placed in the "make" directory. This maybe made sense long time > ago, but does not do so anymore. > > Instead, the build tools source code should move the the module that > needs them. For instance, compilefontconfig should move to > java.desktop, etc. > > There are multiple reasons for this: > > * Currently we build *all* build tools at once, which mean that we > cannot compile java.base until e.g. the compilefontconfig tool is > compiled, even though it is not needed. > > * If a build tool, e.g. compilefontconfig is modified, all build tools > are recompiled, which triggers a rebuild of more or less the entire > JDK. This makes development of the build tools unnecessary tedious. > > * When the build tools are modified, the group owning the > corresponding module is the proper review instance, not the build > team. But since they reside under "make", the review mails often > include build-dev, but this is mostly noise for us. With this move, > the ownership is made clear. > > In this patch, I have not modified how and when the build tools are > compiled, but this shuffle is the prerequisite for continuing with > that in a follow-up patch. > > I have also moved the build tools to the org.openjdk.buildtools.* > package name space (inspired by Skara), instead of the strangely named > build.tools.* name space. > > A few build tools are not moved in this patch. Two of them, > charsetmapping and cldrconverter, are shared between two modules. (I > think they should move to modules nevertheless, but they need some > more thought to make sure I do this right.) The rest are tools that > are needed for the build in general, like linking or javadoc support. > I'll move this to a better location too, but in a separate patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 > > /Magnus > From mandy.chung at oracle.com Mon Mar 23 20:19:13 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Mar 2020 13:19:13 -0700 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: References: Message-ID: <53d7119b-5e7e-22fe-97c1-0382f2d94fbc@oracle.com> Hi Magnus, Modularizing the build tools is a good move.??? This patch suggests to place the build tools under ??? src/$MODULE/share/tools/$PACKAGE/*.java I think the modular source location of the build tools needs more discussion, including jigsaw-dev for this discussion. The JDK source as specified in JEP 201 is under: ??? src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java Compiling the source files from the `src` directory are the intermediate input to build the resulting image.??? Build tools are used to generate additional intermediate input (that is not part of the `src` directory) to build the image.?? So I wonder if make/$MODULE/share/tools or make/tools/$MODULE? may be better location for the build tools. Mandy On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote: > The build tools (small java tools that are run during the build to > generate source code, or data, needed in the JDK) have historically > been placed in the "make" directory. This maybe made sense long time > ago, but does not do so anymore. > > Instead, the build tools source code should move the the module that > needs them. For instance, compilefontconfig should move to > java.desktop, etc. > > There are multiple reasons for this: > > * Currently we build *all* build tools at once, which mean that we > cannot compile java.base until e.g. the compilefontconfig tool is > compiled, even though it is not needed. > > * If a build tool, e.g. compilefontconfig is modified, all build tools > are recompiled, which triggers a rebuild of more or less the entire > JDK. This makes development of the build tools unnecessary tedious. > > * When the build tools are modified, the group owning the > corresponding module is the proper review instance, not the build > team. But since they reside under "make", the review mails often > include build-dev, but this is mostly noise for us. With this move, > the ownership is made clear. > > In this patch, I have not modified how and when the build tools are > compiled, but this shuffle is the prerequisite for continuing with > that in a follow-up patch. > > I have also moved the build tools to the org.openjdk.buildtools.* > package name space (inspired by Skara), instead of the strangely named > build.tools.* name space. > > A few build tools are not moved in this patch. Two of them, > charsetmapping and cldrconverter, are shared between two modules. (I > think they should move to modules nevertheless, but they need some > more thought to make sure I do this right.) The rest are tools that > are needed for the build in general, like linking or javadoc support. > I'll move this to a better location too, but in a separate patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 > > /Magnus > From Alan.Bateman at oracle.com Mon Mar 23 20:33:50 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Mar 2020 20:33:50 +0000 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: References: Message-ID: <20158b4b-f6f1-92e1-59da-d0f6c07a85ca@oracle.com> On 23/03/2020 19:03, Magnus Ihse Bursie wrote: > The build tools (small java tools that are run during the build to > generate source code, or data, needed in the JDK) have historically > been placed in the "make" directory. This maybe made sense long time > ago, but does not do so anymore. > > Instead, the build tools source code should move the the module that > needs them. For instance, compilefontconfig should move to > java.desktop, etc. > > There are multiple reasons for this: > > * Currently we build *all* build tools at once, which mean that we > cannot compile java.base until e.g. the compilefontconfig tool is > compiled, even though it is not needed. > > * If a build tool, e.g. compilefontconfig is modified, all build tools > are recompiled, which triggers a rebuild of more or less the entire > JDK. This makes development of the build tools unnecessary tedious. > > * When the build tools are modified, the group owning the > corresponding module is the proper review instance, not the build > team. But since they reside under "make", the review mails often > include build-dev, but this is mostly noise for us. With this move, > the ownership is made clear. > > In this patch, I have not modified how and when the build tools are > compiled, but this shuffle is the prerequisite for continuing with > that in a follow-up patch. > > I have also moved the build tools to the org.openjdk.buildtools.* > package name space (inspired by Skara), instead of the strangely named > build.tools.* name space. > > A few build tools are not moved in this patch. Two of them, > charsetmapping and cldrconverter, are shared between two modules. (I > think they should move to modules nevertheless, but they need some > more thought to make sure I do this right.) The rest are tools that > are needed for the build in general, like linking or javadoc support. > I'll move this to a better location too, but in a separate patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 I think this will require further discussion, maybe even an update to JEP 201. I think it would be useful to see what other options were exploring, in particular options that organize the tools by module in the make tree (as it will confuse people to put them in the src tree). -Alan From Alan.Bateman at oracle.com Mon Mar 23 20:35:52 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Mar 2020 20:35:52 +0000 Subject: RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays In-Reply-To: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> References: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> Message-ID: On 23/03/2020 19:22, Aleksey Shipilev wrote: > : > > +import java.io.InputStream; > import java.io.IOException; > import java.lang.ProcessBuilder.Redirect; > @@ -314,5 +315,8 @@ > String relativeDbgFileName = relativeFileName + "." + debugExt; > > - Files.write(resourceFileBinary, resource.contentBytes()); > + try (InputStream in = resource.content()) { > + Files.copy(in, resourceFileBinary); > + } > + > Path resourceFileDebugSymbols; > if (includeDebug) { > This looks okay. -Alan. From naoto.sato at oracle.com Mon Mar 23 22:15:31 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 23 Mar 2020 15:15:31 -0700 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: References: Message-ID: Hi Magnus, I looked at i18n related changes: make/CopyInterimTZDB.gmk make/ToolsJdk.gmk make/gendata/Gendata-java.base.gmk make/gendata/GendataBreakIterator.gmk make/gendata/GendataTZDB.gmk make/gensrc/GensrcCharacterData.gmk make/gensrc/GensrcEmojiData.gmk They look ok to me. The *.java changes should have copyright year update. As to charsetmapping and cldrconverter, I believe they can reside in java.base, as jdk.charsets and jdk.localedata modules depend on it. Naoto On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote: > The build tools (small java tools that are run during the build to > generate source code, or data, needed in the JDK) have historically been > placed in the "make" directory. This maybe made sense long time ago, but > does not do so anymore. > > Instead, the build tools source code should move the the module that > needs them. For instance, compilefontconfig should move to java.desktop, > etc. > > There are multiple reasons for this: > > * Currently we build *all* build tools at once, which mean that we > cannot compile java.base until e.g. the compilefontconfig tool is > compiled, even though it is not needed. > > * If a build tool, e.g. compilefontconfig is modified, all build tools > are recompiled, which triggers a rebuild of more or less the entire JDK. > This makes development of the build tools unnecessary tedious. > > * When the build tools are modified, the group owning the corresponding > module is the proper review instance, not the build team. But since they > reside under "make", the review mails often include build-dev, but this > is mostly noise for us. With this move, the ownership is made clear. > > In this patch, I have not modified how and when the build tools are > compiled, but this shuffle is the prerequisite for continuing with that > in a follow-up patch. > > I have also moved the build tools to the org.openjdk.buildtools.* > package name space (inspired by Skara), instead of the strangely named > build.tools.* name space. > > A few build tools are not moved in this patch. Two of them, > charsetmapping and cldrconverter, are shared between two modules. (I > think they should move to modules nevertheless, but they need some more > thought to make sure I do this right.) The rest are tools that are > needed for the build in general, like linking or javadoc support. I'll > move this to a better location too, but in a separate patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 > > > /Magnus > From naoto.sato at oracle.com Tue Mar 24 01:06:13 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 23 Mar 2020 18:06:13 -0700 Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open In-Reply-To: <240d73307297109f271fdd325ad057f9@linux.vnet.ibm.com> References: <240d73307297109f271fdd325ad057f9@linux.vnet.ibm.com> Message-ID: <212756ea-a1a5-2e5a-4b05-0e50f8e61ac5@oracle.com> Hi Takiguchi-san, On 3/23/20 5:48 AM, Ichiroh Takiguchi wrote: > Hello Naoto. > > I'm not reviewer, but I have a concern about following code > on test/jdk/sun/nio/cs/mapping/TestConv.java > ====== > ?98???????????? } catch (Exception ex) { > ?99???????????????? System.out.println("Exception thrown while testing > " + encoding); > 100???????????????? ex.printStackTrace(); > 101???????????????? return; > 102???????????? } > ====== > > 3 stack trace (java.io.UnsupportedEncodingException) were displayed > against following encodings: > ? MS50221_0208, MS50221_0212, MS932_0208 > > I think only UnsupportedEncodingException should be caught. > The other exception should be handled as error. > > What do you think ? Good catch. I believe the test logic that assumes the file name is the charset name is simply wrong. I added the check whether the input charset name is supported or not, and only do the test if the charset is supported: http://cr.openjdk.java.net/~naoto/8241311/webrev.05/ Naoto > > Thanks, > Ichiroh Takiguchi > > On 2020-03-21 01:21, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8241311 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8241311/webrev.04/ >> >> This is simply to move some test cases that have been in closed >> repository into open repository. >> >> Naoto From amaembo at gmail.com Tue Mar 24 02:40:36 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 24 Mar 2020 09:40:36 +0700 Subject: [PING] RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap Message-ID: Hello! A gentle reminder to review the specialized implementation of TreeMap methods. The latest webrev is here: http://cr.openjdk.java.net/~tvaleev/webrev/8176894/r4/ Issue: https://bugs.openjdk.java.net/browse/JDK-8176894 CSR is already approved (thanks to Joe Darcy and Stuart Marks): https://bugs.openjdk.java.net/browse/JDK-8227666 So only code review is necessary. Also, no sponsorship is necessary. Here's the previous discussion http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-October/062859.html Here's benchmarking results http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-February/064901.html Let's push it into Java 15! With best regards, Tagir Valeev. From amy.lu at oracle.com Tue Mar 24 02:43:31 2020 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 24 Mar 2020 10:43:31 +0800 Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open In-Reply-To: References: Message-ID: <1c0ce959-a9b4-03e3-da33-4b05754a96f4@oracle.com> Hi, Naoto CoderTest.java TestConv.java Should they also include @modules jdk.charsets ? Thanks, Amy On 3/21/20 12:21 AM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8241311 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8241311/webrev.04/ > > This is simply to move some test cases that have been in closed > repository into open repository. > > Naoto From naoto.sato at oracle.com Tue Mar 24 04:19:47 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 23 Mar 2020 21:19:47 -0700 Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open In-Reply-To: <1c0ce959-a9b4-03e3-da33-4b05754a96f4@oracle.com> References: <1c0ce959-a9b4-03e3-da33-4b05754a96f4@oracle.com> Message-ID: Hi Amy, Good point. Updated. https://cr.openjdk.java.net/~naoto/8241311/webrev.06/ Naoto On 3/23/20 7:43 PM, Amy Lu wrote: > Hi, Naoto > > CoderTest.java TestConv.java > Should they also include @modules jdk.charsets ? > > Thanks, > Amy > > On 3/21/20 12:21 AM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8241311 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8241311/webrev.04/ >> >> This is simply to move some test cases that have been in closed >> repository into open repository. >> >> Naoto > From amy.lu at oracle.com Tue Mar 24 04:45:47 2020 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 24 Mar 2020 12:45:47 +0800 Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open In-Reply-To: References: <1c0ce959-a9b4-03e3-da33-4b05754a96f4@oracle.com> Message-ID: <9558e95b-d092-f767-d77b-8aa410301867@oracle.com> Thank you Naoto for the quick update. Just more findings ...(sorry for not sending earlier) CoderTest.java Looks like this test has already been migrated (with enhancement) to the 'open' [1] in JDK-8186801 [2] [3]. I'm not sure whether the data files that used by TestCharsetMapping.java can be leveraged by other two tests, but worth checking. Thanks, Amy [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/sun/nio/cs/TestCharsetMapping.java [2] https://bugs.openjdk.java.net/browse/JDK-8186801 [3] https://mail.openjdk.java.net/pipermail/nio-dev/2017-August/004427.html On 3/24/20 12:19 PM, naoto.sato at oracle.com wrote: > Hi Amy, > > Good point. Updated. > > https://cr.openjdk.java.net/~naoto/8241311/webrev.06/ > > Naoto > > On 3/23/20 7:43 PM, Amy Lu wrote: >> Hi, Naoto >> >> CoderTest.java TestConv.java >> Should they also include @modules jdk.charsets ? >> >> Thanks, >> Amy >> >> On 3/21/20 12:21 AM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8241311 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8241311/webrev.04/ >>> >>> This is simply to move some test cases that have been in closed >>> repository into open repository. >>> >>> Naoto >> From christoph.langer at sap.com Tue Mar 24 06:28:22 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Mar 2020 06:28:22 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: <16C954D4-75BC-4296-ACAF-66ACB8B7716D@amazon.com> References: <16C954D4-75BC-4296-ACAF-66ACB8B7716D@amazon.com> Message-ID: Hi Paul, as Martin said, the original bug could not be opened by Oracle. I, however changed the bug created by Martin to a Backport item. Doing it that way would allow a "standard" backport of such type of issues while the original item that was pushed to head can remain invisible. We proceeded like that with other bugs already and it proved to work nicely. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Hohensee, Paul > Sent: Montag, 23. M?rz 2020 19:29 > To: Doerr, Martin ; core-libs- > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync: > java.security.AccessControlException: access denied > ("java.net.NetPermission" "setSocketImpl") > > The changeset references JDK-8223326, which is private. If possible, ask > Oracle to make it public so we can do a normal backport rather than file an > 11u-specific issue. The backport itself looks fine. > > Thanks, > Paul > > ?On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin" updates-dev-bounces at openjdk.java.net on behalf of > martin.doerr at sap.com> wrote: > > > Hi, > > I'd like to backport JDK-8223326 from jdk/jdk. > > 11u backport issue: > https://bugs.openjdk.java.net/browse/JDK-8241460 > > Original change: > https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc > > 11u backport webrev: > > http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/ > > I had to integrate the change manually due to context changes. However, > the new code fits to the 11u versions. > > Please review. > > Best regards, > Martin > > From christoph.langer at sap.com Tue Mar 24 06:39:57 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Mar 2020 06:39:57 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com> References: <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com> Message-ID: Hi Alan, > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Alan Bateman > Sent: Montag, 23. M?rz 2020 20:19 > To: Doerr, Martin ; core-libs- > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR(S): 8223326: Regression introduced by CPU sync: > java.security.AccessControlException: access denied > ("java.net.NetPermission" "setSocketImpl") > > On 23/03/2020 18:07, Doerr, Martin wrote: > > Hi, > > > > I'd like to backport JDK-8223326 from jdk/jdk. > > > > 11u backport issue: > > https://bugs.openjdk.java.net/browse/JDK-8241460 > > > > Original change: > > https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc > > > > 11u backport webrev: > > http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/ > > > > I had to integrate the change manually due to context changes. However, > the new code fits to the 11u versions. > > > > Please review. > > > Socket(SocketImpl) is only specified to do a permission check when the > impl is non-null. The socket adaptor in JDK 12 and older releases > doesn't have a dummy impl so the change should not be needed. If there > is a security exception thrownhere then it suggests something may be > broken elsewhere, do you have a stack trace? I think you are completely right, that change is not required for 11u as it stands. ServerSocketAdaptor::create in 11u would never enter a path that does a permission check and for SocketAdaptor:create the Socket constructor is called with a null impl, so checkPermission(null) will immediately return null. We also don't have an indication that something is broken. My team is just doing an exercise to go through private JBS bugs that have been resolved in jdk/jdk after JDK11 was released and tries to asses which ones should/need to go into OpenJDK 11 updates, too. That's because we wouldn't see when Oracle would backport such bugs for their Oracle 11 Updates and we fear we'd miss something important otherwise. But I suggest to withdraw this backport of JDK-8223326 and set JDK-8241460 to "Won't Fix". Best regards Christoph From christoph.langer at sap.com Tue Mar 24 06:42:25 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Mar 2020 06:42:25 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: References: Message-ID: Hi Alan, > On 23/03/2020 18:07, Doerr, Martin wrote: > > Hi, > > > > I'd like to backport JDK-8223326 from jdk/jdk. > > > One other thing on this. It looks like the spec changes that were part > of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by > mistake. Is that part of the issue that you are trying to fix? I can't find/access JDK-8218573 and I also struggle to find a changelist that would resolve it (should it be a private bug). Did you misspell the number? Please help me. Thanks Christoph From Alan.Bateman at oracle.com Tue Mar 24 07:33:46 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Mar 2020 07:33:46 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: References: Message-ID: <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com> On 24/03/2020 06:42, Langer, Christoph wrote: > Hi Alan, > >> On 23/03/2020 18:07, Doerr, Martin wrote: >>> Hi, >>> >>> I'd like to backport JDK-8223326 from jdk/jdk. >>> >> One other thing on this. It looks like the spec changes that were part >> of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by >> mistake. Is that part of the issue that you are trying to fix? > I can't find/access JDK-8218573 and I also struggle to find a changelist that would resolve it (should it be a private bug). Did you misspell the number? Please help me. > JDK-8218573 was a security fix (restricted in JBS). The spec update for Java SE 13+ that was part of that change have found their way into the jdk11u-dev repo, the change for JDK 12 and older should have not included the spec change. https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c7602effc480 -Alan. From Alan.Bateman at oracle.com Tue Mar 24 07:56:27 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Mar 2020 07:56:27 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com> References: <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com> Message-ID: <63c12a33-f9ec-90dd-bec4-ec23249a4a9c@oracle.com> On 24/03/2020 07:33, Alan Bateman wrote: > > The spec update for Java SE 13+ that was part of that change have > found their way into the jdk11u-dev repo, Sorry, I mean Java SE 14. It seems the spec change was accidentally pushed to 13.0.1 too. -Alan From christoph.langer at sap.com Tue Mar 24 08:19:12 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Mar 2020 08:19:12 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com> References: <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com> Message-ID: > >> One other thing on this. It looks like the spec changes that were part > >> of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by > >> mistake. Is that part of the issue that you are trying to fix? > > I can't find/access JDK-8218573 and I also struggle to find a changelist that > would resolve it (should it be a private bug). Did you misspell the number? > Please help me. > > > JDK-8218573 was a security fix (restricted in JBS). The spec update for > Java SE 13+ that was part of that change have found their way into the > jdk11u-dev repo, the change for JDK 12 and older should have not > included the spec change. > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c7602effc480 Ah, I see... JDK-8218573 is JDK11u/JDK13u specific. Looks like it was derived from JDK-8217997 in jdk/jdk but pushed as a different bug. jdk/jdk was the only place where I was looking for JDK-8218573, so I couldn't find it. By spec part you mean the "@throws SecurityException" sections? Do you think those should not have been part of the 11u/13u change? Should these be even rolled back? Thanks Christoph From adinn at redhat.com Tue Mar 24 08:59:18 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 24 Mar 2020 08:59:18 +0000 Subject: RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode In-Reply-To: References: <2763b3c6-6305-46be-5223-c0a0e47c9359@redhat.com> Message-ID: <64130480-f8bf-37b9-8d05-0dffcecb4ed3@redhat.com> On 23/03/2020 18:38, Erik Joelsson wrote: > Looks good. Thanks for the review, Erik. I'm assuming that also implies it is trivial (because, copyright update a side, it really is a 1-liner :-). I will push to the dev tree and request a backport to jdk14u. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill > On 2020-03-23 10:56, Andrew Dinn wrote: >> Could I please have a review for this trivial fix to the module make >> file which ensures that javadoc is generated for new module >> jdk.nio.mapmode created as part of the implementation of JEP 352. The >> original patch added the module to the BOOT_MODULES list but was not to >> the DOCS_MODULES list. >> >> JIRA:?? https://bugs.openjdk.java.net/browse/JDK-8241144 >> webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev >> >> Testing: >> >> Built image and compiled + ran Hello World. >> >> Built make target docs-jdk-api-javadoc and checked module >> jdk.nio.mapmode was included in output >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill >> > From magnus.ihse.bursie at oracle.com Tue Mar 24 09:10:40 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 Mar 2020 10:10:40 +0100 Subject: RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode In-Reply-To: <64130480-f8bf-37b9-8d05-0dffcecb4ed3@redhat.com> References: <2763b3c6-6305-46be-5223-c0a0e47c9359@redhat.com> <64130480-f8bf-37b9-8d05-0dffcecb4ed3@redhat.com> Message-ID: <610be2c1-7715-9ea5-c11e-cef1f06ca917@oracle.com> On 2020-03-24 09:59, Andrew Dinn wrote: > On 23/03/2020 18:38, Erik Joelsson wrote: >> Looks good. > Thanks for the review, Erik. > > I'm assuming that also implies it is trivial (because, copyright update > a side, it really is a 1-liner :-). For code in the build system, we do not have the Hotspot rules of multiple reviewers, waiting period or trtiviality. A single OK review is enough to be allowed to push it. (And for the record, you can add me as reviewer as well, if you wish? :)) /Magnus > > I will push to the dev tree and request a backport to jdk14u. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > >> On 2020-03-23 10:56, Andrew Dinn wrote: >>> Could I please have a review for this trivial fix to the module make >>> file which ensures that javadoc is generated for new module >>> jdk.nio.mapmode created as part of the implementation of JEP 352. The >>> original patch added the module to the BOOT_MODULES list but was not to >>> the DOCS_MODULES list. >>> >>> JIRA:?? https://bugs.openjdk.java.net/browse/JDK-8241144 >>> webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev >>> >>> Testing: >>> >>> Built image and compiled + ran Hello World. >>> >>> Built make target docs-jdk-api-javadoc and checked module >>> jdk.nio.mapmode was included in output >>> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> Senior Principal Software Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill >>> From adinn at redhat.com Tue Mar 24 09:15:56 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 24 Mar 2020 09:15:56 +0000 Subject: RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode In-Reply-To: <610be2c1-7715-9ea5-c11e-cef1f06ca917@oracle.com> References: <2763b3c6-6305-46be-5223-c0a0e47c9359@redhat.com> <64130480-f8bf-37b9-8d05-0dffcecb4ed3@redhat.com> <610be2c1-7715-9ea5-c11e-cef1f06ca917@oracle.com> Message-ID: On 24/03/2020 09:10, Magnus Ihse Bursie wrote: > On 2020-03-24 09:59, Andrew Dinn wrote: >> I'm assuming that also implies it is trivial (because, copyright update >> a side, it really is a 1-liner :-). > > For code in the build system, we do not have the Hotspot rules of > multiple reviewers, waiting period or trtiviality. A single OK review is > enough to be allowed to push it. Ah ok, thanks for the advice. I'll push as soon as hg.openjdk.java.net comes back to life. > (And for the record, you can add me as reviewer as well, if you wish? :)) You are on the list :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From Alan.Bateman at oracle.com Tue Mar 24 09:53:06 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Mar 2020 09:53:06 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: References: <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com> Message-ID: <5badfad0-14c8-e4a2-62ed-57f838767e3e@oracle.com> On 24/03/2020 08:19, Langer, Christoph wrote: > > Ah, I see... JDK-8218573 is JDK11u/JDK13u specific. Looks like it was derived from JDK-8217997 in jdk/jdk but pushed as a different bug. jdk/jdk was the only place where I was looking for JDK-8218573, so I couldn't find it. I don't have time to dig into this tangled web but it does appear that a backport issue was used instead of the main issue in at least one case. That might be part of the confusion with the JBS issues. It also appears that JDK-8223326 has been backported to several releases where it is not applicable. > > By spec part you mean the "@throws SecurityException" sections? Do you think those should not have been part of the 11u/13u change? Should these be even rolled back? > The spec changes to NetPermission and the protected Socket constructor should not be in the update releases. If a security fix involves a spec clarification then a good starting assumption is that the scope of the change for the update releases, if applicable, will be bit different. -Alan. From martin.doerr at sap.com Tue Mar 24 10:21:30 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 24 Mar 2020 10:21:30 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: <5badfad0-14c8-e4a2-62ed-57f838767e3e@oracle.com> References: <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com> <5badfad0-14c8-e4a2-62ed-57f838767e3e@oracle.com> Message-ID: Thanks a lot for looking into this, Alan, Chris and Christoph! We had also looked at "8217997: Better socket support": https://hg.openjdk.java.net/jdk/jdk/rev/94710bb2a5bb which was backported as "8218573: Better socket support": http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c7602effc480 with the spec update. It's not so easy to understand which changes need to get backportet and we should make sure we don't miss anything really important. Thanks for shedding more light into the history. I've closed it as "Not an Issue". Best regards, Martin > -----Original Message----- > From: Alan Bateman > Sent: Dienstag, 24. M?rz 2020 10:53 > To: Langer, Christoph ; Doerr, Martin > ; core-libs-dev at openjdk.java.net; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR(S): 8223326: Regression introduced by CPU sync: > java.security.AccessControlException: access denied > ("java.net.NetPermission" "setSocketImpl") > > On 24/03/2020 08:19, Langer, Christoph wrote: > > > > Ah, I see... JDK-8218573 is JDK11u/JDK13u specific. Looks like it was derived > from JDK-8217997 in jdk/jdk but pushed as a different bug. jdk/jdk was the > only place where I was looking for JDK-8218573, so I couldn't find it. > I don't have time to dig into this tangled web but it does appear that a > backport issue was used instead of the main issue in at least one case. > That might be part of the confusion with the JBS issues. It also appears > that JDK-8223326 has been backported to several releases where it is not > applicable. > > > > > By spec part you mean the "@throws SecurityException" sections? Do you > think those should not have been part of the 11u/13u change? Should these > be even rolled back? > > > The spec changes to NetPermission and the protected Socket constructor > should not be in the update releases. If a security fix involves a spec > clarification then a good starting assumption is that the scope of the > change for the update releases, if applicable, will be bit different. > > -Alan. From christoph.langer at sap.com Tue Mar 24 10:55:02 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Mar 2020 10:55:02 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") In-Reply-To: <5badfad0-14c8-e4a2-62ed-57f838767e3e@oracle.com> References: <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com> <5badfad0-14c8-e4a2-62ed-57f838767e3e@oracle.com> Message-ID: > > By spec part you mean the "@throws SecurityException" sections? Do you > think those should not have been part of the 11u/13u change? Should these > be even rolled back? > > > The spec changes to NetPermission and the protected Socket constructor > should not be in the update releases. If a security fix involves a spec > clarification then a good starting assumption is that the scope of the > change for the update releases, if applicable, will be bit different. Ok, makes sense. I wasn't involved in the security fix and its backport, though. But I assume should now leave the fix for JDK-8218573: "Better socket support" (http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c7602effc480) alone now? /Christoph From shade at redhat.com Tue Mar 24 11:03:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 24 Mar 2020 12:03:34 +0100 Subject: RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays In-Reply-To: References: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> Message-ID: <019318a9-995e-3e0f-28e0-67030297d5b7@redhat.com> On 3/23/20 9:35 PM, Alan Bateman wrote: > On 23/03/2020 19:22, Aleksey Shipilev wrote: >> +import java.io.InputStream; >> import java.io.IOException; >> import java.lang.ProcessBuilder.Redirect; >> @@ -314,5 +315,8 @@ >> String relativeDbgFileName = relativeFileName + "." + debugExt; >> >> - Files.write(resourceFileBinary, resource.contentBytes()); >> + try (InputStream in = resource.content()) { >> + Files.copy(in, resourceFileBinary); >> + } >> + >> Path resourceFileDebugSymbols; >> if (includeDebug) { >> > This looks okay. Thanks Alan. Severin, you're good with this? -- -Aleksey From magnus.ihse.bursie at oracle.com Tue Mar 24 12:12:45 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 Mar 2020 13:12:45 +0100 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: References: Message-ID: <01a1c812-1adb-a4a2-3db0-327f76c0b21c@oracle.com> On 2020-03-23 23:15, naoto.sato at oracle.com wrote: > Hi Magnus, > > I looked at i18n related changes: > > make/CopyInterimTZDB.gmk > make/ToolsJdk.gmk > make/gendata/Gendata-java.base.gmk > make/gendata/GendataBreakIterator.gmk > make/gendata/GendataTZDB.gmk > make/gensrc/GensrcCharacterData.gmk > make/gensrc/GensrcEmojiData.gmk > > They look ok to me. Thank you! > > The *.java changes should have copyright year update. Ok, I'll update them. > > As to charsetmapping and cldrconverter, I believe they can reside in > java.base, as jdk.charsets and jdk.localedata modules depend on it. Okay. It's not ideal, but I think you're right. I'll move them as well. I'll publish an updated webrev with these changes when there's agreement on where in the source code tree to move the files. /Magnus > > Naoto > > On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote: >> The build tools (small java tools that are run during the build to >> generate source code, or data, needed in the JDK) have historically >> been placed in the "make" directory. This maybe made sense long time >> ago, but does not do so anymore. >> >> Instead, the build tools source code should move the the module that >> needs them. For instance, compilefontconfig should move to >> java.desktop, etc. >> >> There are multiple reasons for this: >> >> * Currently we build *all* build tools at once, which mean that we >> cannot compile java.base until e.g. the compilefontconfig tool is >> compiled, even though it is not needed. >> >> * If a build tool, e.g. compilefontconfig is modified, all build >> tools are recompiled, which triggers a rebuild of more or less the >> entire JDK. This makes development of the build tools unnecessary >> tedious. >> >> * When the build tools are modified, the group owning the >> corresponding module is the proper review instance, not the build >> team. But since they reside under "make", the review mails often >> include build-dev, but this is mostly noise for us. With this move, >> the ownership is made clear. >> >> In this patch, I have not modified how and when the build tools are >> compiled, but this shuffle is the prerequisite for continuing with >> that in a follow-up patch. >> >> I have also moved the build tools to the org.openjdk.buildtools.* >> package name space (inspired by Skara), instead of the strangely >> named build.tools.* name space. >> >> A few build tools are not moved in this patch. Two of them, >> charsetmapping and cldrconverter, are shared between two modules. (I >> think they should move to modules nevertheless, but they need some >> more thought to make sure I do this right.) The rest are tools that >> are needed for the build in general, like linking or javadoc support. >> I'll move this to a better location too, but in a separate patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 >> >> >> /Magnus >> From hohensee at amazon.com Tue Mar 24 13:36:11 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 24 Mar 2020 13:36:11 +0000 Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl") Message-ID: <7CBCC096-6FCF-4D89-A2EE-366B4B780371@amazon.com> Thanks for the explanation of the process. Paul ?On 3/23/20, 11:28 PM, "Langer, Christoph" wrote: Hi Paul, as Martin said, the original bug could not be opened by Oracle. I, however changed the bug created by Martin to a Backport item. Doing it that way would allow a "standard" backport of such type of issues while the original item that was pushed to head can remain invisible. We proceeded like that with other bugs already and it proved to work nicely. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Hohensee, Paul > Sent: Montag, 23. M?rz 2020 19:29 > To: Doerr, Martin ; core-libs- > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync: > java.security.AccessControlException: access denied > ("java.net.NetPermission" "setSocketImpl") > > The changeset references JDK-8223326, which is private. If possible, ask > Oracle to make it public so we can do a normal backport rather than file an > 11u-specific issue. The backport itself looks fine. > > Thanks, > Paul > > On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin" updates-dev-bounces at openjdk.java.net on behalf of > martin.doerr at sap.com> wrote: > > > Hi, > > I'd like to backport JDK-8223326 from jdk/jdk. > > 11u backport issue: > https://bugs.openjdk.java.net/browse/JDK-8241460 > > Original change: > https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc > > 11u backport webrev: > > http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/ > > I had to integrate the change manually due to context changes. However, > the new code fits to the 11u versions. > > Please review. > > Best regards, > Martin > > From iris.clark at oracle.com Tue Mar 24 15:42:18 2020 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 24 Mar 2020 08:42:18 -0700 (PDT) Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open In-Reply-To: References: <1c0ce959-a9b4-03e3-da33-4b05754a96f4@oracle.com> Message-ID: Hi, Naoto. > https://cr.openjdk.java.net/~naoto/8241311/webrev.06/ Looks good! Thanks, Iris From takiguc at linux.vnet.ibm.com Tue Mar 24 16:24:00 2020 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 25 Mar 2020 01:24:00 +0900 Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open In-Reply-To: <212756ea-a1a5-2e5a-4b05-0e50f8e61ac5@oracle.com> References: <240d73307297109f271fdd325ad057f9@linux.vnet.ibm.com> <212756ea-a1a5-2e5a-4b05-0e50f8e61ac5@oracle.com> Message-ID: <5bae468278debc4cd445ec71cdb55b01@linux.vnet.ibm.com> Hello Naoto. I tested webrev.06 code. It's fine, thanks. I'm interested in about @module for these testcases. I think webrev.04 code worked via jtreg. I could not see any warning. At this case, @module is required ? Thanks, Ichiroh Takiguchi On 2020-03-24 10:06, naoto.sato at oracle.com wrote: > Hi Takiguchi-san, > > On 3/23/20 5:48 AM, Ichiroh Takiguchi wrote: >> Hello Naoto. >> >> I'm not reviewer, but I have a concern about following code >> on test/jdk/sun/nio/cs/mapping/TestConv.java >> ====== >> ?98???????????? } catch (Exception ex) { >> ?99???????????????? System.out.println("Exception >> thrown while testing " + encoding); >> 100???????????????? ex.printStackTrace(); >> 101???????????????? return; >> 102???????????? } >> ====== >> >> 3 stack trace (java.io.UnsupportedEncodingException) were displayed >> against following encodings: >> ? MS50221_0208, MS50221_0212, MS932_0208 >> >> I think only UnsupportedEncodingException should be caught. >> The other exception should be handled as error. >> >> What do you think ? > > Good catch. I believe the test logic that assumes the file name is the > charset name is simply wrong. I added the check whether the input > charset name is supported or not, and only do the test if the charset > is supported: > > http://cr.openjdk.java.net/~naoto/8241311/webrev.05/ > > Naoto > >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2020-03-21 01:21, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8241311 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8241311/webrev.04/ >>> >>> This is simply to move some test cases that have been in closed >>> repository into open repository. >>> >>> Naoto From naoto.sato at oracle.com Tue Mar 24 16:30:21 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 24 Mar 2020 09:30:21 -0700 Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open In-Reply-To: <9558e95b-d092-f767-d77b-8aa410301867@oracle.com> References: <1c0ce959-a9b4-03e3-da33-4b05754a96f4@oracle.com> <9558e95b-d092-f767-d77b-8aa410301867@oracle.com> Message-ID: Thanks again. I will look into it and come up with better migration of those tests. Naoto On 3/23/20 9:45 PM, Amy Lu wrote: > Thank you Naoto for the quick update. > > Just more findings ...(sorry for not sending earlier) > > CoderTest.java > Looks like this test has already been migrated (with enhancement) to the > 'open' [1] in JDK-8186801 [2] [3]. > > I'm not sure whether the data files that used by TestCharsetMapping.java > can be leveraged by other two tests, but worth checking. > > Thanks, > Amy > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/sun/nio/cs/TestCharsetMapping.java > > [2] https://bugs.openjdk.java.net/browse/JDK-8186801 > [3] https://mail.openjdk.java.net/pipermail/nio-dev/2017-August/004427.html > > > On 3/24/20 12:19 PM, naoto.sato at oracle.com wrote: >> Hi Amy, >> >> Good point. Updated. >> >> https://cr.openjdk.java.net/~naoto/8241311/webrev.06/ >> >> Naoto >> >> On 3/23/20 7:43 PM, Amy Lu wrote: >>> Hi, Naoto >>> >>> CoderTest.java TestConv.java >>> Should they also include @modules jdk.charsets ? >>> >>> Thanks, >>> Amy >>> >>> On 3/21/20 12:21 AM, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8241311 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8241311/webrev.04/ >>>> >>>> This is simply to move some test cases that have been in closed >>>> repository into open repository. >>>> >>>> Naoto >>> > From naoto.sato at oracle.com Tue Mar 24 16:46:02 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 24 Mar 2020 09:46:02 -0700 Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open In-Reply-To: <5bae468278debc4cd445ec71cdb55b01@linux.vnet.ibm.com> References: <240d73307297109f271fdd325ad057f9@linux.vnet.ibm.com> <212756ea-a1a5-2e5a-4b05-0e50f8e61ac5@oracle.com> <5bae468278debc4cd445ec71cdb55b01@linux.vnet.ibm.com> Message-ID: <69eddfe4-f0f8-b1cf-b4a4-81f6d3cd5bf3@oracle.com> On 3/24/20 9:24 AM, Ichiroh Takiguchi wrote: > Hello Naoto. > > I tested webrev.06 code. > It's fine, thanks. > > I'm interested in about @module for these testcases. > I think webrev.04 code worked via jtreg. > I could not see any warning. > At this case, @module is required ? Yes. The tag lets jtreg not run the test if jdk.charsets module is not present in the test JDK. Otherwise, it may give you the false negative result. Naoto > > Thanks, > Ichiroh Takiguchi > > On 2020-03-24 10:06, naoto.sato at oracle.com wrote: >> Hi Takiguchi-san, >> >> On 3/23/20 5:48 AM, Ichiroh Takiguchi wrote: >>> Hello Naoto. >>> >>> I'm not reviewer, but I have a concern about following code >>> on test/jdk/sun/nio/cs/mapping/TestConv.java >>> ====== >>> ??98???????????? } catch (Exception ex) { >>> ??99???????????????? System.out.println("Exception thrown while >>> testing " + encoding); >>> 100???????????????? ex.printStackTrace(); >>> 101???????????????? return; >>> 102???????????? } >>> ====== >>> >>> 3 stack trace (java.io.UnsupportedEncodingException) were displayed >>> against following encodings: >>> ?? MS50221_0208, MS50221_0212, MS932_0208 >>> >>> I think only UnsupportedEncodingException should be caught. >>> The other exception should be handled as error. >>> >>> What do you think ? >> >> Good catch. I believe the test logic that assumes the file name is the >> charset name is simply wrong. I added the check whether the input >> charset name is supported or not, and only do the test if the charset >> is supported: >> >> http://cr.openjdk.java.net/~naoto/8241311/webrev.05/ >> >> Naoto >> >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2020-03-21 01:21, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8241311 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8241311/webrev.04/ >>>> >>>> This is simply to move some test cases that have been in closed >>>> repository into open repository. >>>> >>>> Naoto From shade at redhat.com Tue Mar 24 17:10:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 24 Mar 2020 18:10:21 +0100 Subject: RFR (XS/T) 8241445: Fix copyrights after JDK-8240629 change In-Reply-To: References: Message-ID: <02da4c40-113f-f8b1-fe22-53bf02ce0c32@redhat.com> On 3/23/20 3:02 PM, Aleksey Shipilev wrote: > This change in JDK-8240629 was not correct and slipped the review? > https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2#l2.5 > > Also, other file has not updated the copyright line. > > Fix: > > diff -r 35ff74547c64 src/java.base/share/native/libjli/args.c > --- a/src/java.base/share/native/libjli/args.c Mon Mar 23 14:10:58 2020 +0100 > +++ b/src/java.base/share/native/libjli/args.c Mon Mar 23 15:00:46 2020 +0100 > @@ -1,4 +1,4 @@ > /* > - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > diff -r 35ff74547c64 test/jdk/tools/launcher/ArgFileSyntax.java > --- a/test/jdk/tools/launcher/ArgFileSyntax.java Mon Mar 23 14:10:58 2020 +0100 > +++ b/test/jdk/tools/launcher/ArgFileSyntax.java Mon Mar 23 15:00:46 2020 +0100 > @@ -1,4 +1,4 @@ > /* > - * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * No takers? :) -- Thanks, -Aleksey From thomas.stuefe at gmail.com Tue Mar 24 17:28:05 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 24 Mar 2020 18:28:05 +0100 Subject: [PING] RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: References: Message-ID: Hi Tagir, nice work. Only a partwise review for TreeMap.java, did not yet look at the tests. remapValue: 711 } else { 712 // replace old mapping 713 t.value = newValue; 714 return newValue; 715 } Should we increase the modification count here? AFAICS Map::computeIfPresent(), Map::compute(), Map::merge() use put() to replace existing value which would have increased TreeMap::modCount . Same for mergeValue(). -- At various places, the "@throws ConcurrentModificationException" javadoc: 619 * @throws ConcurrentModificationException if it is detected that the 620 * mapping function modified this map is missing the period. --- We could exchange all the various if (key == null) throw new NullPointerException(); lines on comparator==null paths with Objects.requireNonNull(key). --- Style nits & bikeshedding: I would place both versions of getNewValueAndCheckModification() together with the other new low level utility functions (addEntry, addEntryToEmptyMap). I may also have named them somewhat differently, maybe "callMappingFunctionWithCheck" resp. "callRemappingFunctionWithCheck". --- private void addEntry(K key, V value, int cmp, Entry parent) { For clarity, could we make cmp a boolean "leftOrRight" or are you afraid that would cost too much performance? --- About the CSR: I guess this has already been discussed but I feel that changing the checking behavior of computeIfPresent() and friends to now detect ConcurrentModificationException has nothing really to do with this change and could be left out. Thank you, On Tue, Mar 24, 2020 at 3:41 AM Tagir Valeev wrote: > Hello! > > A gentle reminder to review the specialized implementation of TreeMap > methods. The latest webrev is here: > http://cr.openjdk.java.net/~tvaleev/webrev/8176894/r4/ > Issue: > https://bugs.openjdk.java.net/browse/JDK-8176894 > > CSR is already approved (thanks to Joe Darcy and Stuart Marks): > https://bugs.openjdk.java.net/browse/JDK-8227666 > So only code review is necessary. Also, no sponsorship is necessary. > > Here's the previous discussion > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-October/062859.html > Here's benchmarking results > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-February/064901.html > > Let's push it into Java 15! > > With best regards, > Tagir Valeev. > From paul.sandoz at oracle.com Tue Mar 24 17:38:57 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 24 Mar 2020 10:38:57 -0700 Subject: RFR (XS/T) 8241445: Fix copyrights after JDK-8240629 change In-Reply-To: <02da4c40-113f-f8b1-fe22-53bf02ce0c32@redhat.com> References: <02da4c40-113f-f8b1-fe22-53bf02ce0c32@redhat.com> Message-ID: I?ll bite :-) +1 Paul. > On Mar 24, 2020, at 10:10 AM, Aleksey Shipilev wrote: > > On 3/23/20 3:02 PM, Aleksey Shipilev wrote: >> This change in JDK-8240629 was not correct and slipped the review? >> https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2#l2.5 >> >> Also, other file has not updated the copyright line. >> >> Fix: >> >> diff -r 35ff74547c64 src/java.base/share/native/libjli/args.c >> --- a/src/java.base/share/native/libjli/args.c Mon Mar 23 14:10:58 2020 +0100 >> +++ b/src/java.base/share/native/libjli/args.c Mon Mar 23 15:00:46 2020 +0100 >> @@ -1,4 +1,4 @@ >> /* >> - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> diff -r 35ff74547c64 test/jdk/tools/launcher/ArgFileSyntax.java >> --- a/test/jdk/tools/launcher/ArgFileSyntax.java Mon Mar 23 14:10:58 2020 +0100 >> +++ b/test/jdk/tools/launcher/ArgFileSyntax.java Mon Mar 23 15:00:46 2020 +0100 >> @@ -1,4 +1,4 @@ >> /* >> - * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * > > No takers? :) > > -- > Thanks, > -Aleksey > From shade at redhat.com Tue Mar 24 17:40:40 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 24 Mar 2020 18:40:40 +0100 Subject: RFR (XS/T) 8241445: Fix copyrights after JDK-8240629 change In-Reply-To: References: <02da4c40-113f-f8b1-fe22-53bf02ce0c32@redhat.com> Message-ID: On 3/24/20 6:38 PM, Paul Sandoz wrote: > I?ll bite :-) +1 Thanks. Would you also, per chance, consider it trivial? -- -Aleksey From sgehwolf at redhat.com Tue Mar 24 17:40:53 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 24 Mar 2020 18:40:53 +0100 Subject: RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays In-Reply-To: <019318a9-995e-3e0f-28e0-67030297d5b7@redhat.com> References: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> <019318a9-995e-3e0f-28e0-67030297d5b7@redhat.com> Message-ID: On Tue, 2020-03-24 at 12:03 +0100, Aleksey Shipilev wrote: > On 3/23/20 9:35 PM, Alan Bateman wrote: > > On 23/03/2020 19:22, Aleksey Shipilev wrote: > > > +import java.io.InputStream; > > > import java.io.IOException; > > > import java.lang.ProcessBuilder.Redirect; > > > @@ -314,5 +315,8 @@ > > > String relativeDbgFileName = relativeFileName + "." + debugExt; > > > > > > - Files.write(resourceFileBinary, resource.contentBytes()); > > > + try (InputStream in = resource.content()) { > > > + Files.copy(in, resourceFileBinary); > > > + } > > > + > > > Path resourceFileDebugSymbols; > > > if (includeDebug) { > > > > > This looks okay. > > Thanks Alan. > > Severin, you're good with this? Looks good. Thanks, Severin From shade at redhat.com Tue Mar 24 17:43:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 24 Mar 2020 18:43:44 +0100 Subject: RFR (XS) 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays In-Reply-To: References: <65d59ecc-e999-e66a-4a03-27ec990f6ca5@redhat.com> <019318a9-995e-3e0f-28e0-67030297d5b7@redhat.com> Message-ID: <299f0538-db8b-0e56-f71d-6599e3bc2294@redhat.com> On 3/24/20 6:40 PM, Severin Gehwolf wrote: > On Tue, 2020-03-24 at 12:03 +0100, Aleksey Shipilev wrote: >> On 3/23/20 9:35 PM, Alan Bateman wrote: >>> On 23/03/2020 19:22, Aleksey Shipilev wrote: >>>> +import java.io.InputStream; >>>> import java.io.IOException; >>>> import java.lang.ProcessBuilder.Redirect; >>>> @@ -314,5 +315,8 @@ >>>> String relativeDbgFileName = relativeFileName + "." + debugExt; >>>> >>>> - Files.write(resourceFileBinary, resource.contentBytes()); >>>> + try (InputStream in = resource.content()) { >>>> + Files.copy(in, resourceFileBinary); >>>> + } >>>> + >>>> Path resourceFileDebugSymbols; >>>> if (includeDebug) { >>>> >>> This looks okay. >> >> Thanks Alan. >> >> Severin, you're good with this? > > Looks good. Thanks! -- -Aleksey From paul.sandoz at oracle.com Tue Mar 24 17:45:53 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 24 Mar 2020 10:45:53 -0700 Subject: RFR (XS/T) 8241445: Fix copyrights after JDK-8240629 change In-Reply-To: References: <02da4c40-113f-f8b1-fe22-53bf02ce0c32@redhat.com> Message-ID: <316EF57B-EAD1-449D-BA30-454DB30492B9@oracle.com> > On Mar 24, 2020, at 10:40 AM, Aleksey Shipilev wrote: > > On 3/24/20 6:38 PM, Paul Sandoz wrote: >> I?ll bite :-) +1 > > Thanks. Would you also, per chance, consider it trivial? Very much so. It?s maybe something that could be gated by jcheck (or whatever the equivalent is for Skara). Paul. From fw at deneb.enyo.de Tue Mar 24 17:49:57 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 24 Mar 2020 18:49:57 +0100 Subject: RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode In-Reply-To: <610be2c1-7715-9ea5-c11e-cef1f06ca917@oracle.com> (Magnus Ihse Bursie's message of "Tue, 24 Mar 2020 10:10:40 +0100") References: <2763b3c6-6305-46be-5223-c0a0e47c9359@redhat.com> <64130480-f8bf-37b9-8d05-0dffcecb4ed3@redhat.com> <610be2c1-7715-9ea5-c11e-cef1f06ca917@oracle.com> Message-ID: <874kudtzga.fsf@mid.deneb.enyo.de> * Magnus Ihse Bursie: > On 2020-03-24 09:59, Andrew Dinn wrote: >> On 23/03/2020 18:38, Erik Joelsson wrote: >>> Looks good. >> Thanks for the review, Erik. >> >> I'm assuming that also implies it is trivial (because, copyright update >> a side, it really is a 1-liner :-). > > For code in the build system, we do not have the Hotspot rules of > multiple reviewers, waiting period or trtiviality. A single OK review is > enough to be allowed to push it. Where are these rules documented? I looked for them on openjdk.java.net, but could not find them unfortunately. From naoto.sato at oracle.com Tue Mar 24 20:37:21 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 24 Mar 2020 13:37:21 -0700 Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open In-Reply-To: <9558e95b-d092-f767-d77b-8aa410301867@oracle.com> References: <1c0ce959-a9b4-03e3-da33-4b05754a96f4@oracle.com> <9558e95b-d092-f767-d77b-8aa410301867@oracle.com> Message-ID: <93c5fe0f-c845-0c2f-1bb2-842ac4224f73@oracle.com> Hi Amy, I ended up the fix pretty much as of ver 06, as those data file formats are different. It'd require some amount of refactoring to those other two tests, and CoderTest.java is a dependence to ConverterTest.java, so I left them as-is. One minor change from 06 is to add @modules jdk.charsets to TestCharsetMapping.java. http://cr.openjdk.java.net/~naoto/8241311/webrev.07/ Naoto On 3/23/20 9:45 PM, Amy Lu wrote: > Thank you Naoto for the quick update. > > Just more findings ...(sorry for not sending earlier) > > CoderTest.java > Looks like this test has already been migrated (with enhancement) to the > 'open' [1] in JDK-8186801 [2] [3]. > > I'm not sure whether the data files that used by TestCharsetMapping.java > can be leveraged by other two tests, but worth checking. > > Thanks, > Amy > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/sun/nio/cs/TestCharsetMapping.java > > [2] https://bugs.openjdk.java.net/browse/JDK-8186801 > [3] https://mail.openjdk.java.net/pipermail/nio-dev/2017-August/004427.html > > > On 3/24/20 12:19 PM, naoto.sato at oracle.com wrote: >> Hi Amy, >> >> Good point. Updated. >> >> https://cr.openjdk.java.net/~naoto/8241311/webrev.06/ >> >> Naoto >> >> On 3/23/20 7:43 PM, Amy Lu wrote: >>> Hi, Naoto >>> >>> CoderTest.java TestConv.java >>> Should they also include @modules jdk.charsets ? >>> >>> Thanks, >>> Amy >>> >>> On 3/21/20 12:21 AM, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8241311 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8241311/webrev.04/ >>>> >>>> This is simply to move some test cases that have been in closed >>>> repository into open repository. >>>> >>>> Naoto >>> > From fw at deneb.enyo.de Tue Mar 24 21:24:19 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 24 Mar 2020 22:24:19 +0100 Subject: [PING] RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: ("Thomas \=\?iso-8859-1\?Q\?St\=FCfe\=22's\?\= message of "Tue, 24 Mar 2020 18:28:05 +0100") References: Message-ID: <87r1xhsayk.fsf@mid.deneb.enyo.de> * Thomas St?fe: > Hi Tagir, > > nice work. Only a partwise review for TreeMap.java, did not yet look at the > tests. > > remapValue: > > 711 } else { > 712 // replace old mapping > 713 t.value = newValue; > 714 return newValue; > 715 } > > Should we increase the modification count here? It's not a structural modification, is it? Only structural modifications increase the modification count, as far as I can see. From martinrb at google.com Wed Mar 25 00:45:48 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 Mar 2020 17:45:48 -0700 Subject: [PING] RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: References: Message-ID: Hi Tagir, Looks good to me. I can't find anything actually wrong, so here are some nitpicks you can ignore: --- 676 V newValue; 677 int mc = modCount; 678 newValue = mappingFunction.apply(key); I would never use a C style declaration when an initializing declaration would work equally well. --- Prevailing whitespace style here is Entry rather than Entry but Intellij is on your side --- On Mon, Mar 23, 2020 at 7:41 PM Tagir Valeev wrote: > Hello! > > A gentle reminder to review the specialized implementation of TreeMap > methods. The latest webrev is here: > http://cr.openjdk.java.net/~tvaleev/webrev/8176894/r4/ > Issue: > https://bugs.openjdk.java.net/browse/JDK-8176894 > > CSR is already approved (thanks to Joe Darcy and Stuart Marks): > https://bugs.openjdk.java.net/browse/JDK-8227666 > So only code review is necessary. Also, no sponsorship is necessary. > > Here's the previous discussion > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-October/062859.html > Here's benchmarking results > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-February/064901.html > > Let's push it into Java 15! > > With best regards, > Tagir Valeev. > From david.holmes at oracle.com Wed Mar 25 01:22:37 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Mar 2020 11:22:37 +1000 Subject: RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode In-Reply-To: <874kudtzga.fsf@mid.deneb.enyo.de> References: <2763b3c6-6305-46be-5223-c0a0e47c9359@redhat.com> <64130480-f8bf-37b9-8d05-0dffcecb4ed3@redhat.com> <610be2c1-7715-9ea5-c11e-cef1f06ca917@oracle.com> <874kudtzga.fsf@mid.deneb.enyo.de> Message-ID: <0f63bf7b-69d3-4a4a-948b-d9146ededde1@oracle.com> On 25/03/2020 3:49 am, Florian Weimer wrote: > * Magnus Ihse Bursie: > >> On 2020-03-24 09:59, Andrew Dinn wrote: >>> On 23/03/2020 18:38, Erik Joelsson wrote: >>>> Looks good. >>> Thanks for the review, Erik. >>> >>> I'm assuming that also implies it is trivial (because, copyright update >>> a side, it really is a 1-liner :-). >> >> For code in the build system, we do not have the Hotspot rules of >> multiple reviewers, waiting period or trtiviality. A single OK review is >> enough to be allowed to push it. > > Where are these rules documented? I looked for them on > openjdk.java.net, but could not find them unfortunately. Hotspot rules are buried in here: https://wiki.openjdk.java.net/display/HotSpot/HotSpot+How+To "Before pushing" You must be a Committer in the JDK project You need a non-JEP JBS issue for tracking Your change must have been available for review at least 24 hours to accommodate for all time zones Your change must have been approved by two Committers out of which at least one is also a Reviewer Your change must have passed through the hs tier 1 testing provided by the submit-hs repository with zero failures You must run all relevant testing to make sure your actual change is working You must be available the next few hours, and the next day and ready to follow up with any fix needed in case your change causes problems in later tiers There is a notion of trivial changes that can be pushed sooner than 24 hours. It should be clearly stated in the review mail that the intention is to push as a trivial change. How to actually define "trivial" is decided on a case-by-case basis but in general it would be things like fixing a comment, or moving code without changing it. Backing out a change is also considered trivial as the change itself in that case is generated by mercurial. ---- Cheers, David From amy.lu at oracle.com Wed Mar 25 02:11:52 2020 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 25 Mar 2020 10:11:52 +0800 Subject: [15] RFR: 8241311: Move some charset mapping tests from closed to open In-Reply-To: <93c5fe0f-c845-0c2f-1bb2-842ac4224f73@oracle.com> References: <1c0ce959-a9b4-03e3-da33-4b05754a96f4@oracle.com> <9558e95b-d092-f767-d77b-8aa410301867@oracle.com> <93c5fe0f-c845-0c2f-1bb2-842ac4224f73@oracle.com> Message-ID: <246f7aa9-b870-23dd-2911-92d8650e4477@oracle.com> That's fine then. Thank you for looking into this. Thanks, Amy On 3/25/20 4:37 AM, naoto.sato at oracle.com wrote: > Hi Amy, > > I ended up the fix pretty much as of ver 06, as those data file > formats are different. It'd require some amount of refactoring to > those other two tests, and CoderTest.java is a dependence to > ConverterTest.java, so I left them as-is. > > One minor change from 06 is to add @modules jdk.charsets to > TestCharsetMapping.java. > > http://cr.openjdk.java.net/~naoto/8241311/webrev.07/ > > Naoto > > On 3/23/20 9:45 PM, Amy Lu wrote: >> Thank you Naoto for the quick update. >> >> Just more findings ...(sorry for not sending earlier) >> >> CoderTest.java >> Looks like this test has already been migrated (with enhancement) to >> the 'open' [1] in JDK-8186801 [2] [3]. >> >> I'm not sure whether the data files that used by >> TestCharsetMapping.java can be leveraged by other two tests, but >> worth checking. >> >> Thanks, >> Amy >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/sun/nio/cs/TestCharsetMapping.java >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8186801 >> [3] >> https://mail.openjdk.java.net/pipermail/nio-dev/2017-August/004427.html >> >> >> On 3/24/20 12:19 PM, naoto.sato at oracle.com wrote: >>> Hi Amy, >>> >>> Good point. Updated. >>> >>> https://cr.openjdk.java.net/~naoto/8241311/webrev.06/ >>> >>> Naoto >>> >>> On 3/23/20 7:43 PM, Amy Lu wrote: >>>> Hi, Naoto >>>> >>>> CoderTest.java TestConv.java >>>> Should they also include @modules jdk.charsets ? >>>> >>>> Thanks, >>>> Amy >>>> >>>> On 3/21/20 12:21 AM, naoto.sato at oracle.com wrote: >>>>> Hello, >>>>> >>>>> Please review the fix to the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8241311 >>>>> >>>>> The proposed changeset is located at: >>>>> >>>>> https://cr.openjdk.java.net/~naoto/8241311/webrev.04/ >>>>> >>>>> This is simply to move some test cases that have been in closed >>>>> repository into open repository. >>>>> >>>>> Naoto >>>> >> From thomas.stuefe at gmail.com Wed Mar 25 06:01:46 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 25 Mar 2020 07:01:46 +0100 Subject: [PING] RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: <87r1xhsayk.fsf@mid.deneb.enyo.de> References: <87r1xhsayk.fsf@mid.deneb.enyo.de> Message-ID: On Tue, Mar 24, 2020 at 10:25 PM Florian Weimer wrote: > * Thomas St?fe: > > > Hi Tagir, > > > > nice work. Only a partwise review for TreeMap.java, did not yet look at > the > > tests. > > > > remapValue: > > > > 711 } else { > > 712 // replace old mapping > > 713 t.value = newValue; > > 714 return newValue; > > 715 } > > > > Should we increase the modification count here? > > It's not a structural modification, is it? Only structural > modifications increase the modification count, as far as I can see. > You may be right. ..Thomas From xu.y.yin at oracle.com Wed Mar 25 07:57:51 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Wed, 25 Mar 2020 15:57:51 +0800 Subject: [15] RFR: 8214694: cleanup rawtypes warnings in open jndi tests Message-ID: <29BE8612-A772-45AC-AEB3-55C5C3FBAED0@oracle.com> Hello Please review following simple changes to cleanup raw types warning for open jndi tests (under test/jdk/com/sun/jndi and test/jdk/javax/naming), thanks Bug: https://bugs.openjdk.java.net/browse/JDK-8214694 Webrev: http://cr.openjdk.java.net/~xyin/8214694/webrev.00/ The changes should be straightforward, only fix raw types warnings, no test logic change, no code optimization or cleanup. Minor change to each test file, just a little surprised about the affected tests count, hope this covers all. Run related jndi tests on 4 platforms for total 200 times, all passed. Thanks, Chris From magnus.ihse.bursie at oracle.com Wed Mar 25 09:05:12 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 25 Mar 2020 10:05:12 +0100 Subject: RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode In-Reply-To: <0f63bf7b-69d3-4a4a-948b-d9146ededde1@oracle.com> References: <2763b3c6-6305-46be-5223-c0a0e47c9359@redhat.com> <64130480-f8bf-37b9-8d05-0dffcecb4ed3@redhat.com> <610be2c1-7715-9ea5-c11e-cef1f06ca917@oracle.com> <874kudtzga.fsf@mid.deneb.enyo.de> <0f63bf7b-69d3-4a4a-948b-d9146ededde1@oracle.com> Message-ID: <44200411-b933-5c74-7b4d-ecc192316a52@oracle.com> On 2020-03-25 02:22, David Holmes wrote: > On 25/03/2020 3:49 am, Florian Weimer wrote: >> * Magnus Ihse Bursie: >> >>> On 2020-03-24 09:59, Andrew Dinn wrote: >>>> On 23/03/2020 18:38, Erik Joelsson wrote: >>>>> Looks good. >>>> Thanks for the review, Erik. >>>> >>>> I'm assuming that also implies it is trivial (because, copyright >>>> update >>>> a side, it really is a 1-liner :-). >>> >>> For code in the build system, we do not have the Hotspot rules of >>> multiple reviewers, waiting period or trtiviality. A single OK >>> review is >>> enough to be allowed to push it. >> >> Where are these rules documented?? I looked for them on >> openjdk.java.net, but could not find them unfortunately. > > Hotspot rules are buried in here: > > https://wiki.openjdk.java.net/display/HotSpot/HotSpot+How+To Thanks for the link, David. For build code, we don't have any such set of rules, so the absence of rules kind of is the rules. The rule about at least one reviewer is enforced by the JDK project (and jcheck), but that's about it. Hopefully, with Project Skara, many rules such as these can be enforced and/or informed about automatically with bots. /Magnus > > "Before pushing" > > ??? You must be a Committer in the JDK project > ??? You need a non-JEP JBS issue for tracking > ??? Your change must have been available for review at least 24 hours > to accommodate for all time zones > ??? Your change must have been approved by two Committers out of which > at least one is also a Reviewer > ??? Your change must have passed through the hs tier 1 testing > provided by the submit-hs repository with zero failures > ??? You must run all relevant testing to make sure your actual change > is working > ??? You must be available the next few hours, and the next day and > ready to follow up with any fix needed in case your change causes > problems in later tiers > > There is a notion of trivial changes that can be pushed sooner than 24 > hours. It should be clearly stated in the review mail that the > intention is to push as a trivial change. How to actually define > "trivial" is decided on a case-by-case basis but in general it would > be things like fixing a comment, or moving code without changing it. > Backing out a change is also considered trivial as the change itself > in that case is generated by mercurial. > ---- > > Cheers, > David > From Roger.Riggs at oracle.com Wed Mar 25 13:56:59 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 25 Mar 2020 09:56:59 -0400 Subject: RFR 8237599 : Greedy matching against supplementary chars fails to respect the region In-Reply-To: References: <88a8bdd6-0791-0539-ff46-cf6441b13f3c@oracle.com> Message-ID: <7eabd7a3-8d64-ad93-46c7-04a05048bd55@oracle.com> Hi Ivan, Looks fine. Interesting edge case, would never be seen with 8 bit charsets. Thanks, Roger On 3/21/20 3:15 AM, Ivan Gerasimov wrote: > Gentle ping. > > The webrev was rebased to accommodate recent changes in RegExTest.java. > > The fix is to handle an edge case situation, which is supposedly not > too common. > > Nevertheless, I think, it is important to handle it correctly. > > Thanks in advance! > > Ivan > > > On 1/22/20 8:23 PM, Ivan Gerasimov wrote: >> Hello everyone! >> >> When the input of a j.u.regex.Matcher is restricted with .region() >> method, it can possibly cut off a half of a surrogate pair. >> >> It turns out that greedy matching implemented in the >> Pattern.CharPropertyGreedy class fails to recognize this edge case in >> two scenarios: >> >> 1) When it greedily consumes the input and meets a higher half of a >> surrogate pair that was cut off at the end of input, and >> >> 2) When it backs off and meets a lower half of a surrogate pair at >> the very beginning of input. >> >> In both cases, the engine reads the entire codepoint, crossing the >> boundaries of the set region. >> >> Instead, it should only read the half of the surrogate pair that lies >> inside the region and ignore the other half. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8237599 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8237599/00/webrev/ >> >> Thanks in advance! >> From ivan.gerasimov at oracle.com Wed Mar 25 15:47:57 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 25 Mar 2020 08:47:57 -0700 Subject: RFR 8237599 : Greedy matching against supplementary chars fails to respect the region In-Reply-To: <7eabd7a3-8d64-ad93-46c7-04a05048bd55@oracle.com> References: <88a8bdd6-0791-0539-ff46-cf6441b13f3c@oracle.com> <7eabd7a3-8d64-ad93-46c7-04a05048bd55@oracle.com> Message-ID: Thank you Roger for review! On 3/25/20 6:56 AM, Roger Riggs wrote: > Hi Ivan, > > Looks fine. > > Interesting edge case, would never be seen with 8 bit charsets. > > Thanks, Roger > > > On 3/21/20 3:15 AM, Ivan Gerasimov wrote: >> Gentle ping. >> >> The webrev was rebased to accommodate recent changes in RegExTest.java. >> >> The fix is to handle an edge case situation, which is supposedly not >> too common. >> >> Nevertheless, I think, it is important to handle it correctly. >> >> Thanks in advance! >> >> Ivan >> >> >> On 1/22/20 8:23 PM, Ivan Gerasimov wrote: >>> Hello everyone! >>> >>> When the input of a j.u.regex.Matcher is restricted with .region() >>> method, it can possibly cut off a half of a surrogate pair. >>> >>> It turns out that greedy matching implemented in the >>> Pattern.CharPropertyGreedy class fails to recognize this edge case >>> in two scenarios: >>> >>> 1) When it greedily consumes the input and meets a higher half of a >>> surrogate pair that was cut off at the end of input, and >>> >>> 2) When it backs off and meets a lower half of a surrogate pair at >>> the very beginning of input. >>> >>> In both cases, the engine reads the entire codepoint, crossing the >>> boundaries of the set region. >>> >>> Instead, it should only read the half of the surrogate pair that >>> lies inside the region and ignore the other half. >>> >>> Would you please help review the fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8237599 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8237599/00/webrev/ >>> >>> Thanks in advance! >>> > -- With kind regards, Ivan Gerasimov From philipp.kunz at paratix.ch Wed Mar 25 18:52:21 2020 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Wed, 25 Mar 2020 19:52:21 +0100 Subject: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes In-Reply-To: <10485888-3ac8-c967-0131-08fe52d2694d@oracle.com> References: <44EE1961-6729-4F96-8885-439FED393A81@oracle.com> <026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch> <10485888-3ac8-c967-0131-08fe52d2694d@oracle.com> Message-ID: <6a4e59d2e0028d80da9655cb1f724697bd516461.camel@paratix.ch> Hi Naoto, See another patch attached with Locale.ROOT for the BreakIterator. I will be glad to hear of any feedback. There is another patch [1] around dealing with manifest attributes during application launch. It certainly is related to 6202130 but feels like a distinct set of changes with a slightly different concern. Any opinion as how to proceed with that one? Regards,Philipp [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-February/064720.html On Mon, 2020-03-23 at 09:05 -0700, naoto.sato at oracle.com wrote: > Hi Philipp, > Right, Locale.ROOT is more appropriate here by definition, though the > implementation is the same. > Naoto > On 3/21/20 5:19 AM, Philipp Kunz wrote: > > Hi Naoto and everyone, > > There are almost as many occurrences of Locale.ROOT as Locale.US > > which made me wonder which one is more appropriately locale- > > independent and which is probably another topic and not actually > > relevant here because BreakIterator.getCharacterInstance is locale- > > agnostic as far as I can tell. > > See attached patch with another attempt to fix bug 6202130. > > Regards,Philipp > > > > On Tue, 2020-03-10 at 10:45 -0700, naoto.sato at oracle.com wrote: > > > Hi Philipp, > > > ..., so using BreakIterator (withLocale.US) is more preferred > > > solution to me. > > > Naoto -------------- next part -------------- A non-text attachment was scrubbed... Name: 20200325-bug6202130-manifestutf8.patch Type: text/x-patch Size: 50108 bytes Desc: not available URL: From sergei.tsypanov at yandex.ru Wed Mar 25 21:18:54 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Wed, 25 Mar 2020 23:18:54 +0200 Subject: [PATCH] Trivial improvement for j.l.Character.toString() Message-ID: <10130881585167129@vla3-6a5326aeb4ee.qloud-c.yandex.net> Hello, I think we can reduce allocation rate for j.l.Character.toString() by calling String.valueOf(char) instead of String.valueOf(char[]). Current implementation creates char[] with one char which is later decoded into byte[]. Instead String.valueOf(char) decodes char directly consuming less memory. I've used benchmark [1] and on my machine got those results (JDK 14): Benchmark Mode Score Error Units CharacterToStringBenchmark.toString_utf8 avgt 14.723 ? 1.354 ns/op CharacterToStringBenchmark.valueOf_utf8 avgt 7.678 ? 0.601 ns/op CharacterToStringBenchmark.toString_latin avgt 10.992 ? 1.371 ns/op CharacterToStringBenchmark.valueOf_latin avgt 7.844 ? 1.044 ns/op CharacterToStringBenchmark.toString_utf8:?gc.alloc.rate.norm avgt 96.003 ? 0.001 B/op CharacterToStringBenchmark.valueOf_utf8:?gc.alloc.rate.norm avgt 48.002 ? 0.001 B/op CharacterToStringBenchmark.toString_latin:?gc.alloc.rate.norm avgt 72.003 ? 0.001 B/op CharacterToStringBenchmark.valueOf_latin:?gc.alloc.rate.norm avgt 48.002 ? 0.001 B/op Patch is below. With best regards, Sergey Tsypanov [1] https://github.com/stsypanov/strings/blob/master/src/jmh/java/tsypanov/strings/character/CharacterToStringBenchmark.java diff --git a/src/java.base/share/classes/java/lang/Character.java b/src/java.base/share/classes/java/lang/Character.java --- a/src/java.base/share/classes/java/lang/Character.java +++ b/src/java.base/share/classes/java/lang/Character.java @@ -3285,7 +3285,7 @@ "SYMBOLS AND PICTOGRAPHS EXTENDED-A", "SYMBOLSANDPICTOGRAPHSEXTENDED-A"); - private static final int blockStarts[] = { + private static final int[] blockStarts = { 0x0000, // 0000..007F; Basic Latin 0x0080, // 0080..00FF; Latin-1 Supplement 0x0100, // 0100..017F; Latin Extended-A @@ -8068,7 +8068,7 @@ UNKNOWN, // E01F0..10FFFF }; - private static HashMap aliases; + private static final HashMap aliases; static { aliases = new HashMap<>((int)(153 / 0.75f + 1.0f)); aliases.put("ADLM", ADLAM); @@ -8421,8 +8421,7 @@ * @return a string representation of this object. */ public String toString() { - char buf[] = {value}; - return String.valueOf(buf); + return toString(value); } /** From claes.redestad at oracle.com Wed Mar 25 21:53:15 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 25 Mar 2020 22:53:15 +0100 Subject: [PATCH] Trivial improvement for j.l.Character.toString() In-Reply-To: <10130881585167129@vla3-6a5326aeb4ee.qloud-c.yandex.net> References: <10130881585167129@vla3-6a5326aeb4ee.qloud-c.yandex.net> Message-ID: <77c281a8-6cd5-df79-f2f0-0f399741d116@oracle.com> Looks good and trivial, including the drive-by cleanups. I can sponsor. /Claes On 2020-03-25 22:18, ?????? ??????? wrote: > Hello, > > I think we can reduce allocation rate for j.l.Character.toString() by calling String.valueOf(char) instead of String.valueOf(char[]). > > Current implementation creates char[] with one char which is later decoded into byte[]. > > Instead String.valueOf(char) decodes char directly consuming less memory. I've used benchmark [1] > and on my machine got those results (JDK 14): > > Benchmark Mode Score Error Units > > CharacterToStringBenchmark.toString_utf8 avgt 14.723 ? 1.354 ns/op > CharacterToStringBenchmark.valueOf_utf8 avgt 7.678 ? 0.601 ns/op > > CharacterToStringBenchmark.toString_latin avgt 10.992 ? 1.371 ns/op > CharacterToStringBenchmark.valueOf_latin avgt 7.844 ? 1.044 ns/op > > CharacterToStringBenchmark.toString_utf8:?gc.alloc.rate.norm avgt 96.003 ? 0.001 B/op > CharacterToStringBenchmark.valueOf_utf8:?gc.alloc.rate.norm avgt 48.002 ? 0.001 B/op > > CharacterToStringBenchmark.toString_latin:?gc.alloc.rate.norm avgt 72.003 ? 0.001 B/op > CharacterToStringBenchmark.valueOf_latin:?gc.alloc.rate.norm avgt 48.002 ? 0.001 B/op > > > Patch is below. > > With best regards, > Sergey Tsypanov > > [1] https://github.com/stsypanov/strings/blob/master/src/jmh/java/tsypanov/strings/character/CharacterToStringBenchmark.java > > diff --git a/src/java.base/share/classes/java/lang/Character.java b/src/java.base/share/classes/java/lang/Character.java > --- a/src/java.base/share/classes/java/lang/Character.java > +++ b/src/java.base/share/classes/java/lang/Character.java > @@ -3285,7 +3285,7 @@ > "SYMBOLS AND PICTOGRAPHS EXTENDED-A", > "SYMBOLSANDPICTOGRAPHSEXTENDED-A"); > > - private static final int blockStarts[] = { > + private static final int[] blockStarts = { > 0x0000, // 0000..007F; Basic Latin > 0x0080, // 0080..00FF; Latin-1 Supplement > 0x0100, // 0100..017F; Latin Extended-A > @@ -8068,7 +8068,7 @@ > UNKNOWN, // E01F0..10FFFF > }; > > - private static HashMap aliases; > + private static final HashMap aliases; > static { > aliases = new HashMap<>((int)(153 / 0.75f + 1.0f)); > aliases.put("ADLM", ADLAM); > @@ -8421,8 +8421,7 @@ > * @return a string representation of this object. > */ > public String toString() { > - char buf[] = {value}; > - return String.valueOf(buf); > + return toString(value); > } > > /** > From Roger.Riggs at oracle.com Wed Mar 25 23:12:02 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 25 Mar 2020 19:12:02 -0400 Subject: [PATCH] Trivial improvement for j.l.Character.toString() In-Reply-To: <77c281a8-6cd5-df79-f2f0-0f399741d116@oracle.com> References: <10130881585167129@vla3-6a5326aeb4ee.qloud-c.yandex.net> <77c281a8-6cd5-df79-f2f0-0f399741d116@oracle.com> Message-ID: <4ff0c485-8e6e-af22-59af-c50be5824a19@oracle.com> Agreed,? +1 On 3/25/20 5:53 PM, Claes Redestad wrote: > Looks good and trivial, including the drive-by cleanups. > > I can sponsor. > > /Claes > > On 2020-03-25 22:18, ?????? ??????? wrote: >> Hello, >> >> I think we can reduce allocation rate for j.l.Character.toString() by >> calling String.valueOf(char) instead of String.valueOf(char[]). >> >> Current implementation creates char[] with one char which is later >> decoded into byte[]. >> >> Instead String.valueOf(char) decodes char directly consuming less >> memory. I've used benchmark [1] >> and on my machine got those results (JDK 14): >> >> Benchmark Mode??? Score???? Error?? Units >> >> CharacterToStringBenchmark.toString_utf8 avgt?? 14.723 ??? 1.354?? ns/op >> CharacterToStringBenchmark.valueOf_utf8 avgt??? 7.678 ??? 0.601?? ns/op >> >> CharacterToStringBenchmark.toString_latin avgt?? 10.992 ??? 1.371?? >> ns/op >> CharacterToStringBenchmark.valueOf_latin avgt??? 7.844 ??? 1.044?? ns/op >> >> CharacterToStringBenchmark.toString_utf8:?gc.alloc.rate.norm avgt?? >> 96.003 ??? 0.001??? B/op >> CharacterToStringBenchmark.valueOf_utf8:?gc.alloc.rate.norm avgt?? >> 48.002 ??? 0.001??? B/op >> >> CharacterToStringBenchmark.toString_latin:?gc.alloc.rate.norm avgt?? >> 72.003 ??? 0.001??? B/op >> CharacterToStringBenchmark.valueOf_latin:?gc.alloc.rate.norm avgt?? >> 48.002 ??? 0.001??? B/op >> >> >> Patch is below. >> >> With best regards, >> Sergey Tsypanov >> >> [1] >> https://github.com/stsypanov/strings/blob/master/src/jmh/java/tsypanov/strings/character/CharacterToStringBenchmark.java >> >> diff --git a/src/java.base/share/classes/java/lang/Character.java >> b/src/java.base/share/classes/java/lang/Character.java >> --- a/src/java.base/share/classes/java/lang/Character.java >> +++ b/src/java.base/share/classes/java/lang/Character.java >> @@ -3285,7 +3285,7 @@ >> ?????????????????????????????? "SYMBOLS AND PICTOGRAPHS EXTENDED-A", >> "SYMBOLSANDPICTOGRAPHSEXTENDED-A"); >> ? -??????? private static final int blockStarts[] = { >> +??????? private static final int[] blockStarts = { >> ????????????? 0x0000,?? // 0000..007F; Basic Latin >> ????????????? 0x0080,?? // 0080..00FF; Latin-1 Supplement >> ????????????? 0x0100,?? // 0100..017F; Latin Extended-A >> @@ -8068,7 +8068,7 @@ >> ????????????? UNKNOWN,????????????????? // E01F0..10FFFF >> ????????? }; >> ? -??????? private static HashMap >> aliases; >> +??????? private static final HashMap> Character.UnicodeScript> aliases; >> ????????? static { >> ????????????? aliases = new HashMap<>((int)(153 / 0.75f + 1.0f)); >> ????????????? aliases.put("ADLM", ADLAM); >> @@ -8421,8 +8421,7 @@ >> ?????? * @return? a string representation of this object. >> ?????? */ >> ????? public String toString() { >> -??????? char buf[] = {value}; >> -??????? return String.valueOf(buf); >> +??????? return toString(value); >> ????? } >> ? ????? /** >> From linzang at tencent.com Thu Mar 26 07:13:53 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Thu, 26 Mar 2020 07:13:53 +0000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> Message-ID: Dear All, May I ask your help to review this tiny fix? Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ Thanks! BRs, Lin From TOSHIONA at jp.ibm.com Thu Mar 26 08:58:05 2020 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Thu, 26 Mar 2020 17:58:05 +0900 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks Message-ID: Hi All, Could you review this change? Additionally, I'd like to ask a sponsor for it, since I'm not a committer. Bug: https://bugs.openjdk.java.net/browse/JDK-8232846 Webrev: http://cr.openjdk.java.net/~tnakamura/8232846/webrev.00 Under Windows environments, ProcessHandle.Info.command shows question marks if the command has non-English characters. I'd like to change the underlying API to Unicode version. Tier1 tests passed. Best regards, Toshio Nakamura From claes.redestad at oracle.com Thu Mar 26 09:10:15 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 26 Mar 2020 10:10:15 +0100 Subject: [PATCH] Trivial improvement for j.l.Character.toString() - 8241649: Optimize Character.toString In-Reply-To: <4ff0c485-8e6e-af22-59af-c50be5824a19@oracle.com> References: <10130881585167129@vla3-6a5326aeb4ee.qloud-c.yandex.net> <77c281a8-6cd5-df79-f2f0-0f399741d116@oracle.com> <4ff0c485-8e6e-af22-59af-c50be5824a19@oracle.com> Message-ID: <46a3b334-0dcd-6d11-53b4-f0a9f7dd68eb@oracle.com> Filed and pushed: https://bugs.openjdk.java.net/browse/JDK-8241649 /Claes On 2020-03-26 00:12, Roger Riggs wrote: > Agreed,? +1 > > On 3/25/20 5:53 PM, Claes Redestad wrote: >> Looks good and trivial, including the drive-by cleanups. >> >> I can sponsor. >> >> /Claes >> >> On 2020-03-25 22:18, ?????? ??????? wrote: >>> Hello, >>> >>> I think we can reduce allocation rate for j.l.Character.toString() by >>> calling String.valueOf(char) instead of String.valueOf(char[]). >>> >>> Current implementation creates char[] with one char which is later >>> decoded into byte[]. >>> >>> Instead String.valueOf(char) decodes char directly consuming less >>> memory. I've used benchmark [1] >>> and on my machine got those results (JDK 14): >>> >>> Benchmark Mode??? Score???? Error?? Units >>> >>> CharacterToStringBenchmark.toString_utf8 avgt?? 14.723 ??? 1.354?? ns/op >>> CharacterToStringBenchmark.valueOf_utf8 avgt??? 7.678 ??? 0.601?? ns/op >>> >>> CharacterToStringBenchmark.toString_latin avgt?? 10.992 ??? 1.371 ns/op >>> CharacterToStringBenchmark.valueOf_latin avgt??? 7.844 ??? 1.044?? ns/op >>> >>> CharacterToStringBenchmark.toString_utf8:?gc.alloc.rate.norm avgt >>> 96.003 ??? 0.001??? B/op >>> CharacterToStringBenchmark.valueOf_utf8:?gc.alloc.rate.norm avgt >>> 48.002 ??? 0.001??? B/op >>> >>> CharacterToStringBenchmark.toString_latin:?gc.alloc.rate.norm avgt >>> 72.003 ??? 0.001??? B/op >>> CharacterToStringBenchmark.valueOf_latin:?gc.alloc.rate.norm avgt >>> 48.002 ??? 0.001??? B/op >>> >>> >>> Patch is below. >>> >>> With best regards, >>> Sergey Tsypanov >>> >>> [1] >>> https://github.com/stsypanov/strings/blob/master/src/jmh/java/tsypanov/strings/character/CharacterToStringBenchmark.java >>> >>> >>> diff --git a/src/java.base/share/classes/java/lang/Character.java >>> b/src/java.base/share/classes/java/lang/Character.java >>> --- a/src/java.base/share/classes/java/lang/Character.java >>> +++ b/src/java.base/share/classes/java/lang/Character.java >>> @@ -3285,7 +3285,7 @@ >>> ?????????????????????????????? "SYMBOLS AND PICTOGRAPHS EXTENDED-A", >>> "SYMBOLSANDPICTOGRAPHSEXTENDED-A"); >>> ? -??????? private static final int blockStarts[] = { >>> +??????? private static final int[] blockStarts = { >>> ????????????? 0x0000,?? // 0000..007F; Basic Latin >>> ????????????? 0x0080,?? // 0080..00FF; Latin-1 Supplement >>> ????????????? 0x0100,?? // 0100..017F; Latin Extended-A >>> @@ -8068,7 +8068,7 @@ >>> ????????????? UNKNOWN,????????????????? // E01F0..10FFFF >>> ????????? }; >>> ? -??????? private static HashMap >>> aliases; >>> +??????? private static final HashMap>> Character.UnicodeScript> aliases; >>> ????????? static { >>> ????????????? aliases = new HashMap<>((int)(153 / 0.75f + 1.0f)); >>> ????????????? aliases.put("ADLM", ADLAM); >>> @@ -8421,8 +8421,7 @@ >>> ?????? * @return? a string representation of this object. >>> ?????? */ >>> ????? public String toString() { >>> -??????? char buf[] = {value}; >>> -??????? return String.valueOf(buf); >>> +??????? return toString(value); >>> ????? } >>> ? ????? /** >>> > From thomas.stuefe at gmail.com Thu Mar 26 09:44:10 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 26 Mar 2020 10:44:10 +0100 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: Message-ID: Hi Toshio, looks good to me. Cheers, Thomas On Thu, Mar 26, 2020 at 9:58 AM Toshio 5 Nakamura wrote: > > Hi All, > > Could you review this change? Additionally, I'd like to ask a sponsor for > it, since I'm not a committer. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232846 > Webrev: http://cr.openjdk.java.net/~tnakamura/8232846/webrev.00 > > Under Windows environments, ProcessHandle.Info.command shows question marks > if the command has non-English characters. I'd like to change the > underlying API to Unicode version. > Tier1 tests passed. > > Best regards, > Toshio Nakamura > From suenaga at oss.nttdata.com Thu Mar 26 10:37:19 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 26 Mar 2020 19:37:19 +0900 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: Message-ID: Hi Nakamura-san, Your change almost looks good, but I have one question. Length of exeName (1024) is enough? According to Microsoft Doc [1], exeName might not be null-terminated if it failed. I concern buffer overrun might occur when QueryFullProcessImageNameW failed. Thanks, Yasumasa [1] https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-queryfullprocessimagenamew On 2020/03/26 17:58, Toshio 5 Nakamura wrote: > > Hi All, > > Could you review this change? Additionally, I'd like to ask a sponsor for > it, since I'm not a committer. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232846 > Webrev: http://cr.openjdk.java.net/~tnakamura/8232846/webrev.00 > > Under Windows environments, ProcessHandle.Info.command shows question marks > if the command has non-English characters. I'd like to change the > underlying API to Unicode version. > Tier1 tests passed. > > Best regards, > Toshio Nakamura > From Roger.Riggs at oracle.com Thu Mar 26 13:48:20 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 26 Mar 2020 09:48:20 -0400 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: Message-ID: Hi, If the call fails, the command field in the info will not be set (and therefore null). I agree that a length of 512 (characters) is probably too small. Roger On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: > Hi Nakamura-san, > > Your change almost looks good, but I have one question. > Length of exeName (1024) is enough? > > According to Microsoft Doc [1], exeName might not be null-terminated > if it failed. > I concern buffer overrun might occur when QueryFullProcessImageNameW > failed. > > > Thanks, > > Yasumasa > > > [1] > https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-queryfullprocessimagenamew > > > On 2020/03/26 17:58, Toshio 5 Nakamura wrote: >> >> Hi All, >> >> Could you review this change? Additionally, I'd like to ask a sponsor >> for >> it, since I'm not a committer. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8232846 >> Webrev: http://cr.openjdk.java.net/~tnakamura/8232846/webrev.00 >> >> Under Windows environments, ProcessHandle.Info.command shows question >> marks >> if the command has non-English characters. I'd like to change the >> underlying API to Unicode version. >> Tier1 tests passed. >> >> Best regards, >> Toshio Nakamura >> From andy.herrick at oracle.com Thu Mar 26 13:58:46 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 26 Mar 2020 09:58:46 -0400 Subject: RFR: JDK-8241400: [macos] jpackageapplauncher/main.m built using CXXFLAGS_JDKEXE Message-ID: Please review the fix to issue [1] at [2]. Simple makefile fix. /Andy [1]: https://bugs.openjdk.java.net/browse/JDK-8241400 [2]: http://cr.openjdk.java.net/~herrick/8241400/webrev.01/ From TOSHIONA at jp.ibm.com Thu Mar 26 14:40:16 2020 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Thu, 26 Mar 2020 23:40:16 +0900 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: Message-ID: Hi Thomas, Suenaga-san, Roger, Thank you for reviewing and comments. I checked behaviors by a small program and debugger. If QueryFullProcessImageNameW failed by not enough buffer, the API didn't change the buffer. It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. The buffer size becomes 1024 characters (2048 bytes) by this patch. Should it use bigger size with malloc? 32,767 characters can be limit [2]. I feel 1024 is reasonable value for command's location. [2] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation Best regards, Toshio Nakamura > Hi, > > If the call fails, the command field in the info will not be set (and > therefore null). > > I agree that a length of 512 (characters) is probably too small. > > Roger > > > On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: > > Hi Nakamura-san, > > > > Your change almost looks good, but I have one question. > > Length of exeName (1024) is enough? > > > > According to Microsoft Doc [1], exeName might not be null-terminated > > if it failed. > > I concern buffer overrun might occur when QueryFullProcessImageNameW > > failed. > > > > > > Thanks, > > > > Yasumasa > > > > > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_api_winbase_nf-2Dwinbase-2Dqueryfullprocessimagenamew&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=oc_KTGmJUjsfnLf3tjWr9DO1dwWp1TqIZgd2EiHVW14&e= > > > > > > On 2020/03/26 17:58, Toshio 5 Nakamura wrote: > >> > >> Hi All, > >> > >> Could you review this change? Additionally, I'd like to ask a sponsor > >> for > >> it, since I'm not a committer. > >> > >> Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232846&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=pn_uS0DojBk6-R6R5QwtYFJvJpaabhia-eiOtIrJO9Q&e= > >> Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=NylYK0Q3nFFZRVIaeUna6iaClaJm1CWJ2Zkwy-ysvv4&e= > >> > >> Under Windows environments, ProcessHandle.Info.command shows question > >> marks > >> if the command has non-English characters. I'd like to change the > >> underlying API to Unicode version. > >> Tier1 tests passed. > >> > >> Best regards, > >> Toshio Nakamura > >> > From erik.joelsson at oracle.com Thu Mar 26 14:46:51 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Mar 2020 07:46:51 -0700 Subject: RFR: JDK-8241400: [macos] jpackageapplauncher/main.m built using CXXFLAGS_JDKEXE In-Reply-To: References: Message-ID: Looks good. /Erik On 2020-03-26 06:58, Andy Herrick wrote: > Please review the fix to issue [1] at [2]. > > Simple makefile fix. > > /Andy > > [1]: https://bugs.openjdk.java.net/browse/JDK-8241400 > > [2]: http://cr.openjdk.java.net/~herrick/8241400/webrev.01/ > From sverre.moe at gmail.com Thu Mar 26 15:17:51 2020 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 26 Mar 2020 16:17:51 +0100 Subject: jpackage Are the RPM Requires necessary? Message-ID: Running jpackage to build an RPM will add some Requires to the package. It comes from the Template file: https://github.com/openjdk/jdk/blob/jdk-14%2B36/src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/resources/template.spec Autoprov: 0 Autoreq: 0 %if "xPACKAGE_DEFAULT_DEPENDENCIES" != x || "xPACKAGE_CUSTOM_DEPENDENCIES" != x Requires: PACKAGE_DEFAULT_DEPENDENCIES PACKAGE_CUSTOM_DEPENDENCIES %endif Building on OpenSUSE will give us these Requires: +%if "xglibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, libXtst6, libasound2, libxcb1, libz1" != x || "x" != x +Requires: glibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, libXtst6, libasound2, libxcb1, libz1 +%endif + +#avoid ARCH subfolder We override the RPM spec file with resource directory. I copied the RPM spec file content from the one jpackage generated and added something extra to it. Unfortunately this RPM will not install on Fedora, but installs fine on OpenSUSE where I built it. Installing on Fedora will spew out this line for all these Requires. nothing provides libX11-6 Are these Requires needed by Java? What is the consequences if these are not available on the system installing the RPM? It is an JavaFX application we are packaging. /Sverre From Roger.Riggs at oracle.com Thu Mar 26 15:35:30 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 26 Mar 2020 11:35:30 -0400 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: Message-ID: Hi, Reading further down the reference to the section: "Enable Long Paths in Windows 10, Version 1607, and Later" might suggest the code be more resilient to long paths. The stack allocated buffer (1024) is fine, but I'd suggest adding code to retry in the case of INSUFFICIENT BUFFER with a malloc'd buffer to make it more robust since the enabling of long paths is environment and application specific. Thanks, Roger On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: > Hi Thomas, Suenaga-san, Roger, > > Thank you for reviewing and comments. > > I checked behaviors by a small program and debugger. > If QueryFullProcessImageNameW failed by not enough buffer, > the API didn't change the buffer. > It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. > > The buffer size becomes 1024 characters (2048 bytes) by this patch. > Should it use bigger size with malloc? 32,767 characters can be limit [2]. > I feel 1024 is reasonable value for command's location. > > [2] > https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation > > Best regards, > Toshio Nakamura > >> Hi, >> >> If the call fails, the command field in the info will not be set (and >> therefore null). >> >> I agree that a length of 512 (characters) is probably too small. >> >> Roger >> >> >> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: >>> Hi Nakamura-san, >>> >>> Your change almost looks good, but I have one question. >>> Length of exeName (1024) is enough? >>> >>> According to Microsoft Doc [1], exeName might not be null-terminated >>> if it failed. >>> I concern buffer overrun might occur when QueryFullProcessImageNameW >>> failed. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] > https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_api_winbase_nf-2Dwinbase-2Dqueryfullprocessimagenamew&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=oc_KTGmJUjsfnLf3tjWr9DO1dwWp1TqIZgd2EiHVW14&e= > >>> >>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: >>>> Hi All, >>>> >>>> Could you review this change? Additionally, I'd like to ask a sponsor >>>> for >>>> it, since I'm not a committer. >>>> >>>> Bug: > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232846&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=pn_uS0DojBk6-R6R5QwtYFJvJpaabhia-eiOtIrJO9Q&e= > >>>> Webrev: > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=NylYK0Q3nFFZRVIaeUna6iaClaJm1CWJ2Zkwy-ysvv4&e= > >>>> Under Windows environments, ProcessHandle.Info.command shows question >>>> marks >>>> if the command has non-English characters. I'd like to change the >>>> underlying API to Unicode version. >>>> Tier1 tests passed. >>>> >>>> Best regards, >>>> Toshio Nakamura >>>> From alexey.semenyuk at oracle.com Thu Mar 26 19:39:06 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 26 Mar 2020 15:39:06 -0400 Subject: jpackage Are the RPM Requires necessary? In-Reply-To: References: Message-ID: <2246a9bd-42d9-63e7-4a9c-e1df8dbeff80@oracle.com> On 3/26/2020 11:17 AM, Sverre Moe wrote: > Running jpackage to build an RPM will add some Requires to the package. > > It comes from the Template file: > https://github.com/openjdk/jdk/blob/jdk-14%2B36/src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/resources/template.spec > > Autoprov: 0 > Autoreq: 0 > %if "xPACKAGE_DEFAULT_DEPENDENCIES" != x || "xPACKAGE_CUSTOM_DEPENDENCIES" > != x > Requires: PACKAGE_DEFAULT_DEPENDENCIES PACKAGE_CUSTOM_DEPENDENCIES > %endif > > Building on OpenSUSE will give us these Requires: > +%if "xglibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, libXtst6, > libasound2, libxcb1, libz1" != x || "x" != x > +Requires: glibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, > libXtst6, libasound2, libxcb1, libz1 > +%endif > + > +#avoid ARCH subfolder > > We override the RPM spec file with resource directory. I copied the RPM > spec file content from the one jpackage generated and added something extra > to it. > > Unfortunately this RPM will not install on Fedora, but installs fine on > OpenSUSE where I built it. > > Installing on Fedora will spew out this line for all these Requires. > nothing provides libX11-6 > > Are these Requires needed by Java? Yes. The list of required packages is built automatically by jpackage by analyzing dependencies of dynamic libraries of JRE bundled with the application being packed. On different distributes the same package can have different names. Seems like the package that is named on OpenSuSE as ' libX11-6' is named as 'libX11' on Fedora. > What is the consequences if these are > not available on the system installing the RPM? Installation will fail. - Alexey > It is an JavaFX application we are packaging. > > /Sverre From sverre.moe at gmail.com Thu Mar 26 20:13:16 2020 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 26 Mar 2020 21:13:16 +0100 Subject: jpackage Are the RPM Requires necessary? In-Reply-To: <2246a9bd-42d9-63e7-4a9c-e1df8dbeff80@oracle.com> References: <2246a9bd-42d9-63e7-4a9c-e1df8dbeff80@oracle.com> Message-ID: tor. 26. mar. 2020 kl. 20:41 skrev Alexey Semenyuk < alexey.semenyuk at oracle.com>: > > > On 3/26/2020 11:17 AM, Sverre Moe wrote: > > Running jpackage to build an RPM will add some Requires to the package. > > > > It comes from the Template file: > > > https://github.com/openjdk/jdk/blob/jdk-14%2B36/src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/resources/template.spec > > > > Autoprov: 0 > > Autoreq: 0 > > %if "xPACKAGE_DEFAULT_DEPENDENCIES" != x || > "xPACKAGE_CUSTOM_DEPENDENCIES" > > != x > > Requires: PACKAGE_DEFAULT_DEPENDENCIES PACKAGE_CUSTOM_DEPENDENCIES > > %endif > > > > Building on OpenSUSE will give us these Requires: > > +%if "xglibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, libXtst6, > > libasound2, libxcb1, libz1" != x || "x" != x > > +Requires: glibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, > > libXtst6, libasound2, libxcb1, libz1 > > +%endif > > + > > +#avoid ARCH subfolder > > > > We override the RPM spec file with resource directory. I copied the RPM > > spec file content from the one jpackage generated and added something > extra > > to it. > > > > Unfortunately this RPM will not install on Fedora, but installs fine on > > OpenSUSE where I built it. > > > > Installing on Fedora will spew out this line for all these Requires. > > nothing provides libX11-6 > > > > Are these Requires needed by Java? > Yes. The list of required packages is built automatically by jpackage by > analyzing dependencies of dynamic libraries of JRE bundled with the > application being packed. > On different distributes the same package can have different names. > Seems like the package that is named on OpenSuSE as ' libX11-6' is named > as 'libX11' on Fedora. > Not all Requires for OpenSUSE had an equivalent Fedoroa Requires Requires for OpenSUSE from jpackage Requires: glibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, libXtst6, libasound2, libxcb1, libz1 Requires for Fedora from jpackage: Requires: glibc, libX11, libXau, libXext, libXi, libXrender, libXtst, libxcbs The RPM spec for Fedora does not get any Requires with libasound and libz. > > What is the consequences if these are > > not available on the system installing the RPM? > Installation will fail. > Yes of course, if it has Requires and the Requires is not present, that is the problem we now got on Fedora for the installer built in OpenSUSE. However, if I omit all these Requires, then RPM will install/unpackage the application just fine. What you are saying if any of these Requires is not present then the install/unpack of the RPM will fail? So these Requires are only necessary for the RPM installation process? We previously uses jpackager, and did not specify these Requires when building the installer. Installation worked fine though on both OpenSUSE and Fedore. Probably because these Requires where installed as default on those systems. /Sverre From alexey.semenyuk at oracle.com Thu Mar 26 20:27:37 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 26 Mar 2020 16:27:37 -0400 Subject: jpackage Are the RPM Requires necessary? In-Reply-To: References: <2246a9bd-42d9-63e7-4a9c-e1df8dbeff80@oracle.com> Message-ID: <6c072414-3c33-9b7a-29f0-6e039a80c097@oracle.com> On 3/26/2020 4:13 PM, Sverre Moe wrote: > tor. 26. mar. 2020 kl. 20:41 skrev Alexey Semenyuk > >: > > > > On 3/26/2020 11:17 AM, Sverre Moe wrote: > > Running jpackage to build an RPM will add some Requires to the > package. > > > > It comes from the Template file: > > > https://github.com/openjdk/jdk/blob/jdk-14%2B36/src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/resources/template.spec > > > > > Autoprov: 0 > > Autoreq: 0 > > %if "xPACKAGE_DEFAULT_DEPENDENCIES" != x || > "xPACKAGE_CUSTOM_DEPENDENCIES" > > != x > > Requires: PACKAGE_DEFAULT_DEPENDENCIES PACKAGE_CUSTOM_DEPENDENCIES > > %endif > > > > Building on OpenSUSE will give us these Requires: > > +%if "xglibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, > libXtst6, > > libasound2, libxcb1, libz1" != x || "x" != x > > +Requires: glibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, > > libXtst6, libasound2, libxcb1, libz1 > > +%endif > > + > > +#avoid ARCH subfolder > > > > We override the RPM spec file with resource directory. I copied > the RPM > > spec file content from the one jpackage generated and added > something extra > > to it. > > > > Unfortunately this RPM will not install on Fedora, but installs > fine on > > OpenSUSE where I built it. > > > > Installing on Fedora will spew out this line for all these Requires. > > nothing provides libX11-6 > > > > Are these Requires needed by Java? > Yes. The list of required packages is built automatically by > jpackage by > analyzing dependencies of dynamic libraries of JRE bundled with the > application being packed. > On different distributes the same package can have different names. > Seems like the package that is named on OpenSuSE as ' libX11-6' is > named > as 'libX11' on Fedora. > > > Not all Requires for OpenSUSE had an equivalent Fedoroa?Requires > > Requires for OpenSUSE from jpackage > Requires: glibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, > libXtst6, libasound2, libxcb1, libz1 > > Requires for Fedora from jpackage: > Requires: glibc, libX11, libXau, libXext, libXi, libXrender, libXtst, > libxcbs > > The RPM spec for Fedora does not get any Requires with libasound and libz. Probably this is because these packages are not installed on Fedora host where you run jpackage. > > What is the consequences if these are > > not available on the system installing the RPM? > Installation will fail. > > Yes of course, if it has Requires and the Requires is not present, > that is the problem we now got on Fedora for the installer built in > OpenSUSE. > However, if I omit all these Requires, then RPM will install/unpackage > the application just fine. What you are saying if any of these > Requires is not present then the install/unpack of the RPM will fail? Correct. Sorry for the confusion. > So these Requires are only necessary for the RPM installation process? Yes. > > We previously uses jpackager, and did not specify these Requires when > building the installer. Installation worked fine though on both > OpenSUSE and Fedore. Probably because these Requires where installed > as default on those systems. If installed app depends on missing packages it will fail to operate. The idea of providing the list of required packages is to verify the app will run at installation phase. - Alexey > /Sverre From joe.darcy at oracle.com Thu Mar 26 20:41:03 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 26 Mar 2020 13:41:03 -0700 Subject: [15] RFR: 8214694: cleanup rawtypes warnings in open jndi tests In-Reply-To: <29BE8612-A772-45AC-AEB3-55C5C3FBAED0@oracle.com> References: <29BE8612-A772-45AC-AEB3-55C5C3FBAED0@oracle.com> Message-ID: Hi Chris, The changes don't appear incorrect, but at least from a cursory inspection, they don't appear as precise as they could be. Usually generifying a classes like this will next yield a round of redundant "cast" warnings; in my cleanup efforts, getting cast warnings was usually a sign the right generifiation was found. HTH, -Joe On 3/25/2020 12:57 AM, Chris Yin wrote: > Hello > > Please review following simple changes to cleanup raw types warning for open jndi tests (under test/jdk/com/sun/jndi and test/jdk/javax/naming), thanks > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214694 > Webrev: http://cr.openjdk.java.net/~xyin/8214694/webrev.00/ > > > The changes should be straightforward, only fix raw types warnings, no test logic change, no code optimization or cleanup. Minor change to each test file, just a little surprised about the affected tests count, hope this covers all. Run related jndi tests on 4 platforms for total 200 times, all passed. > > Thanks, > Chris From naoto.sato at oracle.com Thu Mar 26 21:14:51 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 26 Mar 2020 14:14:51 -0700 Subject: RFR: 8241055: Regex Grapheme Matcher Performance Depends too much on Total Input Sequence Size In-Reply-To: <76d3dbae877bf81bf3841fbefe01c4b956832074.camel@paratix.ch> References: <76d3dbae877bf81bf3841fbefe01c4b956832074.camel@paratix.ch> Message-ID: Hi Philipp, I looked at the patch, and it looks good to me. As to the test case, since it is measuring the performance, I would make it in a JMH test. Maybe you would want to put it similar to open/test/micro/org/openjdk/bench/java/util/regex/PatternBench.java Minor suggestion: I would rather rename "getGraphemeType()" to just "getType()", as it is simply retrieving the character type. Naoto On 3/21/20 7:58 AM, Philipp Kunz wrote: > Hi, > > Any opinions on the attached patch or someone tempted to sponsor it? > > Regards, > Philipp From sverre.moe at gmail.com Thu Mar 26 22:21:54 2020 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 26 Mar 2020 23:21:54 +0100 Subject: jpackage Are the RPM Requires necessary? In-Reply-To: <6c072414-3c33-9b7a-29f0-6e039a80c097@oracle.com> References: <2246a9bd-42d9-63e7-4a9c-e1df8dbeff80@oracle.com> <6c072414-3c33-9b7a-29f0-6e039a80c097@oracle.com> Message-ID: tor. 26. mar. 2020 kl. 21:29 skrev Alexey Semenyuk < alexey.semenyuk at oracle.com>: > > > On 3/26/2020 4:13 PM, Sverre Moe wrote: > > tor. 26. mar. 2020 kl. 20:41 skrev Alexey Semenyuk < > alexey.semenyuk at oracle.com>: > >> >> >> On 3/26/2020 11:17 AM, Sverre Moe wrote: >> > Running jpackage to build an RPM will add some Requires to the package. >> > >> > It comes from the Template file: >> > >> https://github.com/openjdk/jdk/blob/jdk-14%2B36/src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/resources/template.spec >> >> > >> > Autoprov: 0 >> > Autoreq: 0 >> > %if "xPACKAGE_DEFAULT_DEPENDENCIES" != x || >> "xPACKAGE_CUSTOM_DEPENDENCIES" >> > != x >> > Requires: PACKAGE_DEFAULT_DEPENDENCIES PACKAGE_CUSTOM_DEPENDENCIES >> > %endif >> > >> > Building on OpenSUSE will give us these Requires: >> > +%if "xglibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, >> libXtst6, >> > libasound2, libxcb1, libz1" != x || "x" != x >> > +Requires: glibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, >> > libXtst6, libasound2, libxcb1, libz1 >> > +%endif >> > + >> > +#avoid ARCH subfolder >> > >> > We override the RPM spec file with resource directory. I copied the RPM >> > spec file content from the one jpackage generated and added something >> extra >> > to it. >> > >> > Unfortunately this RPM will not install on Fedora, but installs fine on >> > OpenSUSE where I built it. >> > >> > Installing on Fedora will spew out this line for all these Requires. >> > nothing provides libX11-6 >> > >> > Are these Requires needed by Java? >> Yes. The list of required packages is built automatically by jpackage by >> analyzing dependencies of dynamic libraries of JRE bundled with the >> application being packed. >> On different distributes the same package can have different names. >> Seems like the package that is named on OpenSuSE as ' libX11-6' is named >> as 'libX11' on Fedora. >> > > Not all Requires for OpenSUSE had an equivalent Fedoroa Requires > > Requires for OpenSUSE from jpackage > Requires: glibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, > libXtst6, libasound2, libxcb1, libz1 > > Requires for Fedora from jpackage: > Requires: glibc, libX11, libXau, libXext, libXi, libXrender, libXtst, > libxcb > > The RPM spec for Fedora does not get any Requires with libasound and libz. > > Probably this is because these packages are not installed on Fedora host > where you run jpackage. > > Actually, the "missing" packages from Fedora RPM Spec generated by jpackage, the libasound and libz does not exist on Fedora 30. Makes me wonder, because the RPM installs fine on Fedora without these. /Sverre From sverre.moe at gmail.com Thu Mar 26 22:23:08 2020 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 26 Mar 2020 23:23:08 +0100 Subject: jpackage Are the RPM Requires necessary? In-Reply-To: References: <2246a9bd-42d9-63e7-4a9c-e1df8dbeff80@oracle.com> <6c072414-3c33-9b7a-29f0-6e039a80c097@oracle.com> Message-ID: tor. 26. mar. 2020 kl. 23:21 skrev Sverre Moe : > tor. 26. mar. 2020 kl. 21:29 skrev Alexey Semenyuk < > alexey.semenyuk at oracle.com>: > >> >> >> On 3/26/2020 4:13 PM, Sverre Moe wrote: >> >> tor. 26. mar. 2020 kl. 20:41 skrev Alexey Semenyuk < >> alexey.semenyuk at oracle.com>: >> >>> >>> >>> On 3/26/2020 11:17 AM, Sverre Moe wrote: >>> > Running jpackage to build an RPM will add some Requires to the package. >>> > >>> > It comes from the Template file: >>> > >>> https://github.com/openjdk/jdk/blob/jdk-14%2B36/src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/resources/template.spec >>> >>> > >>> > Autoprov: 0 >>> > Autoreq: 0 >>> > %if "xPACKAGE_DEFAULT_DEPENDENCIES" != x || >>> "xPACKAGE_CUSTOM_DEPENDENCIES" >>> > != x >>> > Requires: PACKAGE_DEFAULT_DEPENDENCIES PACKAGE_CUSTOM_DEPENDENCIES >>> > %endif >>> > >>> > Building on OpenSUSE will give us these Requires: >>> > +%if "xglibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, >>> libXtst6, >>> > libasound2, libxcb1, libz1" != x || "x" != x >>> > +Requires: glibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, >>> > libXtst6, libasound2, libxcb1, libz1 >>> > +%endif >>> > + >>> > +#avoid ARCH subfolder >>> > >>> > We override the RPM spec file with resource directory. I copied the RPM >>> > spec file content from the one jpackage generated and added something >>> extra >>> > to it. >>> > >>> > Unfortunately this RPM will not install on Fedora, but installs fine on >>> > OpenSUSE where I built it. >>> > >>> > Installing on Fedora will spew out this line for all these Requires. >>> > nothing provides libX11-6 >>> > >>> > Are these Requires needed by Java? >>> Yes. The list of required packages is built automatically by jpackage by >>> analyzing dependencies of dynamic libraries of JRE bundled with the >>> application being packed. >>> On different distributes the same package can have different names. >>> Seems like the package that is named on OpenSuSE as ' libX11-6' is named >>> as 'libX11' on Fedora. >>> >> >> Not all Requires for OpenSUSE had an equivalent Fedoroa Requires >> >> Requires for OpenSUSE from jpackage >> Requires: glibc, libX11-6, libXau6, libXext6, libXi6, libXrender1, >> libXtst6, libasound2, libxcb1, libz1 >> >> Requires for Fedora from jpackage: >> Requires: glibc, libX11, libXau, libXext, libXi, libXrender, libXtst, >> libxcb >> >> The RPM spec for Fedora does not get any Requires with libasound and libz. >> >> Probably this is because these packages are not installed on Fedora host >> where you run jpackage. >> >> Actually, the "missing" packages from Fedora RPM Spec generated by > jpackage, the libasound and libz does not exist on Fedora 30. > Makes me wonder, because the RPM installs fine on Fedora without these. > > /Sverre > Though there could be a different package that provides these two on Fedora, but then jpackage should have mention that package. /Sverre From alexey.semenyuk at oracle.com Thu Mar 26 22:24:37 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 26 Mar 2020 18:24:37 -0400 Subject: jpackage Are the RPM Requires necessary? In-Reply-To: References: <2246a9bd-42d9-63e7-4a9c-e1df8dbeff80@oracle.com> <6c072414-3c33-9b7a-29f0-6e039a80c097@oracle.com> Message-ID: <9998ae34-0486-6b1c-fe7c-7aa7326b4e79@oracle.com> On 3/26/2020 6:23 PM, Sverre Moe wrote: > tor. 26. mar. 2020 kl. 23:21 skrev Sverre Moe >: > > tor. 26. mar. 2020 kl. 21:29 skrev Alexey Semenyuk > >: > > > > On 3/26/2020 4:13 PM, Sverre Moe wrote: >> tor. 26. mar. 2020 kl. 20:41 skrev Alexey Semenyuk >> >: >> >> >> >> On 3/26/2020 11:17 AM, Sverre Moe wrote: >> > Running jpackage to build an RPM will add some Requires >> to the package. >> > >> > It comes from the Template file: >> > >> https://github.com/openjdk/jdk/blob/jdk-14%2B36/src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/resources/template.spec >> >> > >> > Autoprov: 0 >> > Autoreq: 0 >> > %if "xPACKAGE_DEFAULT_DEPENDENCIES" != x || >> "xPACKAGE_CUSTOM_DEPENDENCIES" >> > != x >> > Requires: PACKAGE_DEFAULT_DEPENDENCIES >> PACKAGE_CUSTOM_DEPENDENCIES >> > %endif >> > >> > Building on OpenSUSE will give us these Requires: >> > +%if "xglibc, libX11-6, libXau6, libXext6, libXi6, >> libXrender1, libXtst6, >> > libasound2, libxcb1, libz1" != x || "x" != x >> > +Requires: glibc, libX11-6, libXau6, libXext6, libXi6, >> libXrender1, >> > libXtst6, libasound2, libxcb1, libz1 >> > +%endif >> > + >> > +#avoid ARCH subfolder >> > >> > We override the RPM spec file with resource directory. >> I copied the RPM >> > spec file content from the one jpackage generated and >> added something extra >> > to it. >> > >> > Unfortunately this RPM will not install on Fedora, but >> installs fine on >> > OpenSUSE where I built it. >> > >> > Installing on Fedora will spew out this line for all >> these Requires. >> > nothing provides libX11-6 >> > >> > Are these Requires needed by Java? >> Yes. The list of required packages is built automatically >> by jpackage by >> analyzing dependencies of dynamic libraries of JRE >> bundled with the >> application being packed. >> On different distributes the same package can have >> different names. >> Seems like the package that is named on OpenSuSE as ' >> libX11-6' is named >> as 'libX11' on Fedora. >> >> >> Not all Requires for OpenSUSE had an equivalent Fedoroa?Requires >> >> Requires for OpenSUSE from jpackage >> Requires: glibc, libX11-6, libXau6, libXext6, libXi6, >> libXrender1, libXtst6, libasound2, libxcb1, libz1 >> >> Requires for Fedora from jpackage: >> Requires: glibc, libX11, libXau, libXext, libXi, libXrender, >> libXtst, libxcb >> >> The RPM spec for Fedora does not get any Requires with >> libasound and libz. > Probably this is because these packages are not installed on > Fedora host where you run jpackage. > > Actually, the "missing" packages from Fedora RPM Spec generated by > jpackage, the libasound and libz does not exist on Fedora 30. > Makes me wonder, because the RPM installs fine on Fedora without > these. > > /Sverre > > > Though there could be a different package that provides these two on > Fedora, but then jpackage should have mention that package. I can't comment on this without seeing jpackage log. - Alexey > > /Sverre From suenaga at oss.nttdata.com Thu Mar 26 23:55:37 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 27 Mar 2020 08:55:37 +0900 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: Message-ID: On 2020/03/27 0:35, Roger Riggs wrote: > Hi, > > Reading further down the reference to the section: > "Enable Long Paths in Windows 10, Version 1607, and Later" > might suggest the code be more resilient to long paths. > > The stack allocated buffer (1024) is fine, but I'd suggest adding code to retry in the case > of INSUFFICIENT BUFFER with a malloc'd buffer to make it more robust since the enabling > of long paths is environment and application specific. In addition, it's better to throw an exception if the call failed due to other error code. Thanks, Yasumasa > Thanks, Roger > > > > On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: >> Hi Thomas, Suenaga-san, Roger, >> >> Thank you for reviewing and comments. >> >> I checked behaviors by a small program and debugger. >> If QueryFullProcessImageNameW failed by not enough buffer, >> the API didn't change the buffer. >> It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. >> >> The buffer size becomes 1024 characters (2048 bytes) by this patch. >> Should it use bigger size with malloc? 32,767 characters can be limit [2]. >> I feel 1024 is reasonable value for command's location. >> >> [2] >> https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation >> >> Best regards, >> Toshio Nakamura >> >>> Hi, >>> >>> If the call fails, the command field in the info will not be set (and >>> therefore null). >>> >>> I agree that a length of 512 (characters) is probably too small. >>> >>> Roger >>> >>> >>> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: >>>> Hi Nakamura-san, >>>> >>>> Your change almost looks good, but I have one question. >>>> Length of exeName (1024) is enough? >>>> >>>> According to Microsoft Doc [1], exeName might not be null-terminated >>>> if it failed. >>>> I concern buffer overrun might occur when QueryFullProcessImageNameW >>>> failed. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_api_winbase_nf-2Dwinbase-2Dqueryfullprocessimagenamew&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=oc_KTGmJUjsfnLf3tjWr9DO1dwWp1TqIZgd2EiHVW14&e= >> >>>> >>>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: >>>>> Hi All, >>>>> >>>>> Could you review this change? Additionally, I'd like to ask a sponsor >>>>> for >>>>> it, since I'm not a committer. >>>>> >>>>> Bug: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232846&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=pn_uS0DojBk6-R6R5QwtYFJvJpaabhia-eiOtIrJO9Q&e= >> >>>>> Webrev: >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=NylYK0Q3nFFZRVIaeUna6iaClaJm1CWJ2Zkwy-ysvv4&e= >> >>>>> Under Windows environments, ProcessHandle.Info.command shows question >>>>> marks >>>>> if the command has non-English characters. I'd like to change the >>>>> underlying API to Unicode version. >>>>> Tier1 tests passed. >>>>> >>>>> Best regards, >>>>> Toshio Nakamura >>>>> > From mandy.chung at oracle.com Thu Mar 26 23:57:39 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 Mar 2020 16:57:39 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes Message-ID: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Please review the implementation of JEP 371: Hidden Classes. The main changes are in core-libs and hotspot runtime area.? Small changes are made in javac, VM compiler (intrinsification of Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized state (see specdiff and javadoc below for reference). Webrev: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point of view, a hidden class is a normal class except the following: - A hidden class has no initiating class loader and is not registered in any dictionary. - A hidden class has a name containing an illegal character `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` returns "Lp/Foo.0x1234;". - A hidden class is not modifiable, i.e. cannot be redefined or retransformed. JVM TI IsModifableClass returns false on a hidden. - Final fields in a hidden class is "final".? The value of final fields cannot be overriden via reflection.? setAccessible(true) can still be called on reflected objects representing final fields in a hidden class and its access check will be suppressed but only have read-access (i.e. can do Field::getXXX but not setXXX). Brief summary of this patch: 1. A new Lookup::defineHiddenClass method is the API to create a hidden class. 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG option that ?? can be specified when creating a hidden class. 3. A new Class::isHiddenClass method tests if a class is a hidden class. 4. Field::setXXX method will throw IAE on a final field of a hidden class ?? regardless of the value of the accessible flag. 5. JVM_LookupDefineClass is the new JVM entry point for Lookup::defineClass ?? and defineHiddenClass to create a class from the given bytes. 6. ClassLoaderData implementation is not changed.? There is one primary CLD ?? that holds the classes strongly referenced by its defining loader.? There ?? can be zero or more additional CLDs - one per weak class. 7. Nest host determination is updated per revised JVMS 5.4.4. Access control ?? check no longer throws LinkageError but instead it will throw IAE with ?? a clear message if a class fails to resolve/validate the nest host declared ?? in NestHost/NestMembers attribute. 8. JFR, jcmd, JDI are updated to support hidden classes. 9. update javac LambdaToMethod as lambda proxy starts using nestmates ?? and generate a bridge method to desuger a method reference to a protected ?? method in its supertype in a different package This patch also updates StringConcatFactory, LambdaMetaFactory, and LambdaForms to use hidden classes.? The webrev includes changes in nashorn to hidden class and I will update the webrev if JEP 372 removes it any time soon. We uncovered a bug in Lookup::defineClass spec throws LinkageError and intends to have the newly created class linked.? However, the implementation in 14 does not link the class.? A separate CSR [2] proposes to update the implementation to match the spec.? This patch fixes the implementation. The spec update on JVM TI, JDI and Instrumentation will be done as a separate RFE [3].? This patch includes new tests for JVM TI and java.instrument that validates how the existing APIs work for hidden classes. javadoc/specdiff http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ JVMS 5.4.4 change: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf CSR: https://bugs.openjdk.java.net/browse/JDK-8238359 Thanks Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8238359 [2] https://bugs.openjdk.java.net/browse/JDK-8240338 [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From Roger.Riggs at oracle.com Fri Mar 27 00:01:26 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 26 Mar 2020 20:01:26 -0400 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: Message-ID: <063fb628-a25d-500a-b495-c6a7364bb2de@oracle.com> Hi, Please don't throw an exception. It would abort being able to provide any information. And who would expect or handle such an exception? Degrading the info or omitting it provides better service overall. There is no point to throwing an exception. Regards, Roger On 3/26/20 7:55 PM, Yasumasa Suenaga wrote: > On 2020/03/27 0:35, Roger Riggs wrote: >> Hi, >> >> Reading further down the reference to the section: >> "Enable Long Paths in Windows 10, Version 1607, and Later" >> might suggest the code be more resilient to long paths. >> >> The stack allocated buffer (1024) is fine, but I'd suggest adding >> code to retry in the case >> of INSUFFICIENT BUFFER with a malloc'd buffer to make it more robust >> since the enabling >> of long paths is environment and application specific. > > In addition, it's better to throw an exception if the call failed due > to other error code. > > Thanks, > > Yasumasa > > >> Thanks, Roger >> >> >> >> On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: >>> Hi Thomas, Suenaga-san, Roger, >>> >>> Thank you for reviewing and comments. >>> >>> I checked behaviors by a small program and debugger. >>> If QueryFullProcessImageNameW failed by not enough buffer, >>> the API didn't change the buffer. >>> It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. >>> >>> The buffer size becomes 1024 characters (2048 bytes) by this patch. >>> Should it use bigger size with malloc? 32,767 characters can be >>> limit [2]. >>> I feel 1024 is reasonable value for command's location. >>> >>> [2] >>> https://urldefense.com/v3/__https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file*maximum-path-length-limitation__;Iw!!GqivPVa7Brio!PgzCcUQOjCNpcVeetU_drS4DFFVLaj0ceJBvipX7iDc_RlPtcEkdH8AzelGtzqXS$ >>> >>> Best regards, >>> Toshio Nakamura >>> >>>> Hi, >>>> >>>> If the call fails, the command field in the info will not be set (and >>>> therefore null). >>>> >>>> I agree that a length of 512 (characters) is probably too small. >>>> >>>> Roger >>>> >>>> >>>> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: >>>>> Hi Nakamura-san, >>>>> >>>>> Your change almost looks good, but I have one question. >>>>> Length of exeName (1024) is enough? >>>>> >>>>> According to Microsoft Doc [1], exeName might not be null-terminated >>>>> if it failed. >>>>> I concern buffer overrun might occur when QueryFullProcessImageNameW >>>>> failed. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_api_winbase_nf-2Dwinbase-2Dqueryfullprocessimagenamew&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=oc_KTGmJUjsfnLf3tjWr9DO1dwWp1TqIZgd2EiHVW14&e= >>> >>> >>>>> >>>>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: >>>>>> Hi All, >>>>>> >>>>>> Could you review this change? Additionally, I'd like to ask a >>>>>> sponsor >>>>>> for >>>>>> it, since I'm not a committer. >>>>>> >>>>>> Bug: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232846&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=pn_uS0DojBk6-R6R5QwtYFJvJpaabhia-eiOtIrJO9Q&e= >>> >>> >>>>>> Webrev: >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=NylYK0Q3nFFZRVIaeUna6iaClaJm1CWJ2Zkwy-ysvv4&e= >>> >>> >>>>>> Under Windows environments, ProcessHandle.Info.command shows >>>>>> question >>>>>> marks >>>>>> if the command has non-English characters. I'd like to change the >>>>>> underlying API to Unicode version. >>>>>> Tier1 tests passed. >>>>>> >>>>>> Best regards, >>>>>> Toshio Nakamura >>>>>> >> From suenaga at oss.nttdata.com Fri Mar 27 00:10:15 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 27 Mar 2020 09:10:15 +0900 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: <063fb628-a25d-500a-b495-c6a7364bb2de@oracle.com> References: <063fb628-a25d-500a-b495-c6a7364bb2de@oracle.com> Message-ID: On 2020/03/27 9:01, Roger Riggs wrote: > Hi, > > Please don't throw an exception. > It would abort being able to provide any information. > And who would expect or handle such an exception? > > Degrading the info or omitting it provides better service overall. > There is no point to throwing an exception. hProcess in QueryFullProcessImageNameW needs PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION access right, so I thought it is reasonable to throw runtime exception if the call failed. Anyway, I agree with you if throwing exception is not comfortable in this case for Java API. Thanks, Yasumasa > Regards, Roger > > > On 3/26/20 7:55 PM, Yasumasa Suenaga wrote: >> On 2020/03/27 0:35, Roger Riggs wrote: >>> Hi, >>> >>> Reading further down the reference to the section: >>> "Enable Long Paths in Windows 10, Version 1607, and Later" >>> might suggest the code be more resilient to long paths. >>> >>> The stack allocated buffer (1024) is fine, but I'd suggest adding code to retry in the case >>> of INSUFFICIENT BUFFER with a malloc'd buffer to make it more robust since the enabling >>> of long paths is environment and application specific. >> >> In addition, it's better to throw an exception if the call failed due to other error code. >> >> Thanks, >> >> Yasumasa >> >> >>> Thanks, Roger >>> >>> >>> >>> On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: >>>> Hi Thomas, Suenaga-san, Roger, >>>> >>>> Thank you for reviewing and comments. >>>> >>>> I checked behaviors by a small program and debugger. >>>> If QueryFullProcessImageNameW failed by not enough buffer, >>>> the API didn't change the buffer. >>>> It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. >>>> >>>> The buffer size becomes 1024 characters (2048 bytes) by this patch. >>>> Should it use bigger size with malloc? 32,767 characters can be limit [2]. >>>> I feel 1024 is reasonable value for command's location. >>>> >>>> [2] >>>> https://urldefense.com/v3/__https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file*maximum-path-length-limitation__;Iw!!GqivPVa7Brio!PgzCcUQOjCNpcVeetU_drS4DFFVLaj0ceJBvipX7iDc_RlPtcEkdH8AzelGtzqXS$ >>>> Best regards, >>>> Toshio Nakamura >>>> >>>>> Hi, >>>>> >>>>> If the call fails, the command field in the info will not be set (and >>>>> therefore null). >>>>> >>>>> I agree that a length of 512 (characters) is probably too small. >>>>> >>>>> Roger >>>>> >>>>> >>>>> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: >>>>>> Hi Nakamura-san, >>>>>> >>>>>> Your change almost looks good, but I have one question. >>>>>> Length of exeName (1024) is enough? >>>>>> >>>>>> According to Microsoft Doc [1], exeName might not be null-terminated >>>>>> if it failed. >>>>>> I concern buffer overrun might occur when QueryFullProcessImageNameW >>>>>> failed. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_api_winbase_nf-2Dwinbase-2Dqueryfullprocessimagenamew&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=oc_KTGmJUjsfnLf3tjWr9DO1dwWp1TqIZgd2EiHVW14&e= >>>> >>>>>> >>>>>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Could you review this change? Additionally, I'd like to ask a sponsor >>>>>>> for >>>>>>> it, since I'm not a committer. >>>>>>> >>>>>>> Bug: >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232846&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=pn_uS0DojBk6-R6R5QwtYFJvJpaabhia-eiOtIrJO9Q&e= >>>> >>>>>>> Webrev: >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=NylYK0Q3nFFZRVIaeUna6iaClaJm1CWJ2Zkwy-ysvv4&e= >>>> >>>>>>> Under Windows environments, ProcessHandle.Info.command shows question >>>>>>> marks >>>>>>> if the command has non-English characters. I'd like to change the >>>>>>> underlying API to Unicode version. >>>>>>> Tier1 tests passed. >>>>>>> >>>>>>> Best regards, >>>>>>> Toshio Nakamura >>>>>>> >>> > From vyommani at gmail.com Fri Mar 27 04:08:58 2020 From: vyommani at gmail.com (Vyom Tiwari) Date: Fri, 27 Mar 2020 09:38:58 +0530 Subject: [15] RFR: 8214694: cleanup rawtypes warnings in open jndi tests In-Reply-To: <29BE8612-A772-45AC-AEB3-55C5C3FBAED0@oracle.com> References: <29BE8612-A772-45AC-AEB3-55C5C3FBAED0@oracle.com> Message-ID: Hi Chris, I have one question to you, is there is any specific reason for using wildcard(?) ?. In your change we can avoid "?" at most of the places. Please see the below methods signatures. ####################################################################### public NamingEnumeration listBindings(Name name) throws NamingException; public NamingEnumeration list(Name name) throws NamingException; public NamingEnumeration search(Name name, Attributes matchingAttributes, String[] attributesToReturn) throws NamingException; ##################################################################### thanks, Vyom On Wed, Mar 25, 2020 at 1:28 PM Chris Yin wrote: > Hello > > Please review following simple changes to cleanup raw types warning for > open jndi tests (under test/jdk/com/sun/jndi and test/jdk/javax/naming), > thanks > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214694 > Webrev: http://cr.openjdk.java.net/~xyin/8214694/webrev.00/ > > > The changes should be straightforward, only fix raw types warnings, no > test logic change, no code optimization or cleanup. Minor change to each > test file, just a little surprised about the affected tests count, hope > this covers all. Run related jndi tests on 4 platforms for total 200 times, > all passed. > > Thanks, > Chris -- Thanks, Vyom From TOSHIONA at jp.ibm.com Fri Mar 27 05:06:22 2020 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Fri, 27 Mar 2020 14:06:22 +0900 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: <063fb628-a25d-500a-b495-c6a7364bb2de@oracle.com> Message-ID: Hi Roger, Suenaga-san, Thank you for your comments and discussion for the issue. I've updated webrev. Could you review it again? tier1 tests passed. webrev.01: http://cr.openjdk.java.net/~tnakamura/8232846/webrev.01 Best regards, Toshio Nakamura Yasumasa Suenaga wrote on 2020/03/27 09:10:15: > On 2020/03/27 9:01, Roger Riggs wrote: > > Hi, > > > > Please don't throw an exception. > > It would abort being able to provide any information. > > And who would expect or handle such an exception? > > > > Degrading the info or omitting it provides better service overall. > > There is no point to throwing an exception. > > hProcess in QueryFullProcessImageNameW needs > PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION > access right, so I thought it is reasonable to throw runtime > exception if the call failed. > > Anyway, I agree with you if throwing exception is not comfortable in > this case for Java API. > > > Thanks, > > Yasumasa > > > > Regards, Roger > > > > > > On 3/26/20 7:55 PM, Yasumasa Suenaga wrote: > >> On 2020/03/27 0:35, Roger Riggs wrote: > >>> Hi, > >>> > >>> Reading further down the reference to the section: > >>> "Enable Long Paths in Windows 10, Version 1607, and Later" > >>> might suggest the code be more resilient to long paths. > >>> > >>> The stack allocated buffer (1024) is fine, but I'd suggest > adding code to retry in the case > >>> of INSUFFICIENT BUFFER with a malloc'd buffer to make it more > robust since the enabling > >>> of long paths is environment and application specific. > >> > >> In addition, it's better to throw an exception if the call failed > due to other error code. > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > >>> Thanks, Roger > >>> > >>> > >>> > >>> On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: > >>>> Hi Thomas, Suenaga-san, Roger, > >>>> > >>>> Thank you for reviewing and comments. > >>>> > >>>> I checked behaviors by a small program and debugger. > >>>> If QueryFullProcessImageNameW failed by not enough buffer, > >>>> the API didn't change the buffer. > >>>> It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. > >>>> > >>>> The buffer size becomes 1024 characters (2048 bytes) by this patch. > >>>> Should it use bigger size with malloc? 32,767 characters can belimit [2]. > >>>> I feel 1024 is reasonable value for command's location. > >>>> > >>>> [2] > >>>> https://urldefense.com/v3/__https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file*maximum-path-length-limitation__;Iw!!GqivPVa7Brio!PgzCcUQOjCNpcVeetU_drS4DFFVLaj0ceJBvipX7iDc_RlPtcEkdH8AzelGtzqXS $ > >>>> Best regards, > >>>> Toshio Nakamura > >>>> > >>>>> Hi, > >>>>> > >>>>> If the call fails, the command field in the info will not be set (and > >>>>> therefore null). > >>>>> > >>>>> I agree that a length of 512 (characters) is probably too small. > >>>>> > >>>>> Roger > >>>>> > >>>>> > >>>>> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: > >>>>>> Hi Nakamura-san, > >>>>>> > >>>>>> Your change almost looks good, but I have one question. > >>>>>> Length of exeName (1024) is enough? > >>>>>> > >>>>>> According to Microsoft Doc [1], exeName might not be null-terminated > >>>>>> if it failed. > >>>>>> I concern buffer overrun might occur when QueryFullProcessImageNameW > >>>>>> failed. > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Yasumasa > >>>>>> > >>>>>> > >>>>>> [1] > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_api_winbase_nf-2Dwinbase-2Dqueryfullprocessimagenamew&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=oc_KTGmJUjsfnLf3tjWr9DO1dwWp1TqIZgd2EiHVW14&e= > >>>> > >>>>>> > >>>>>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: > >>>>>>> Hi All, > >>>>>>> > >>>>>>> Could you review this change? Additionally, I'd like to ask a sponsor > >>>>>>> for > >>>>>>> it, since I'm not a committer. > >>>>>>> > >>>>>>> Bug: > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232846&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=pn_uS0DojBk6-R6R5QwtYFJvJpaabhia-eiOtIrJO9Q&e= > >>>> > >>>>>>> Webrev: > >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=NylYK0Q3nFFZRVIaeUna6iaClaJm1CWJ2Zkwy-ysvv4&e= > >>>> > >>>>>>> Under Windows environments, ProcessHandle.Info.command shows question > >>>>>>> marks > >>>>>>> if the command has non-English characters. I'd like to change the > >>>>>>> underlying API to Unicode version. > >>>>>>> Tier1 tests passed. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Toshio Nakamura > >>>>>>> > >>> > > > From thomas.stuefe at gmail.com Fri Mar 27 06:24:31 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Mar 2020 07:24:31 +0100 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: <063fb628-a25d-500a-b495-c6a7364bb2de@oracle.com> Message-ID: Hi Toshio, did you test the malloc path? Since https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-queryfullprocessimagenamew#return-value does not mention ERROR_INSUFFICIENT_BUFFER as return code, would like to see this working. It does however mention that it returns the number of returned characters, so if the return code does not work out we may use that. If you tested the truncation path and it works I am fine with the change as it is. Cheers, Thomas On Fri, Mar 27, 2020 at 6:08 AM Toshio 5 Nakamura wrote: > > Hi Roger, Suenaga-san, > > Thank you for your comments and discussion for the issue. > I've updated webrev. Could you review it again? > tier1 tests passed. > > webrev.01: http://cr.openjdk.java.net/~tnakamura/8232846/webrev.01 > > Best regards, > Toshio Nakamura > > Yasumasa Suenaga wrote on 2020/03/27 09:10:15: > > > On 2020/03/27 9:01, Roger Riggs wrote: > > > Hi, > > > > > > Please don't throw an exception. > > > It would abort being able to provide any information. > > > And who would expect or handle such an exception? > > > > > > Degrading the info or omitting it provides better service overall. > > > There is no point to throwing an exception. > > > > hProcess in QueryFullProcessImageNameW needs > > PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION > > access right, so I thought it is reasonable to throw runtime > > exception if the call failed. > > > > Anyway, I agree with you if throwing exception is not comfortable in > > this case for Java API. > > > > > > Thanks, > > > > Yasumasa > > > > > > > Regards, Roger > > > > > > > > > On 3/26/20 7:55 PM, Yasumasa Suenaga wrote: > > >> On 2020/03/27 0:35, Roger Riggs wrote: > > >>> Hi, > > >>> > > >>> Reading further down the reference to the section: > > >>> "Enable Long Paths in Windows 10, Version 1607, and Later" > > >>> might suggest the code be more resilient to long paths. > > >>> > > >>> The stack allocated buffer (1024) is fine, but I'd suggest > > adding code to retry in the case > > >>> of INSUFFICIENT BUFFER with a malloc'd buffer to make it more > > robust since the enabling > > >>> of long paths is environment and application specific. > > >> > > >> In addition, it's better to throw an exception if the call failed > > due to other error code. > > >> > > >> Thanks, > > >> > > >> Yasumasa > > >> > > >> > > >>> Thanks, Roger > > >>> > > >>> > > >>> > > >>> On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: > > >>>> Hi Thomas, Suenaga-san, Roger, > > >>>> > > >>>> Thank you for reviewing and comments. > > >>>> > > >>>> I checked behaviors by a small program and debugger. > > >>>> If QueryFullProcessImageNameW failed by not enough buffer, > > >>>> the API didn't change the buffer. > > >>>> It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. > > >>>> > > >>>> The buffer size becomes 1024 characters (2048 bytes) by this patch. > > >>>> Should it use bigger size with malloc? 32,767 characters can belimit > [2]. > > >>>> I feel 1024 is reasonable value for command's location. > > >>>> > > >>>> [2] > > >>>> > > https://urldefense.com/v3/__https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file*maximum-path-length-limitation__;Iw!!GqivPVa7Brio!PgzCcUQOjCNpcVeetU_drS4DFFVLaj0ceJBvipX7iDc_RlPtcEkdH8AzelGtzqXS > $ > > >>>> Best regards, > > >>>> Toshio Nakamura > > >>>> > > >>>>> Hi, > > >>>>> > > >>>>> If the call fails, the command field in the info will not be set > (and > > >>>>> therefore null). > > >>>>> > > >>>>> I agree that a length of 512 (characters) is probably too small. > > >>>>> > > >>>>> Roger > > >>>>> > > >>>>> > > >>>>> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: > > >>>>>> Hi Nakamura-san, > > >>>>>> > > >>>>>> Your change almost looks good, but I have one question. > > >>>>>> Length of exeName (1024) is enough? > > >>>>>> > > >>>>>> According to Microsoft Doc [1], exeName might not be > null-terminated > > >>>>>> if it failed. > > >>>>>> I concern buffer overrun might occur when > QueryFullProcessImageNameW > > >>>>>> failed. > > >>>>>> > > >>>>>> > > >>>>>> Thanks, > > >>>>>> > > >>>>>> Yasumasa > > >>>>>> > > >>>>>> > > >>>>>> [1] > > >>>> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_api_winbase_nf-2Dwinbase-2Dqueryfullprocessimagenamew&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=oc_KTGmJUjsfnLf3tjWr9DO1dwWp1TqIZgd2EiHVW14&e= > > > >>>> > > >>>>>> > > >>>>>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: > > >>>>>>> Hi All, > > >>>>>>> > > >>>>>>> Could you review this change? Additionally, I'd like to ask a > sponsor > > >>>>>>> for > > >>>>>>> it, since I'm not a committer. > > >>>>>>> > > >>>>>>> Bug: > > >>>> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232846&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=pn_uS0DojBk6-R6R5QwtYFJvJpaabhia-eiOtIrJO9Q&e= > > > >>>> > > >>>>>>> Webrev: > > >>>> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=NylYK0Q3nFFZRVIaeUna6iaClaJm1CWJ2Zkwy-ysvv4&e= > > > >>>> > > >>>>>>> Under Windows environments, ProcessHandle.Info.command shows > question > > >>>>>>> marks > > >>>>>>> if the command has non-English characters. I'd like to change the > > >>>>>>> underlying API to Unicode version. > > >>>>>>> Tier1 tests passed. > > >>>>>>> > > >>>>>>> Best regards, > > >>>>>>> Toshio Nakamura > > >>>>>>> > > >>> > > > > > > From thomas.stuefe at gmail.com Fri Mar 27 08:11:49 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Mar 2020 09:11:49 +0100 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: <063fb628-a25d-500a-b495-c6a7364bb2de@oracle.com> Message-ID: Looks good to me in its current form, thanks. On Fri, Mar 27, 2020 at 8:02 AM Toshio 5 Nakamura wrote: > Hi Thomas, > > Yes, I tested it locally with small buffer size, 50 for example. But, it's > hard to create a jtreg test. > > I confirmed ERROR_INSUFFICIENT_BUFFER returned from GetLastError(), if the > provided buffer was not enough. > Furthermore, "lpdwSize" parameter didn't set a new value in that case. > I hope the manual has more specific description... > > Best regards, > Toshio Nakamura > > > ----- Original message ----- > > Hi Toshio, > > did you test the malloc path? Since > https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-queryfullprocessimagenamew#return-value does > not mention ERROR_INSUFFICIENT_BUFFER as return code, would like to see > this working. It does however mention that it returns the number of > returned characters, so if the return code does not work out we may use > that. > > If you tested the truncation path and it works I am fine with the change > as it is. > > Cheers, Thomas > > > On Fri, Mar 27, 2020 at 6:08 AM Toshio 5 Nakamura > wrote: > > > Hi Roger, Suenaga-san, > > Thank you for your comments and discussion for the issue. > I've updated webrev. Could you review it again? > tier1 tests passed. > > webrev.01: http://cr.openjdk.java.net/~tnakamura/8232846/webrev.01 > > Best regards, > Toshio Nakamura > > Yasumasa Suenaga wrote on 2020/03/27 09:10:15: > > > On 2020/03/27 9:01, Roger Riggs wrote: > > > Hi, > > > > > > Please don't throw an exception. > > > It would abort being able to provide any information. > > > And who would expect or handle such an exception? > > > > > > Degrading the info or omitting it provides better service overall. > > > There is no point to throwing an exception. > > > > hProcess in QueryFullProcessImageNameW needs > > PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION > > access right, so I thought it is reasonable to throw runtime > > exception if the call failed. > > > > Anyway, I agree with you if throwing exception is not comfortable in > > this case for Java API. > > > > > > Thanks, > > > > Yasumasa > > > > > > > Regards, Roger > > > > > > > > > On 3/26/20 7:55 PM, Yasumasa Suenaga wrote: > > >> On 2020/03/27 0:35, Roger Riggs wrote: > > >>> Hi, > > >>> > > >>> Reading further down the reference to the section: > > >>> "Enable Long Paths in Windows 10, Version 1607, and Later" > > >>> might suggest the code be more resilient to long paths. > > >>> > > >>> The stack allocated buffer (1024) is fine, but I'd suggest > > adding code to retry in the case > > >>> of INSUFFICIENT BUFFER with a malloc'd buffer to make it more > > robust since the enabling > > >>> of long paths is environment and application specific. > > >> > > >> In addition, it's better to throw an exception if the call failed > > due to other error code. > > >> > > >> Thanks, > > >> > > >> Yasumasa > > >> > > >> > > >>> Thanks, Roger > > >>> > > >>> > > >>> > > >>> On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: > > >>>> Hi Thomas, Suenaga-san, Roger, > > >>>> > > >>>> Thank you for reviewing and comments. > > >>>> > > >>>> I checked behaviors by a small program and debugger. > > >>>> If QueryFullProcessImageNameW failed by not enough buffer, > > >>>> the API didn't change the buffer. > > >>>> It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. > > >>>> > > >>>> The buffer size becomes 1024 characters (2048 bytes) by this patch. > > >>>> Should it use bigger size with malloc? 32,767 characters can belimit > [2]. > > >>>> I feel 1024 is reasonable value for command's location. > > >>>> > > >>>> [2] > > >>>> > > https://urldefense.com/v3/__https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file*maximum-path-length-limitation__;Iw!!GqivPVa7Brio!PgzCcUQOjCNpcVeetU_drS4DFFVLaj0ceJBvipX7iDc_RlPtcEkdH8AzelGtzqXS > $ > > >>>> Best regards, > > >>>> Toshio Nakamura > > >>>> > > >>>>> Hi, > > >>>>> > > >>>>> If the call fails, the command field in the info will not be set > (and > > >>>>> therefore null). > > >>>>> > > >>>>> I agree that a length of 512 (characters) is probably too small. > > >>>>> > > >>>>> Roger > > >>>>> > > >>>>> > > >>>>> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: > > >>>>>> Hi Nakamura-san, > > >>>>>> > > >>>>>> Your change almost looks good, but I have one question. > > >>>>>> Length of exeName (1024) is enough? > > >>>>>> > > >>>>>> According to Microsoft Doc [1], exeName might not be > null-terminated > > >>>>>> if it failed. > > >>>>>> I concern buffer overrun might occur when > QueryFullProcessImageNameW > > >>>>>> failed. > > >>>>>> > > >>>>>> > > >>>>>> Thanks, > > >>>>>> > > >>>>>> Yasumasa > > >>>>>> > > >>>>>> > > >>>>>> [1] > > >>>> > > https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-queryfullprocessimagenamew > > > >>>> > > >>>>>> > > >>>>>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: > > >>>>>>> Hi All, > > >>>>>>> > > >>>>>>> Could you review this change? Additionally, I'd like to ask a > sponsor > > >>>>>>> for > > >>>>>>> it, since I'm not a committer. > > >>>>>>> > > >>>>>>> Bug: > > >>>> > https://bugs.openjdk.java.net/browse/JDK-8232846 > > > >>>> > > >>>>>>> Webrev: > > >>>> > http://cr.openjdk.java.net/~tnakamura/8232846/webrev.00 > > > >>>> > > >>>>>>> Under Windows environments, ProcessHandle.Info.command shows > question > > >>>>>>> marks > > >>>>>>> if the command has non-English characters. I'd like to change the > > >>>>>>> underlying API to Unicode version. > > >>>>>>> Tier1 tests passed. > > >>>>>>> > > >>>>>>> Best regards, > > >>>>>>> Toshio Nakamura > > >>>>>>> > > >>> > > > > > > > > > From suenaga at oss.nttdata.com Fri Mar 27 08:24:57 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 27 Mar 2020 17:24:57 +0900 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: <063fb628-a25d-500a-b495-c6a7364bb2de@oracle.com> Message-ID: Nakamura-san, I think location of CHECK_NULL and SetObjectField() are incorrect. Currently they are called when QueryFullProcessImageName() succeed only. In addition, you need to allocate 32768 chars (32767 + 1 ('\0')) via malloc. I understand "32767" is max length, not includes null-terminator. Thanks, Yasumasa On 2020/03/27 14:06, Toshio 5 Nakamura wrote: > > Hi Roger, Suenaga-san, > > Thank you for your comments and discussion for the issue. > I've updated webrev. Could you review it again? > tier1 tests passed. > > webrev.01: http://cr.openjdk.java.net/~tnakamura/8232846/webrev.01 > > Best regards, > Toshio Nakamura > > Yasumasa Suenaga wrote on 2020/03/27 09:10:15: > >> On 2020/03/27 9:01, Roger Riggs wrote: >>> Hi, >>> >>> Please don't throw an exception. >>> It would abort being able to provide any information. >>> And who would expect or handle such an exception? >>> >>> Degrading the info or omitting it provides better service overall. >>> There is no point to throwing an exception. >> >> hProcess in QueryFullProcessImageNameW needs >> PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION >> access right, so I thought it is reasonable to throw runtime >> exception if the call failed. >> >> Anyway, I agree with you if throwing exception is not comfortable in >> this case for Java API. >> >> >> Thanks, >> >> Yasumasa >> >> >>> Regards, Roger >>> >>> >>> On 3/26/20 7:55 PM, Yasumasa Suenaga wrote: >>>> On 2020/03/27 0:35, Roger Riggs wrote: >>>>> Hi, >>>>> >>>>> Reading further down the reference to the section: >>>>> "Enable Long Paths in Windows 10, Version 1607, and Later" >>>>> might suggest the code be more resilient to long paths. >>>>> >>>>> The stack allocated buffer (1024) is fine, but I'd suggest >> adding code to retry in the case >>>>> of INSUFFICIENT BUFFER with a malloc'd buffer to make it more >> robust since the enabling >>>>> of long paths is environment and application specific. >>>> >>>> In addition, it's better to throw an exception if the call failed >> due to other error code. >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> Thanks, Roger >>>>> >>>>> >>>>> >>>>> On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: >>>>>> Hi Thomas, Suenaga-san, Roger, >>>>>> >>>>>> Thank you for reviewing and comments. >>>>>> >>>>>> I checked behaviors by a small program and debugger. >>>>>> If QueryFullProcessImageNameW failed by not enough buffer, >>>>>> the API didn't change the buffer. >>>>>> It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. >>>>>> >>>>>> The buffer size becomes 1024 characters (2048 bytes) by this patch. >>>>>> Should it use bigger size with malloc? 32,767 characters can belimit > [2]. >>>>>> I feel 1024 is reasonable value for command's location. >>>>>> >>>>>> [2] >>>>>> > https://urldefense.com/v3/__https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file*maximum-path-length-limitation__;Iw!!GqivPVa7Brio!PgzCcUQOjCNpcVeetU_drS4DFFVLaj0ceJBvipX7iDc_RlPtcEkdH8AzelGtzqXS > $ >>>>>> Best regards, >>>>>> Toshio Nakamura >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> If the call fails, the command field in the info will not be set > (and >>>>>>> therefore null). >>>>>>> >>>>>>> I agree that a length of 512 (characters) is probably too small. >>>>>>> >>>>>>> Roger >>>>>>> >>>>>>> >>>>>>> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi Nakamura-san, >>>>>>>> >>>>>>>> Your change almost looks good, but I have one question. >>>>>>>> Length of exeName (1024) is enough? >>>>>>>> >>>>>>>> According to Microsoft Doc [1], exeName might not be > null-terminated >>>>>>>> if it failed. >>>>>>>> I concern buffer overrun might occur when > QueryFullProcessImageNameW >>>>>>>> failed. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_api_winbase_nf-2Dwinbase-2Dqueryfullprocessimagenamew&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=oc_KTGmJUjsfnLf3tjWr9DO1dwWp1TqIZgd2EiHVW14&e= > >>>>>> >>>>>>>> >>>>>>>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Could you review this change? Additionally, I'd like to ask a > sponsor >>>>>>>>> for >>>>>>>>> it, since I'm not a committer. >>>>>>>>> >>>>>>>>> Bug: >>>>>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232846&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=pn_uS0DojBk6-R6R5QwtYFJvJpaabhia-eiOtIrJO9Q&e= > >>>>>> >>>>>>>>> Webrev: >>>>>> > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=noFyLWDG1dMjO5TlaqM_zvW_f-8fvveS2EoZylT5DMQ&s=NylYK0Q3nFFZRVIaeUna6iaClaJm1CWJ2Zkwy-ysvv4&e= > >>>>>> >>>>>>>>> Under Windows environments, ProcessHandle.Info.command shows > question >>>>>>>>> marks >>>>>>>>> if the command has non-English characters. I'd like to change the >>>>>>>>> underlying API to Unicode version. >>>>>>>>> Tier1 tests passed. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Toshio Nakamura >>>>>>>>> >>>>> >>> >> From xu.y.yin at oracle.com Fri Mar 27 08:30:41 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Fri, 27 Mar 2020 16:30:41 +0800 Subject: [15] RFR: 8214694: cleanup rawtypes warnings in open jndi tests In-Reply-To: References: <29BE8612-A772-45AC-AEB3-55C5C3FBAED0@oracle.com> Message-ID: <7850C8C2-6457-48F6-ADE4-A27B81F7D7B8@oracle.com> Hi, Joe Thank you for reviewing and comments. I agree that some part of the change could be as precise as they could be, and yes, after fix them, a round of redundant ?cast? warnings just show up as you mentioned, both fixed now For rest of them, I could see most are due to the API return value or parameter are imprecise (such as Class.forName, Context.getEnvironment etc), to avoid useless cast, just kept the same declaration, please kindly advise if you have any suggestion about that too, thanks. Updated webrev as below http://cr.openjdk.java.net/~xyin/8214694/webrev.01/ Regards, Chris > On 27 Mar 2020, at 4:41 AM, Joe Darcy wrote: > > Hi Chris, > > The changes don't appear incorrect, but at least from a cursory inspection, they don't appear as precise as they could be. Usually generifying a classes like this will next yield a round of redundant "cast" warnings; in my cleanup efforts, getting cast warnings was usually a sign the right generifiation was found. > > HTH, > > -Joe > > On 3/25/2020 12:57 AM, Chris Yin wrote: >> Hello >> >> Please review following simple changes to cleanup raw types warning for open jndi tests (under test/jdk/com/sun/jndi and test/jdk/javax/naming), thanks >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214694 >> Webrev: http://cr.openjdk.java.net/~xyin/8214694/webrev.00/ >> >> >> The changes should be straightforward, only fix raw types warnings, no test logic change, no code optimization or cleanup. Minor change to each test file, just a little surprised about the affected tests count, hope this covers all. Run related jndi tests on 4 platforms for total 200 times, all passed. >> >> Thanks, >> Chris From xu.y.yin at oracle.com Fri Mar 27 09:18:00 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Fri, 27 Mar 2020 17:18:00 +0800 Subject: [15] RFR: 8214694: cleanup rawtypes warnings in open jndi tests In-Reply-To: References: <29BE8612-A772-45AC-AEB3-55C5C3FBAED0@oracle.com> Message-ID: <112844A8-42EE-4976-B207-FCD014A72724@oracle.com> Hi, Vyom > On 27 Mar 2020, at 12:08 PM, Vyom Tiwari wrote: > > Hi Chris, > > I have one question to you, is there is any specific reason for using wildcard(?) ?. Thank you for reviewing and comments. I just replaced most of the wildcard(?) with specified type as precise as they could be in latest webrev.01, the rest of them may fall into below scenarios. 1. API return value or parameter with wildcard(?), such as Hashtable in test/jdk/com/sun/jndi/dns/EnvTests/AddInherited.java 2. Cannot find the precise type from code, such as ScheduledFuture in test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java > In your change we can avoid "?" at most of the places. Please see the below methods signatures. > > ####################################################################### > public NamingEnumeration listBindings(Name name) throws NamingException; > public NamingEnumeration list(Name name) throws NamingException; > public NamingEnumeration search(Name name, Attributes matchingAttributes, > String[] attributesToReturn) throws NamingException; > ##################################################################### Thank you for the detailed signatures info, yes, now all fixed in the latest webrev http://cr.openjdk.java.net/~xyin/8214694/webrev.01/ Regards, Chris > > thanks, > Vyom > > On Wed, Mar 25, 2020 at 1:28 PM Chris Yin > wrote: > Hello > > Please review following simple changes to cleanup raw types warning for open jndi tests (under test/jdk/com/sun/jndi and test/jdk/javax/naming), thanks > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214694 > Webrev: http://cr.openjdk.java.net/~xyin/8214694/webrev.00/ > > > The changes should be straightforward, only fix raw types warnings, no test logic change, no code optimization or cleanup. Minor change to each test file, just a little surprised about the affected tests count, hope this covers all. Run related jndi tests on 4 platforms for total 200 times, all passed. > > Thanks, > Chris > > > -- > Thanks, > Vyom From suenaga at oss.nttdata.com Fri Mar 27 09:52:04 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 27 Mar 2020 18:52:04 +0900 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: <063fb628-a25d-500a-b495-c6a7364bb2de@oracle.com> Message-ID: Ok, your change looks good. Thanks, Yasumasa On 2020/03/27 18:10, Toshio 5 Nakamura wrote: > Hi Suenaga-san, > Thank you for the comment. I updated the limit to 32768. > webrev.02: http://cr.openjdk.java.net/~tnakamura/8232846/webrev.02 > Well, I believe the new logic works as same as the current one. > I added NULL initialization to commandObj, and the value will be changed only if QueryFullProcessImageNameW() was success. > Then, CHECK_NULL(commandObj) works as "return" if commandObj is NULL. > src/java.base/share/native/libjava/jni_util.h > > #define CHECK_NULL(x)?????????????????????????? \ > >???? do {??????????????????????????????????????? \ > >???????? if ((x) == NULL) {????????????????????? \ > >???????????? return;???????????????????????????? \ > >???????? }?????????????????????????????????????? \ > >???? } while (0)???????????????????????????????? \ > I hope this solves your concern. > Best regards, > Toshio Nakamura > > ----- Original message ----- > Nakamura-san, > > I think location of CHECK_NULL and SetObjectField() are incorrect. > Currently they are called when QueryFullProcessImageName() succeed only. > > In addition, you need to allocate 32768 chars (32767 + 1 ('\0')) via malloc. > I understand "32767" is max length, not includes null-terminator. > > > Thanks, > > Yasumasa > > > On 2020/03/27 14:06, Toshio 5 Nakamura wrote: > > > > Hi Roger, Suenaga-san, > > > > Thank you for your comments and discussion for the issue. > > I've updated webrev. Could you review it again? > > tier1 tests passed. > > > > webrev.01: http://cr.openjdk.java.net/~tnakamura/8232846/webrev.01 > > > > Best regards, > > Toshio Nakamura > > > > Yasumasa Suenaga wrote on 2020/03/27 09:10:15: > > > >> On 2020/03/27 9:01, Roger Riggs wrote: > >>> Hi, > >>> > >>> Please don't throw an exception. > >>> It would abort being able to provide any information. > >>> And who would expect or handle such an exception? > >>> > >>> Degrading the info or omitting it provides better service overall. > >>> There is no point to throwing an exception. > >> > >> hProcess in QueryFullProcessImageNameW needs > >> PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION > >> access right, so I thought it is reasonable to throw runtime > >> exception if the call failed. > >> > >> Anyway, I agree with you if throwing exception is not comfortable in > >> this case for Java API. > >> > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > >>> Regards, Roger > >>> > >>> > >>> On 3/26/20 7:55 PM, Yasumasa Suenaga wrote: > >>>> On 2020/03/27 0:35, Roger Riggs wrote: > >>>>> Hi, > >>>>> > >>>>> Reading further down the reference to the section: > >>>>> "Enable Long Paths in Windows 10, Version 1607, and Later" > >>>>> might suggest the code be more resilient to long paths. > >>>>> > >>>>> The stack allocated buffer (1024) is fine, but I'd suggest > >> adding code to retry in the case > >>>>> of INSUFFICIENT BUFFER with a malloc'd buffer to make it more > >> robust since the enabling > >>>>> of long paths is environment and application specific. > >>>> > >>>> In addition, it's better to throw an exception if the call failed > >> due to other error code. > >>>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> > >>>> > >>>>> Thanks, Roger > >>>>> > >>>>> > >>>>> > >>>>> On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: > >>>>>> Hi Thomas, Suenaga-san, Roger, > >>>>>> > >>>>>> Thank you for reviewing and comments. > >>>>>> > >>>>>> I checked behaviors by a small program and debugger. > >>>>>> If QueryFullProcessImageNameW failed by not enough buffer, > >>>>>> the API didn't change the buffer. > >>>>>> It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. > >>>>>> > >>>>>> The buffer size becomes 1024 characters (2048 bytes) by this patch. > >>>>>> Should it use bigger size with malloc? 32,767 characters can belimit > > [2]. > >>>>>> I feel 1024 is reasonable value for command's location. > >>>>>> > >>>>>> [2] > >>>>>> > > https://urldefense.com/v3/__https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file*maximum-path-length-limitation__;Iw!!GqivPVa7Brio!PgzCcUQOjCNpcVeetU_drS4DFFVLaj0ceJBvipX7iDc_RlPtcEkdH8AzelGtzqXS > > $ > >>>>>> Best regards, > >>>>>> Toshio Nakamura > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> If the call fails, the command field in the info will not be set (and > >>>>>>> therefore null). > >>>>>>> > >>>>>>> I agree that a length of 512 (characters) is probably too small. > >>>>>>> > >>>>>>> Roger > >>>>>>> > >>>>>>> > >>>>>>> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: > >>>>>>>> Hi Nakamura-san, > >>>>>>>> > >>>>>>>> Your change almost looks good, but I have one question. > >>>>>>>> Length of exeName (1024) is enough? > >>>>>>>> > >>>>>>>> According to Microsoft Doc [1], exeName might not be null-terminated > >>>>>>>> if it failed. > >>>>>>>> I concern buffer overrun might occur when QueryFullProcessImageNameW > >>>>>>>> failed. > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Yasumasa > >>>>>>>> > >>>>>>>> > >>>>>>>> [1] > >>>>>> > > https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-queryfullprocessimagenamew > > > >>>>>> > >>>>>>>> > >>>>>>>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: > >>>>>>>>> Hi All, > >>>>>>>>> > >>>>>>>>> Could you review this change? Additionally, I'd like to ask a > > sponsor > >>>>>>>>> for > >>>>>>>>> it, since I'm not a committer. > >>>>>>>>> > >>>>>>>>> Bug: > >>>>>> > > https://bugs.openjdk.java.net/browse/JDK-8232846 > > > >>>>>> > >>>>>>>>> Webrev: > >>>>>> > > http://cr.openjdk.java.net/~tnakamura/8232846/webrev.00 > > >>>>>>>>> Under Windows environments, ProcessHandle.Info.command shows question marks > >>>>>>>>> if the command has non-English characters. I'd like to change the > >>>>>>>>> underlying API to Unicode version. > >>>>>>>>> Tier1 tests passed. > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Toshio Nakamura > >>>>>>>>> > >>>>> > >>> > >> > > From vyommani at gmail.com Fri Mar 27 10:06:59 2020 From: vyommani at gmail.com (Vyom Tiwari) Date: Fri, 27 Mar 2020 15:36:59 +0530 Subject: [15] RFR: 8214694: cleanup rawtypes warnings in open jndi tests In-Reply-To: <112844A8-42EE-4976-B207-FCD014A72724@oracle.com> References: <29BE8612-A772-45AC-AEB3-55C5C3FBAED0@oracle.com> <112844A8-42EE-4976-B207-FCD014A72724@oracle.com> Message-ID: Hi Chris, Latest changes look good to me. I can see that there are couple of unused imports in files(DeadServerTimeoutSSLTest.java) but unused imports are separate issue. Thanks, Vyom On Fri, Mar 27, 2020 at 2:48 PM Chris Yin wrote: > Hi, Vyom > > On 27 Mar 2020, at 12:08 PM, Vyom Tiwari wrote: > > Hi Chris, > > I have one question to you, is there is any specific reason for using > wildcard(?) ?. > > > Thank you for reviewing and comments. I just replaced most of the > wildcard(?) with specified type as precise as they could be in latest > webrev.01, the rest of them may fall into below scenarios. > > 1. API return value or parameter with wildcard(?), such as Hashtable > in test/jdk/com/sun/jndi/dns/EnvTests/AddInherited.java > 2. Cannot find the precise type from code, such as ScheduledFuture > in test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java > > In your change we can avoid "?" at most of the places. Please see the > below methods signatures. > > ####################################################################### > public NamingEnumeration listBindings(Name name) throws > NamingException; > public NamingEnumeration list(Name name) throws > NamingException; > public NamingEnumeration search(Name name, Attributes > matchingAttributes, > > > String[] attributesToReturn) throws NamingException; > ##################################################################### > > > Thank you for the detailed signatures info, yes, now all fixed in the > latest webrev http://cr.openjdk.java.net/~xyin/8214694/webrev.01/ > > Regards, > Chris > > > thanks, > Vyom > > On Wed, Mar 25, 2020 at 1:28 PM Chris Yin wrote: > >> Hello >> >> Please review following simple changes to cleanup raw types warning for >> open jndi tests (under test/jdk/com/sun/jndi and test/jdk/javax/naming), >> thanks >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214694 >> Webrev: http://cr.openjdk.java.net/~xyin/8214694/webrev.00/ >> >> >> The changes should be straightforward, only fix raw types warnings, no >> test logic change, no code optimization or cleanup. Minor change to each >> test file, just a little surprised about the affected tests count, hope >> this covers all. Run related jndi tests on 4 platforms for total 200 times, >> all passed. >> >> Thanks, >> Chris > > > > -- > Thanks, > Vyom > > > -- Thanks, Vyom From xu.y.yin at oracle.com Fri Mar 27 10:16:17 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Fri, 27 Mar 2020 18:16:17 +0800 Subject: [15] RFR: 8214694: cleanup rawtypes warnings in open jndi tests In-Reply-To: References: <29BE8612-A772-45AC-AEB3-55C5C3FBAED0@oracle.com> <112844A8-42EE-4976-B207-FCD014A72724@oracle.com> Message-ID: Thank you, Vyom Regards, Chris > On 27 Mar 2020, at 6:06 PM, Vyom Tiwari wrote: > > Hi Chris, > > Latest changes look good to me. I can see that there are couple of unused imports in files(DeadServerTimeoutSSLTest.java) but unused imports are separate issue. > > Thanks, > Vyom > > On Fri, Mar 27, 2020 at 2:48 PM Chris Yin > wrote: > Hi, Vyom > >> On 27 Mar 2020, at 12:08 PM, Vyom Tiwari > wrote: >> >> Hi Chris, >> >> I have one question to you, is there is any specific reason for using wildcard(?) ?. > > Thank you for reviewing and comments. I just replaced most of the wildcard(?) with specified type as precise as they could be in latest webrev.01, the rest of them may fall into below scenarios. > > 1. API return value or parameter with wildcard(?), such as Hashtable in test/jdk/com/sun/jndi/dns/EnvTests/AddInherited.java > 2. Cannot find the precise type from code, such as ScheduledFuture in test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java > >> In your change we can avoid "?" at most of the places. Please see the below methods signatures. >> >> ####################################################################### >> public NamingEnumeration listBindings(Name name) throws NamingException; >> public NamingEnumeration list(Name name) throws NamingException; >> public NamingEnumeration search(Name name, Attributes matchingAttributes, >> String[] attributesToReturn) throws NamingException; >> ##################################################################### > > Thank you for the detailed signatures info, yes, now all fixed in the latest webrev http://cr.openjdk.java.net/~xyin/8214694/webrev.01/ > > Regards, > Chris > >> >> thanks, >> Vyom >> >> On Wed, Mar 25, 2020 at 1:28 PM Chris Yin > wrote: >> Hello >> >> Please review following simple changes to cleanup raw types warning for open jndi tests (under test/jdk/com/sun/jndi and test/jdk/javax/naming), thanks >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214694 >> Webrev: http://cr.openjdk.java.net/~xyin/8214694/webrev.00/ >> >> >> The changes should be straightforward, only fix raw types warnings, no test logic change, no code optimization or cleanup. Minor change to each test file, just a little surprised about the affected tests count, hope this covers all. Run related jndi tests on 4 platforms for total 200 times, all passed. >> >> Thanks, >> Chris >> >> >> -- >> Thanks, >> Vyom > > > > -- > Thanks, > Vyom From ivan.gerasimov at oracle.com Fri Mar 27 10:26:40 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 27 Mar 2020 03:26:40 -0700 Subject: [15] RFR 8241727 : Typos: empty lines in javadoc, inconsistent indents, etc. (core-libs only) Message-ID: Hello! This is a javadoc-only fix. There are a few changes that will actually be visible (for example [1], [2]), but the vast majority of changes are to remove redundant empty lines, correct indentation, or otherwise restore harmony. Would you please help review this rather technical fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8241727 WEBREV: http://cr.openjdk.java.net/~igerasim/8241727/00/webrev/ Thank in advance! [1] Extra '+' in text: https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/io/ObjectInputStream.html#readObjectOverride() [2] Extra 'I' in text: https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/annotation/Annotation.html#hashCode() -- With kind regards, Ivan Gerasimov From TOSHIONA at jp.ibm.com Fri Mar 27 10:46:09 2020 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Fri, 27 Mar 2020 19:46:09 +0900 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: <063fb628-a25d-500a-b495-c6a7364bb2de@oracle.com> Message-ID: Thank you for review, Suenaga-san, Thomas. (My mail in html format was blocked by the list. Sorry for inconvenience.) The latest webrev is 02: http://cr.openjdk.java.net/~tnakamura/8232846/webrev.02/ Thanks, Toshio > From: Yasumasa Suenaga > > Ok, your change looks good. > > > Thanks, > > Yasumasa > > On 2020/03/27 18:10, Toshio 5 Nakamura wrote: > > Hi Suenaga-san, > > Thank you for the comment. I updated the limit to 32768. > > webrev.02: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.02&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=PIzjJwY4DhVqnxGp-4WusnNS4MlBy9PEGoCiCE9Hnaw&e= > > Well, I believe the new logic works as same as the current one. > > I added NULL initialization to commandObj, and the value will be > changed only if QueryFullProcessImageNameW() was success. > > Then, CHECK_NULL(commandObj) works as "return" if commandObj is NULL. > > src/java.base/share/native/libjava/jni_util.h > > > #define CHECK_NULL(x)?????????????????????????? \ > > >???? do {??????????????????????????????????????? \ > > >???????? if ((x) == NULL) {????????????????????? \ > > >???????????? return;???????????????????????????? \ > > >???????? }?????????????????????????????????????? \ > > >???? } while (0)???????????????????????????????? \ > > I hope this solves your concern. > > Best regards, > > Toshio Nakamura > > > > ----- Original message ----- > > Nakamura-san, > > > > I think location of CHECK_NULL and SetObjectField() are incorrect. > > Currently they are called when QueryFullProcessImageName() succeed only. > > > > In addition, you need to allocate 32768 chars (32767 + 1 ('\0')) via malloc. > > I understand "32767" is max length, not includes null-terminator. > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2020/03/27 14:06, Toshio 5 Nakamura wrote: > > > > > > Hi Roger, Suenaga-san, > > > > > > Thank you for your comments and discussion for the issue. > > > I've updated webrev. Could you review it again? > > > tier1 tests passed. > > > > > > webrev.01: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.01&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=sSZ6mylujPpWlHliOmnz9ukEJoaJrOnLJWuTptntVj8&e= > > > > > > Best regards, > > > Toshio Nakamura > > > > > > Yasumasa Suenaga wrote on 2020/ > 03/27 09:10:15: > > > > > >> On 2020/03/27 9:01, Roger Riggs wrote: > > >>> Hi, > > >>> > > >>> Please don't throw an exception. > > >>> It would abort being able to provide any information. > > >>> And who would expect or handle such an exception? > > >>> > > >>> Degrading the info or omitting it provides better service overall. > > >>> There is no point to throwing an exception. > > >> > > >> hProcess in QueryFullProcessImageNameW needs > > >> PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION > > >> access right, so I thought it is reasonable to throw runtime > > >> exception if the call failed. > > >> > > >> Anyway, I agree with you if throwing exception is not comfortable in > > >> this case for Java API. > > >> > > >> > > >> Thanks, > > >> > > >> Yasumasa > > >> > > >> > > >>> Regards, Roger > > >>> > > >>> > > >>> On 3/26/20 7:55 PM, Yasumasa Suenaga wrote: > > >>>> On 2020/03/27 0:35, Roger Riggs wrote: > > >>>>> Hi, > > >>>>> > > >>>>> Reading further down the reference to the section: > > >>>>> "Enable Long Paths in Windows 10, Version 1607, and Later" > > >>>>> might suggest the code be more resilient to long paths. > > >>>>> > > >>>>> The stack allocated buffer (1024) is fine, but I'd suggest > > >> adding code to retry in the case > > >>>>> of INSUFFICIENT BUFFER with a malloc'd buffer to make it more > > >> robust since the enabling > > >>>>> of long paths is environment and application specific. > > >>>> > > >>>> In addition, it's better to throw an exception if the call failed > > >> due to other error code. > > >>>> > > >>>> Thanks, > > >>>> > > >>>> Yasumasa > > >>>> > > >>>> > > >>>>> Thanks, Roger > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: > > >>>>>> Hi Thomas, Suenaga-san, Roger, > > >>>>>> > > >>>>>> Thank you for reviewing and comments. > > >>>>>> > > >>>>>> I checked behaviors by a small program and debugger. > > >>>>>> If QueryFullProcessImageNameW failed by not enough buffer, > > >>>>>> the API didn't change the buffer. > > >>>>>> It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. > > >>>>>> > > >>>>>> The buffer size becomes 1024 characters (2048 bytes) by this patch. > > >>>>>> Should it use bigger size with malloc? 32,767 characters can be limit > > > [2]. > > >>>>>> I feel 1024 is reasonable value for command's location. > > >>>>>> > > >>>>>> [2] https://urldefense.com/v3/__https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file*maximum-path-length-limitation__;Iw!!GqivPVa7Brio!PgzCcUQOjCNpcVeetU_drS4DFFVLaj0ceJBvipX7iDc_RlPtcEkdH8AzelGtzqXS $ > > >>>>>> Best regards, > > >>>>>> Toshio Nakamura > > >>>>>> > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> If the call fails, the command field in the info will not be set (and > > >>>>>>> therefore null). > > >>>>>>> > > >>>>>>> I agree that a length of 512 (characters) is probablytoo small. > > >>>>>>> > > >>>>>>> Roger > > >>>>>>> > > >>>>>>> > > >>>>>>> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: > > >>>>>>>> Hi Nakamura-san, > > >>>>>>>> > > >>>>>>>> Your change almost looks good, but I have one question. > > >>>>>>>> Length of exeName (1024) is enough? > > >>>>>>>> > > >>>>>>>> According to Microsoft Doc [1], exeName might not be null-terminated > > >>>>>>>> if it failed. > > >>>>>>>> I concern buffer overrun might occur when QueryFullProcessImageNameW > > >>>>>>>> failed. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> > > >>>>>>>> Yasumasa > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> [1] > > >>>>>> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_api_winbase_nf-2Dwinbase-2Dqueryfullprocessimagenamew&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=V6oP8SJvlxIc2iOxIOAcY6_mznTaxta2tyCV2iVzD3I&e= > > > > > >>>>>> > > >>>>>>>> > > >>>>>>>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: > > >>>>>>>>> Hi All, > > >>>>>>>>> > > >>>>>>>>> Could you review this change? Additionally, I'd like to ask a sponsor > > >>>>>>>>> for it, since I'm not a committer. > > >>>>>>>>> > > >>>>>>>>> Bug: > > >>>>>> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232846&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=8iQnOHT0GkoAZsYE39mDmx8036dUvvDbcj4tjCaPyps&e= > > > > > >>>>>> > > >>>>>>>>> Webrev: > > >>>>>> > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.00&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=0avs_hvCJdUYCP8WPu8Ttlo4sLwbwuFs2wWV0Szc9gg&e= > > > > >>>>>>>>> Under Windows environments, ProcessHandle.Info.command shows question marks > > >>>>>>>>> if the command has non-English characters. I'd like to change the > > >>>>>>>>> underlying API to Unicode version. > > >>>>>>>>> Tier1 tests passed. > > >>>>>>>>> > > >>>>>>>>> Best regards, > > >>>>>>>>> Toshio Nakamura > > >>>>>>>>> From jan.lahoda at oracle.com Fri Mar 27 11:31:33 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 27 Mar 2020 12:31:33 +0100 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: Hi Mandy, Regarding the javac changes - should those be switched on/off depending the Target? Or, if one compiles with e.g. --release 14, will the newly generated output still work on JDK 14? Jan On 27. 03. 20 0:57, Mandy Chung wrote: > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area.? Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > > Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point > of view, a hidden class is a normal class except the following: > > - A hidden class has no initiating class loader and is not registered in > any dictionary. > - A hidden class has a name containing an illegal character > `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` > returns "Lp/Foo.0x1234;". > - A hidden class is not modifiable, i.e. cannot be redefined or > retransformed. JVM TI IsModifableClass returns false on a hidden. > - Final fields in a hidden class is "final".? The value of final fields > cannot be overriden via reflection.? setAccessible(true) can still be > called on reflected objects representing final fields in a hidden class > and its access check will be suppressed but only have read-access (i.e. > can do Field::getXXX but not setXXX). > > Brief summary of this patch: > > 1. A new Lookup::defineHiddenClass method is the API to create a hidden > class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG > option that > ?? can be specified when creating a hidden class. > 3. A new Class::isHiddenClass method tests if a class is a hidden class. > 4. Field::setXXX method will throw IAE on a final field of a hidden class > ?? regardless of the value of the accessible flag. > 5. JVM_LookupDefineClass is the new JVM entry point for Lookup::defineClass > ?? and defineHiddenClass to create a class from the given bytes. > 6. ClassLoaderData implementation is not changed.? There is one primary CLD > ?? that holds the classes strongly referenced by its defining loader. > There > ?? can be zero or more additional CLDs - one per weak class. > 7. Nest host determination is updated per revised JVMS 5.4.4. Access > control > ?? check no longer throws LinkageError but instead it will throw IAE with > ?? a clear message if a class fails to resolve/validate the nest host > declared > ?? in NestHost/NestMembers attribute. > 8. JFR, jcmd, JDI are updated to support hidden classes. > 9. update javac LambdaToMethod as lambda proxy starts using nestmates > ?? and generate a bridge method to desuger a method reference to a > protected > ?? method in its supertype in a different package > > This patch also updates StringConcatFactory, LambdaMetaFactory, and > LambdaForms > to use hidden classes.? The webrev includes changes in nashorn to hidden > class > and I will update the webrev if JEP 372 removes it any time soon. > > We uncovered a bug in Lookup::defineClass spec throws LinkageError and > intends > to have the newly created class linked.? However, the implementation in 14 > does not link the class.? A separate CSR [2] proposes to update the > implementation to match the spec.? This patch fixes the implementation. > > The spec update on JVM TI, JDI and Instrumentation will be done as > a separate RFE [3].? This patch includes new tests for JVM TI and > java.instrument that validates how the existing APIs work for hidden > classes. > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From forax at univ-mlv.fr Fri Mar 27 12:00:06 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 27 Mar 2020 13:00:06 +0100 (CET) Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <1271059704.1214239.1585310406005.JavaMail.zimbra@u-pem.fr> Hi Mandy, in ReflectionFactory, why in the case of a constructor the check to the anonymous class is removed ? in BytecodeGenerator, the comment "// bootstrapping issue if using condy" can be promoted on top of clinit, because i ask myself the same question seeing a static block was generated in AbstractValidatingLambdaMetafactory.java, the field caller is not used after all ? regards, R?mi ----- Mail original ----- > De: "mandy chung" > ?: "valhalla-dev" , "core-libs-dev" , > "serviceability-dev" , "hotspot-dev" > Envoy?: Vendredi 27 Mars 2020 00:57:39 > Objet: Review Request: 8238358: Implementation of JEP 371: Hidden Classes > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area.? Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point > of view, a hidden class is a normal class except the following: > > - A hidden class has no initiating class loader and is not registered in > any dictionary. > - A hidden class has a name containing an illegal character > `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` > returns "Lp/Foo.0x1234;". > - A hidden class is not modifiable, i.e. cannot be redefined or > retransformed. JVM TI IsModifableClass returns false on a hidden. > - Final fields in a hidden class is "final".? The value of final fields > cannot be overriden via reflection.? setAccessible(true) can still be > called on reflected objects representing final fields in a hidden class > and its access check will be suppressed but only have read-access (i.e. > can do Field::getXXX but not setXXX). > > Brief summary of this patch: > > 1. A new Lookup::defineHiddenClass method is the API to create a hidden > class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG > option that > ?? can be specified when creating a hidden class. > 3. A new Class::isHiddenClass method tests if a class is a hidden class. > 4. Field::setXXX method will throw IAE on a final field of a hidden class > ?? regardless of the value of the accessible flag. > 5. JVM_LookupDefineClass is the new JVM entry point for Lookup::defineClass > ?? and defineHiddenClass to create a class from the given bytes. > 6. ClassLoaderData implementation is not changed.? There is one primary CLD > ?? that holds the classes strongly referenced by its defining loader. > There > ?? can be zero or more additional CLDs - one per weak class. > 7. Nest host determination is updated per revised JVMS 5.4.4. Access control > ?? check no longer throws LinkageError but instead it will throw IAE with > ?? a clear message if a class fails to resolve/validate the nest host > declared > ?? in NestHost/NestMembers attribute. > 8. JFR, jcmd, JDI are updated to support hidden classes. > 9. update javac LambdaToMethod as lambda proxy starts using nestmates > ?? and generate a bridge method to desuger a method reference to a > protected > ?? method in its supertype in a different package > > This patch also updates StringConcatFactory, LambdaMetaFactory, and > LambdaForms > to use hidden classes.? The webrev includes changes in nashorn to hidden > class > and I will update the webrev if JEP 372 removes it any time soon. > > We uncovered a bug in Lookup::defineClass spec throws LinkageError and > intends > to have the newly created class linked.? However, the implementation in 14 > does not link the class.? A separate CSR [2] proposes to update the > implementation to match the spec.? This patch fixes the implementation. > > The spec update on JVM TI, JDI and Instrumentation will be done as > a separate RFE [3].? This patch includes new tests for JVM TI and > java.instrument that validates how the existing APIs work for hidden > classes. > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From pavel.rappo at oracle.com Fri Mar 27 12:09:42 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 27 Mar 2020 12:09:42 +0000 Subject: [15] RFR 8241727 : Typos: empty lines in javadoc, inconsistent indents, etc. (core-libs only) In-Reply-To: References: Message-ID: <21FDAF1A-BC4F-4946-BA4A-EBFF0415CF63@oracle.com> 140 a successful * query to a constant will always remain successful. Made me pause and read a bit of the surrounding context to make sure there's no "*" type of query. Looks good to me. Thanks for doing this. -Pavel > On 27 Mar 2020, at 10:26, Ivan Gerasimov wrote: > > Hello! > > This is a javadoc-only fix. > > There are a few changes that will actually be visible (for example [1], [2]), but the vast majority of changes are to remove redundant empty lines, correct indentation, or otherwise restore harmony. > > Would you please help review this rather technical fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8241727 > WEBREV: http://cr.openjdk.java.net/~igerasim/8241727/00/webrev/ > > Thank in advance! > > [1] Extra '+' in text: https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/io/ObjectInputStream.html#readObjectOverride() > > [2] Extra 'I' in text: https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/annotation/Annotation.html#hashCode() > > -- > > With kind regards, > Ivan Gerasimov > From Roger.Riggs at oracle.com Fri Mar 27 14:24:14 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 27 Mar 2020 10:24:14 -0400 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: <063fb628-a25d-500a-b495-c6a7364bb2de@oracle.com> Message-ID: Hi Toshio, Looks good, I can sponsor it. Thanks, Roger On 3/27/20 6:46 AM, Toshio 5 Nakamura wrote: > Thank you for review, Suenaga-san, Thomas. > > (My mail in html format was blocked by the list. Sorry for inconvenience.) > > The latest webrev is 02: > http://cr.openjdk.java.net/~tnakamura/8232846/webrev.02/ > > Thanks, > Toshio > >> From: Yasumasa Suenaga >> >> Ok, your change looks good. >> >> >> Thanks, >> >> Yasumasa >> >> On 2020/03/27 18:10, Toshio 5 Nakamura wrote: >>> Hi Suenaga-san, >>> Thank you for the comment. I updated the limit to 32768. >>> webrev.02: > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.02&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=PIzjJwY4DhVqnxGp-4WusnNS4MlBy9PEGoCiCE9Hnaw&e= > >>> Well, I believe the new logic works as same as the current one. >>> I added NULL initialization to commandObj, and the value will be >> changed only if QueryFullProcessImageNameW() was success. >>> Then, CHECK_NULL(commandObj) works as "return" if commandObj is NULL. >>> src/java.base/share/native/libjava/jni_util.h >>> > #define CHECK_NULL(x)?????????????????????????? \ >>> >???? do {??????????????????????????????????????? \ >>> >???????? if ((x) == NULL) {????????????????????? \ >>> >???????????? return;???????????????????????????? \ >>> >???????? }?????????????????????????????????????? \ >>> >???? } while (0)???????????????????????????????? \ >>> I hope this solves your concern. >>> Best regards, >>> Toshio Nakamura >>> >>> ----- Original message ----- >>> Nakamura-san, >>> >>> I think location of CHECK_NULL and SetObjectField() are incorrect. >>> Currently they are called when QueryFullProcessImageName() succeed > only. >>> In addition, you need to allocate 32768 chars (32767 + 1 ('\0')) > via malloc. >>> I understand "32767" is max length, not includes null-terminator. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/03/27 14:06, Toshio 5 Nakamura wrote: >>> > >>> > Hi Roger, Suenaga-san, >>> > >>> > Thank you for your comments and discussion for the issue. >>> > I've updated webrev. Could you review it again? >>> > tier1 tests passed. >>> > >>> > webrev.01: > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.01&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=sSZ6mylujPpWlHliOmnz9ukEJoaJrOnLJWuTptntVj8&e= > >>> > >>> > Best regards, >>> > Toshio Nakamura >>> > >>> > Yasumasa Suenaga wrote on 2020/ >> 03/27 09:10:15: >>> > >>> >> On 2020/03/27 9:01, Roger Riggs wrote: >>> >>> Hi, >>> >>> >>> >>> Please don't throw an exception. >>> >>> It would abort being able to provide any information. >>> >>> And who would expect or handle such an exception? >>> >>> >>> >>> Degrading the info or omitting it provides better service > overall. >>> >>> There is no point to throwing an exception. >>> >> >>> >> hProcess in QueryFullProcessImageNameW needs >>> >> PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION >>> >> access right, so I thought it is reasonable to throw runtime >>> >> exception if the call failed. >>> >> >>> >> Anyway, I agree with you if throwing exception is not > comfortable in >>> >> this case for Java API. >>> >> >>> >> >>> >> Thanks, >>> >> >>> >> Yasumasa >>> >> >>> >> >>> >>> Regards, Roger >>> >>> >>> >>> >>> >>> On 3/26/20 7:55 PM, Yasumasa Suenaga wrote: >>> >>>> On 2020/03/27 0:35, Roger Riggs wrote: >>> >>>>> Hi, >>> >>>>> >>> >>>>> Reading further down the reference to the section: >>> >>>>> "Enable Long Paths in Windows 10, Version 1607, and Later" >>> >>>>> might suggest the code be more resilient to long paths. >>> >>>>> >>> >>>>> The stack allocated buffer (1024) is fine, but I'd suggest >>> >> adding code to retry in the case >>> >>>>> of INSUFFICIENT BUFFER with a malloc'd buffer to make it > more >>> >> robust since the enabling >>> >>>>> of long paths is environment and application specific. >>> >>>> >>> >>>> In addition, it's better to throw an exception if the call > failed >>> >> due to other error code. >>> >>>> >>> >>>> Thanks, >>> >>>> >>> >>>> Yasumasa >>> >>>> >>> >>>> >>> >>>>> Thanks, Roger >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: >>> >>>>>> Hi Thomas, Suenaga-san, Roger, >>> >>>>>> >>> >>>>>> Thank you for reviewing and comments. >>> >>>>>> >>> >>>>>> I checked behaviors by a small program and debugger. >>> >>>>>> If QueryFullProcessImageNameW failed by not enough buffer, >>> >>>>>> the API didn't change the buffer. >>> >>>>>> It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. >>> >>>>>> >>> >>>>>> The buffer size becomes 1024 characters (2048 bytes) by > this patch. >>> >>>>>> Should it use bigger size with malloc? 32,767 characters > can be limit >>> > [2]. >>> >>>>>> I feel 1024 is reasonable value for command's location. >>> >>>>>> >>> >>>>>> [2] > https://urldefense.com/v3/__https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file*maximum-path-length-limitation__;Iw!!GqivPVa7Brio!PgzCcUQOjCNpcVeetU_drS4DFFVLaj0ceJBvipX7iDc_RlPtcEkdH8AzelGtzqXS > $ >>> >>>>>> Best regards, >>> >>>>>> Toshio Nakamura >>> >>>>>> >>> >>>>>>> Hi, >>> >>>>>>> >>> >>>>>>> If the call fails, the command field in the info will not > be set (and >>> >>>>>>> therefore null). >>> >>>>>>> >>> >>>>>>> I agree that a length of 512 (characters) is probablytoo > small. >>> >>>>>>> >>> >>>>>>> Roger >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: >>> >>>>>>>> Hi Nakamura-san, >>> >>>>>>>> >>> >>>>>>>> Your change almost looks good, but I have one question. >>> >>>>>>>> Length of exeName (1024) is enough? >>> >>>>>>>> >>> >>>>>>>> According to Microsoft Doc [1], exeName might not be > null-terminated >>> >>>>>>>> if it failed. >>> >>>>>>>> I concern buffer overrun might occur when > QueryFullProcessImageNameW >>> >>>>>>>> failed. >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> Thanks, >>> >>>>>>>> >>> >>>>>>>> Yasumasa >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> [1] >>> >>>>>> >>> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_api_winbase_nf-2Dwinbase-2Dqueryfullprocessimagenamew&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=V6oP8SJvlxIc2iOxIOAcY6_mznTaxta2tyCV2iVzD3I&e= > >>> > >>> >>>>>> >>> >>>>>>>> >>> >>>>>>>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: >>> >>>>>>>>> Hi All, >>> >>>>>>>>> >>> >>>>>>>>> Could you review this change? Additionally, I'd like to > ask a sponsor >>> >>>>>>>>> for it, since I'm not a committer. >>> >>>>>>>>> >>> >>>>>>>>> Bug: >>> >>>>>> >>> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232846&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=8iQnOHT0GkoAZsYE39mDmx8036dUvvDbcj4tjCaPyps&e= > >>> > >>> >>>>>> >>> >>>>>>>>> Webrev: >>> >>>>>> >>> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.00&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=0avs_hvCJdUYCP8WPu8Ttlo4sLwbwuFs2wWV0Szc9gg&e= > >>> >>>>>>>>> Under Windows environments, ProcessHandle.Info.command > shows question marks >>> >>>>>>>>> if the command has non-English characters. I'd like to > change the >>> >>>>>>>>> underlying API to Unicode version. >>> >>>>>>>>> Tier1 tests passed. >>> >>>>>>>>> >>> >>>>>>>>> Best regards, >>> >>>>>>>>> Toshio Nakamura >>> >>>>>>>>> From TOSHIONA at jp.ibm.com Fri Mar 27 14:52:18 2020 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Fri, 27 Mar 2020 23:52:18 +0900 Subject: RFR: 8232846: ProcessHandle.Info command with non-English shows question marks In-Reply-To: References: <063fb628-a25d-500a-b495-c6a7364bb2de@oracle.com> Message-ID: Hi Roger, Thank you so much for the review and being sponsor this fix. Best regards, Toshio > From: Roger Riggs > > Hi Toshio, > > Looks good, > > I can sponsor it. > > Thanks, Roger > > On 3/27/20 6:46 AM, Toshio 5 Nakamura wrote: > > Thank you for review, Suenaga-san, Thomas. > > > > (My mail in html format was blocked by the list. Sorry for inconvenience.) > > > > The latest webrev is 02: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.02_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=NbJbA8eszoW-rk4brJaNlSeZiHqZPeE8XFp2akykxQU&s=o0kV8G3aphifHI_0bBpRcnkyOBvB9i63nXBUiS1-mjY&e= > > > > Thanks, > > Toshio > > > >> From: Yasumasa Suenaga > >> > >> Ok, your change looks good. > >> > >> > >> Thanks, > >> > >> Yasumasa > >> > >> On 2020/03/27 18:10, Toshio 5 Nakamura wrote: > >>> Hi Suenaga-san, > >>> Thank you for the comment. I updated the limit to 32768. > >>> webrev.02: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.02&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=PIzjJwY4DhVqnxGp-4WusnNS4MlBy9PEGoCiCE9Hnaw&e= > > > >>> Well, I believe the new logic works as same as the current one. > >>> I added NULL initialization to commandObj, and the value will be > >> changed only if QueryFullProcessImageNameW() was success. > >>> Then, CHECK_NULL(commandObj) works as "return" if commandObj is NULL. > >>> src/java.base/share/native/libjava/jni_util.h > >>> > #define CHECK_NULL(x)?????????????????????????? \ > >>> >???? do {??????????????????????????????????????? \ > >>> >???????? if ((x) == NULL) {????????????????????? \ > >>> >???????????? return;???????????????????????????? \ > >>> >???????? }?????????????????????????????????????? \ > >>> >???? } while (0)???????????????????????????????? \ > >>> I hope this solves your concern. > >>> Best regards, > >>> Toshio Nakamura > >>> > >>> ----- Original message ----- > >>> Nakamura-san, > >>> > >>> I think location of CHECK_NULL and SetObjectField() are incorrect. > >>> Currently they are called when QueryFullProcessImageName() succeed only. > >>> In addition, you need to allocate 32768 chars (32767 + 1 ('\0')) via malloc. > >>> I understand "32767" is max length, not includes null-terminator. > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >>> > >>> > >>> On 2020/03/27 14:06, Toshio 5 Nakamura wrote: > >>> > > >>> > Hi Roger, Suenaga-san, > >>> > > >>> > Thank you for your comments and discussion for the issue. > >>> > I've updated webrev. Could you review it again? > >>> > tier1 tests passed. > >>> > > >>> > webrev.01: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.01&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=sSZ6mylujPpWlHliOmnz9ukEJoaJrOnLJWuTptntVj8&e= > >>> > > >>> > Best regards, > >>> > Toshio Nakamura > >>> > > >>> > Yasumasa Suenaga wrote on 2020/ > >> 03/27 09:10:15: > >>> > > >>> >> On 2020/03/27 9:01, Roger Riggs wrote: > >>> >>> Hi, > >>> >>> > >>> >>> Please don't throw an exception. > >>> >>> It would abort being able to provide any information. > >>> >>> And who would expect or handle such an exception? > >>> >>> > >>> >>> Degrading the info or omitting it provides better service overall. > >>> >>> There is no point to throwing an exception. > >>> >> > >>> >> hProcess in QueryFullProcessImageNameW needs > >>> >> PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION > >>> >> access right, so I thought it is reasonable to throw runtime > >>> >> exception if the call failed. > >>> >> > >>> >> Anyway, I agree with you if throwing exception is not comfortable in > >>> >> this case for Java API. > >>> >> > >>> >> > >>> >> Thanks, > >>> >> > >>> >> Yasumasa > >>> >> > >>> >> > >>> >>> Regards, Roger > >>> >>> > >>> >>> > >>> >>> On 3/26/20 7:55 PM, Yasumasa Suenaga wrote: > >>> >>>> On 2020/03/27 0:35, Roger Riggs wrote: > >>> >>>>> Hi, > >>> >>>>> > >>> >>>>> Reading further down the reference to the section: > >>> >>>>> "Enable Long Paths in Windows 10, Version 1607, and Later" > >>> >>>>> might suggest the code be more resilient to long paths. > >>> >>>>> > >>> >>>>> The stack allocated buffer (1024) is fine, but I'd suggest > >>> >> adding code to retry in the case > >>> >>>>> of INSUFFICIENT BUFFER with a malloc'd buffer to make it more > >>> >> robust since the enabling > >>> >>>>> of long paths is environment and application specific. > >>> >>>> > >>> >>>> In addition, it's better to throw an exception if the call failed > >>> >> due to other error code. > >>> >>>> > >>> >>>> Thanks, > >>> >>>> > >>> >>>> Yasumasa > >>> >>>> > >>> >>>> > >>> >>>>> Thanks, Roger > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>> On 3/26/20 10:40 AM, Toshio 5 Nakamura wrote: > >>> >>>>>> Hi Thomas, Suenaga-san, Roger, > >>> >>>>>> > >>> >>>>>> Thank you for reviewing and comments. > >>> >>>>>> > >>> >>>>>> I checked behaviors by a small program and debugger. > >>> >>>>>> If QueryFullProcessImageNameW failed by not enough buffer, > >>> >>>>>> the API didn't change the buffer. > >>> >>>>>> It just set ERROR_INSUFFICIENT_BUFFER(0x7a) to LastError. > >>> >>>>>> > >>> >>>>>> The buffer size becomes 1024 characters (2048 bytes) by this patch. > >>> >>>>>> Should it use bigger size with malloc? 32,767 characters can be limit > >>> > [2]. > >>> >>>>>> I feel 1024 is reasonable value for command's location. > >>> >>>>>> > >>> >>>>>> [2] > > https://urldefense.com/v3/__https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file*maximum-path-length-limitation__;Iw!!GqivPVa7Brio!PgzCcUQOjCNpcVeetU_drS4DFFVLaj0ceJBvipX7iDc_RlPtcEkdH8AzelGtzqXS $ > >>> >>>>>> Best regards, > >>> >>>>>> Toshio Nakamura > >>> >>>>>> > >>> >>>>>>> Hi, > >>> >>>>>>> > >>> >>>>>>> If the call fails, the command field in the info will not be set (and > >>> >>>>>>> therefore null). > >>> >>>>>>> > >>> >>>>>>> I agree that a length of 512 (characters) is probablytoo small. > >>> >>>>>>> > >>> >>>>>>> Roger > >>> >>>>>>> > >>> >>>>>>> > >>> >>>>>>> On 3/26/20 6:37 AM, Yasumasa Suenaga wrote: > >>> >>>>>>>> Hi Nakamura-san, > >>> >>>>>>>> > >>> >>>>>>>> Your change almost looks good, but I have one question. > >>> >>>>>>>> Length of exeName (1024) is enough? > >>> >>>>>>>> > >>> >>>>>>>> According to Microsoft Doc [1], exeName might not be null-terminated > >>> >>>>>>>> if it failed. > >>> >>>>>>>> I concern buffer overrun might occur when QueryFullProcessImageNameW > >>> >>>>>>>> failed. > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> Thanks, > >>> >>>>>>>> > >>> >>>>>>>> Yasumasa > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_api_winbase_nf-2Dwinbase-2Dqueryfullprocessimagenamew&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=V6oP8SJvlxIc2iOxIOAcY6_mznTaxta2tyCV2iVzD3I&e= > >>> >>>>>>>> > >>> >>>>>>>> On 2020/03/26 17:58, Toshio 5 Nakamura wrote: > >>> >>>>>>>>> Hi All, > >>> >>>>>>>>> > >>> >>>>>>>>> Could you review this change? Additionally, I'd like to ask a sponsor > >>> >>>>>>>>> for it, since I'm not a committer. > >>> >>>>>>>>> > >>> >>>>>>>>> Bug: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232846&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=8iQnOHT0GkoAZsYE39mDmx8036dUvvDbcj4tjCaPyps&e= > >>> >>>>>> > >>> >>>>>>>>> Webrev: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8232846_webrev.00&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=wzpmzDaZdDfLKNqZprr1X6d_EdWvLpBWS6fMzVNeu3w&s=0avs_hvCJdUYCP8WPu8Ttlo4sLwbwuFs2wWV0Szc9gg&e= > > > >>> >>>>>>>>> Under Windows environments, ProcessHandle.Info.command shows question marks > >>> >>>>>>>>> if the command has non-English characters. I'd like to change the > >>> >>>>>>>>> underlying API to Unicode version. > >>> >>>>>>>>> Tier1 tests passed. > >>> >>>>>>>>> > >>> >>>>>>>>> Best regards, > >>> >>>>>>>>> Toshio Nakamura > >>> >>>>>>>>> > From raffaello.giulietti at gmail.com Fri Mar 27 15:12:11 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 27 Mar 2020 16:12:11 +0100 Subject: REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results Message-ID: <0bee1f31-597e-1717-72ee-6495514137b9@gmail.com> Hello, here's the periodic monthly reminder that the latest patches to overcome [1] have been submitted [2] and are waiting for a review. Full background documentation is available at [3]. Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8202555 [2] http://cr.openjdk.java.net/~bpb/4511638/webrev.04/ [3] https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN From MRasmussen at perforce.com Fri Mar 27 15:34:09 2020 From: MRasmussen at perforce.com (Michael Rasmussen) Date: Fri, 27 Mar 2020 15:34:09 +0000 Subject: ClassLoader used in Module.loadModuleInfoClass should be self-first Message-ID: The ClassLoader used to create the pseudo module-info interface is parent-first, so if there are any modules on the classpath, it will try to load the module-info.class file from there instead of the synthetic that is being generated in the method. This interface is generated if you try to read annotations from the Module. Simple example to reproduce: /* --- module-info.java --- */ @Deprecated module com.test {} /* --- com/test/Main.java --- */ package com.test; public class Main { public static void main(String[] args) throws Exception { System.out.println(Main.class.getModule().isAnnotationPresent(Deprecated.class)); } } > java -p target/classes -m com.test/com.test.Main true > java -cp target/classes -p target/classes -m com.test/com.test.Main Exception in thread "main" java.lang.NoClassDefFoundError: module-info is not a class because access_flag ACC_MODULE is set at java.base/java.lang.ClassLoader.defineClass1(Native Method) at (.....) The problem here is that the ClassLoader is parent-first, so it will search parent for a "module-info" class, and use that if it finds it. If the ClassLoader was self-first this problem would not appear, it would still delegate to parent for everything but the synthetic module-info class. /Michael This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. From mandy.chung at oracle.com Fri Mar 27 15:50:55 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 Mar 2020 08:50:55 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <1271059704.1214239.1585310406005.JavaMail.zimbra@u-pem.fr> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1271059704.1214239.1585310406005.JavaMail.zimbra@u-pem.fr> Message-ID: On 3/27/20 5:00 AM, Remi Forax wrote: > Hi Mandy, > in ReflectionFactory, why in the case of a constructor the check to the anonymous class is removed ? Good catch.? Fixed > > in BytecodeGenerator, the comment "// bootstrapping issue if using condy" > can be promoted on top of clinit, because i ask myself the same question seeing a static block was generated OK, that's clearer. > > in AbstractValidatingLambdaMetafactory.java, the field caller is not used after all ? Thanks.? Removed.? It was left behind from an early prototype. Below is the patch.? I will send out a new webrev and delta webrev in the next revision. thanks Mandy diff --git a/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java b/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java --- a/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java +++ b/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java @@ -51,7 +51,6 @@ ????? *???????? System.out.printf(">>> %s\n", iii.foo(44)); ????? * }} ????? */ -??? final MethodHandles.Lookup caller; ???? final Class targetClass;?????????????? // The class calling the meta-factory via invokedynamic "class X" ???? final MethodType invokedType;???????????? // The type of the invoked method "(CC)II" ???? final Class samBase;?????????????????? // The type of the returned instance "interface JJ" @@ -121,7 +120,6 @@ ???????????????????? "Invalid caller: %s", ???????????????????? caller.lookupClass().getName())); ???????? } -??????? this.caller = caller; ???????? this.targetClass = caller.lookupClass(); ???????? this.invokedType = invokedType; diff --git a/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java b/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java --- a/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java +++ b/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java @@ -363,6 +363,10 @@ ???????? clinit(cw, className(), classData); ???? } +??? /* +???? * to initialize the static final fields with the live class data +???? * LambdaForms can't use condy due to bootstrapping issue. +???? */ ???? static void clinit(ClassWriter cw, String className, List classData) { ???????? if (classData.isEmpty()) ???????????? return; @@ -375,7 +379,6 @@ ???????? MethodVisitor mv = cw.visitMethod(Opcodes.ACC_STATIC, "", "()V", null, null); ???????? mv.visitCode(); -??????? // bootstrapping issue if using condy ???????? mv.visitLdcInsn(Type.getType("L" + className + ";")); ???????? mv.visitMethodInsn(Opcodes.INVOKESTATIC, "java/lang/invoke/MethodHandleNatives", ??????????????????????????? "classData", "(Ljava/lang/Class;)Ljava/lang/Object;", false); diff --git a/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java b/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java --- a/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java +++ b/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java @@ -245,7 +245,8 @@ ???????????? return new BootstrapConstructorAccessorImpl(c); ???????? } -??????? if (noInflation && !c.getDeclaringClass().isHiddenClass()) { +??????? if (noInflation && !c.getDeclaringClass().isHiddenClass() +??????????????? && !ReflectUtil.isVMAnonymousClass(c.getDeclaringClass())) { ???????????? return new MethodAccessorGenerator(). ???????????????? generateConstructor(c.getDeclaringClass(), ???????????????????????????????????? c.getParameterTypes(), From forax at univ-mlv.fr Fri Mar 27 15:54:37 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 27 Mar 2020 16:54:37 +0100 (CET) Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1271059704.1214239.1585310406005.JavaMail.zimbra@u-pem.fr> Message-ID: <387396409.1414184.1585324477993.JavaMail.zimbra@u-pem.fr> > De: "mandy chung" > ?: "Remi Forax" > Cc: "valhalla-dev" , "core-libs-dev" > , "serviceability-dev" > , "hotspot-dev" > > Envoy?: Vendredi 27 Mars 2020 16:50:55 > Objet: Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes > On 3/27/20 5:00 AM, Remi Forax wrote: >> Hi Mandy, >> in ReflectionFactory, why in the case of a constructor the check to the >> anonymous class is removed ? > Good catch. Fixed >> in BytecodeGenerator, the comment "// bootstrapping issue if using condy" >> can be promoted on top of clinit, because i ask myself the same question seeing >> a static block was generated > OK, that's clearer. >> in AbstractValidatingLambdaMetafactory.java, the field caller is not used after >> all ? > Thanks. Removed. It was left behind from an early prototype. > Below is the patch. I will send out a new webrev and delta webrev in the next > revision. Thanks Mandy, Looks good. R?mi > thanks > Mandy > diff --git > a/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java > b/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java > --- > a/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java > +++ > b/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java > @@ -51,7 +51,6 @@ > * System.out.printf(">>> %s\n", iii.foo(44)); > * }} > */ > - final MethodHandles.Lookup caller; > final Class targetClass; // The class calling the meta-factory via > invokedynamic "class X" > final MethodType invokedType; // The type of the invoked method "(CC)II" > final Class samBase; // The type of the returned instance "interface JJ" > @@ -121,7 +120,6 @@ > "Invalid caller: %s", > caller.lookupClass().getName())); > } > - this.caller = caller; > this.targetClass = caller.lookupClass(); > this.invokedType = invokedType; > diff --git > a/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java > b/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java > --- a/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java > +++ b/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java > @@ -363,6 +363,10 @@ > clinit(cw, className(), classData); > } > + /* > + * to initialize the static final fields with the live class data > + * LambdaForms can't use condy due to bootstrapping issue. > + */ > static void clinit(ClassWriter cw, String className, List classData) > { > if (classData.isEmpty()) > return; > @@ -375,7 +379,6 @@ > MethodVisitor mv = cw.visitMethod(Opcodes.ACC_STATIC, "", "()V", null, > null); > mv.visitCode(); > - // bootstrapping issue if using condy > mv.visitLdcInsn(Type.getType("L" + className + ";")); > mv.visitMethodInsn(Opcodes.INVOKESTATIC, "java/lang/invoke/MethodHandleNatives", > "classData", "(Ljava/lang/Class;)Ljava/lang/Object;", false); > diff --git > a/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java > b/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java > --- a/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java > +++ b/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java > @@ -245,7 +245,8 @@ > return new BootstrapConstructorAccessorImpl(c); > } > - if (noInflation && !c.getDeclaringClass().isHiddenClass()) { > + if (noInflation && !c.getDeclaringClass().isHiddenClass() > + && !ReflectUtil.isVMAnonymousClass(c.getDeclaringClass())) { > return new MethodAccessorGenerator(). > generateConstructor(c.getDeclaringClass(), > c.getParameterTypes(), From Alan.Bateman at oracle.com Fri Mar 27 16:21:52 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Mar 2020 16:21:52 +0000 Subject: ClassLoader used in Module.loadModuleInfoClass should be self-first In-Reply-To: References: Message-ID: <4e32f9fa-aea5-e288-a9db-12da078ef1c0@oracle.com> On 27/03/2020 15:34, Michael Rasmussen wrote: > The ClassLoader used to create the pseudo module-info interface is parent-first, so if there are any modules on the classpath, it will try to load the module-info.class file from there instead of the synthetic that is being generated in the method. This interface is generated if you try to read annotations from the Module. > Thanks, I've created JDK-8241770 [1] to track it. The special class loader should never delegate for the generated module-info. Surprised this hasn't come up before now but maybe not too many cases yet where a modular app has a module-info.class on the class path. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8241770 From mandy.chung at oracle.com Fri Mar 27 16:29:46 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 Mar 2020 09:29:46 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com> Hi Jan, Good point.? The javac change only applies to JDK 15 and later and the lambda proxy class is not a nestmate when running on JDK 14 or earlier. I probably need the help from langtools team to fix this.? I'll give it a try. Mandy On 3/27/20 4:31 AM, Jan Lahoda wrote: > Hi Mandy, > > Regarding the javac changes - should those be switched on/off > depending the Target? Or, if one compiles with e.g. --release 14, will > the newly generated output still work on JDK 14? > > Jan > > On 27. 03. 20 0:57, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area.? Small changes are >> made in javac, VM compiler (intrinsification of >> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed >> and is in the finalized state (see specdiff and javadoc below for >> reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >> point >> of view, a hidden class is a normal class except the following: >> >> - A hidden class has no initiating class loader and is not registered >> in any dictionary. >> - A hidden class has a name containing an illegal character >> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >> returns "Lp/Foo.0x1234;". >> - A hidden class is not modifiable, i.e. cannot be redefined or >> retransformed. JVM TI IsModifableClass returns false on a hidden. >> - Final fields in a hidden class is "final".? The value of final >> fields cannot be overriden via reflection.? setAccessible(true) can >> still be called on reflected objects representing final fields in a >> hidden class and its access check will be suppressed but only have >> read-access (i.e. can do Field::getXXX but not setXXX). >> >> Brief summary of this patch: >> >> 1. A new Lookup::defineHiddenClass method is the API to create a >> hidden class. >> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >> option that >> ??? can be specified when creating a hidden class. >> 3. A new Class::isHiddenClass method tests if a class is a hidden class. >> 4. Field::setXXX method will throw IAE on a final field of a hidden >> class >> ??? regardless of the value of the accessible flag. >> 5. JVM_LookupDefineClass is the new JVM entry point for >> Lookup::defineClass >> ??? and defineHiddenClass to create a class from the given bytes. >> 6. ClassLoaderData implementation is not changed.? There is one >> primary CLD >> ??? that holds the classes strongly referenced by its defining >> loader. There >> ??? can be zero or more additional CLDs - one per weak class. >> 7. Nest host determination is updated per revised JVMS 5.4.4. Access >> control >> ??? check no longer throws LinkageError but instead it will throw IAE >> with >> ??? a clear message if a class fails to resolve/validate the nest >> host declared >> ??? in NestHost/NestMembers attribute. >> 8. JFR, jcmd, JDI are updated to support hidden classes. >> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >> ??? and generate a bridge method to desuger a method reference to a >> protected >> ??? method in its supertype in a different package >> >> This patch also updates StringConcatFactory, LambdaMetaFactory, and >> LambdaForms >> to use hidden classes.? The webrev includes changes in nashorn to >> hidden class >> and I will update the webrev if JEP 372 removes it any time soon. >> >> We uncovered a bug in Lookup::defineClass spec throws LinkageError >> and intends >> to have the newly created class linked.? However, the implementation >> in 14 >> does not link the class.? A separate CSR [2] proposes to update the >> implementation to match the spec.? This patch fixes the implementation. >> >> The spec update on JVM TI, JDI and Instrumentation will be done as >> a separate RFE [3].? This patch includes new tests for JVM TI and >> java.instrument that validates how the existing APIs work for hidden >> classes. >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From paul.sandoz at oracle.com Fri Mar 27 18:59:10 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 27 Mar 2020 11:59:10 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <72EC6AFD-412B-4238-B98E-90AF8C185D98@oracle.com> Hi Mandy, Very thorough, bravo! Minor suggestions below. Paul. MethodHandleNatives.java ? 142 143 /** 144 * Flags for Lookup.ClassOptions 145 */ 146 static final int 147 NESTMATE_CLASS = 0x00000001, 148 HIDDEN_CLASS = 0x00000002, 149 STRONG_LOADER_LINK = 0x00000004, 150 ACCESS_VM_ANNOTATIONS = 0x00000008; 151 } Suggest you add a comment to keep the values in sync with the VM component. MethodHandles.java ? 1786 * (Given the {@code Lookup} object returned this method, its lookup class 1787 * is a {@code Class} object for which {@link Class#getName()} returns a string 1788 * that is not a binary name.) ? (The {@code Lookup} object returned from this method has a lookup class that is a {@code Class} object whose {@link Class#getName()} returns a string that is not a binary name.) ? 1902 Set opts = options.length > 0 ? Set.of(options) : Set.of(); You can just do: Set opts = Set.of(options) And/or inline it into the subsequent method call. The implementation of Set.of checks the array length. 2001 ClassDefiner makeHiddenClassDefiner(byte[] bytes, I think you can telescope the methods for non-name and name accepting since IIUC the name is derived from the byte[]. Thereby you can remove some code duplication. i.e. pull ClassDefiner.className out from ClassDefiner and place the logic in the factory methods. Alternative push the factory methods into ClassDefiner to keep all the logic together. 3797 public enum ClassOption { Shuffle up to be closer to the defineHiddenClass 3798 /** 3799 * This class option specifies the hidden class be added to 3800 * {@linkplain Class#getNestHost nest} of a lookup class as 3801 * a nestmate. Suggest: "This class option specifies the hidden class ? -> ?Specifies that a hidden class 3812 * This class option specifies the hidden class to have a strong ?Specifies that a hidden class have a ?" 3813 * relationship with the class loader marked as its defining loader, 3814 * as a normal class or interface has with its own defining loader. 3815 * This means that the hidden class may be unloaded if and only if 3816 * its defining loader is not reachable and thus may be reclaimed 3817 * by a garbage collector (JLS 12.7). StringConcatFactory.java ? 861 // use of @ForceInline no longer has any effect ? 862 mv.visitAnnotation("Ljdk/internal/vm/annotation/ForceInline;", true); 863 mv.visitCode(); > On Mar 26, 2020, at 4:57 PM, Mandy Chung wrote: > > Please review the implementation of JEP 371: Hidden Classes. The main changes are in core-libs and hotspot runtime area. Small changes are made in javac, VM compiler (intrinsification of Class::isHiddenClass), JFR, JDI, and jcmd. CSR [1]has been reviewed and is in the finalized state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point > of view, a hidden class is a normal class except the following: > > - A hidden class has no initiating class loader and is not registered in any dictionary. > - A hidden class has a name containing an illegal character `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` returns "Lp/Foo.0x1234;". > - A hidden class is not modifiable, i.e. cannot be redefined or retransformed. JVM TI IsModifableClass returns false on a hidden. > - Final fields in a hidden class is "final". The value of final fields cannot be overriden via reflection. setAccessible(true) can still be called on reflected objects representing final fields in a hidden class and its access check will be suppressed but only have read-access (i.e. can do Field::getXXX but not setXXX). > > Brief summary of this patch: > > 1. A new Lookup::defineHiddenClass method is the API to create a hidden class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG option that > can be specified when creating a hidden class. > 3. A new Class::isHiddenClass method tests if a class is a hidden class. > 4. Field::setXXX method will throw IAE on a final field of a hidden class > regardless of the value of the accessible flag. > 5. JVM_LookupDefineClass is the new JVM entry point for Lookup::defineClass > and defineHiddenClass to create a class from the given bytes. > 6. ClassLoaderData implementation is not changed. There is one primary CLD > that holds the classes strongly referenced by its defining loader. There > can be zero or more additional CLDs - one per weak class. > 7. Nest host determination is updated per revised JVMS 5.4.4. Access control > check no longer throws LinkageError but instead it will throw IAE with > a clear message if a class fails to resolve/validate the nest host declared > in NestHost/NestMembers attribute. > 8. JFR, jcmd, JDI are updated to support hidden classes. > 9. update javac LambdaToMethod as lambda proxy starts using nestmates > and generate a bridge method to desuger a method reference to a protected > method in its supertype in a different package > > This patch also updates StringConcatFactory, LambdaMetaFactory, and LambdaForms > to use hidden classes. The webrev includes changes in nashorn to hidden class > and I will update the webrev if JEP 372 removes it any time soon. > > We uncovered a bug in Lookup::defineClass spec throws LinkageError and intends > to have the newly created class linked. However, the implementation in 14 > does not link the class. A separate CSR [2] proposes to update the > implementation to match the spec. This patch fixes the implementation. > > The spec update on JVM TI, JDI and Instrumentation will be done as > a separate RFE [3]. This patch includes new tests for JVM TI and > java.instrument that validates how the existing APIs work for hidden classes. > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From andy.herrick at oracle.com Fri Mar 27 19:35:28 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 27 Mar 2020 15:35:28 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg Message-ID: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> Please review the fix to issue [1] at [2]. This change enables notarization on Mac for dmg images and app-image zip files. /Andy [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 [2]: http://cr.openjdk.java.net/~herrick/8237490 From mandy.chung at oracle.com Fri Mar 27 20:18:07 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 Mar 2020 13:18:07 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <72EC6AFD-412B-4238-B98E-90AF8C185D98@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <72EC6AFD-412B-4238-B98E-90AF8C185D98@oracle.com> Message-ID: On 3/27/20 11:59 AM, Paul Sandoz wrote: > Hi Mandy, > > Very thorough, bravo! Thanks. > Minor suggestions below. > > Paul. > > MethodHandleNatives.java > ? > > 142 > 143 /** > 144 * Flags for Lookup.ClassOptions > 145 */ > 146 static final int > 147 NESTMATE_CLASS = 0x00000001, > 148 HIDDEN_CLASS = 0x00000002, > 149 STRONG_LOADER_LINK = 0x00000004, > 150 ACCESS_VM_ANNOTATIONS = 0x00000008; > 151 } > > > Suggest you add a comment to keep the values in sync with the VM component. Already in the class spec of this Constants class.? The values of all constants defined in this Constants class are verified in sync with VM (see verifyConstants). > > MethodHandles.java > ? > > 1786 * (Given the {@code Lookup} object returned this method, its lookup class > 1787 * is a {@code Class} object for which {@link Class#getName()} returns a string > 1788 * that is not a binary name.) > > ? > (The {@code Lookup} object returned from this method has a lookup class that is > a {@code Class} object whose {@link Class#getName()} returns a string > that is not a binary name.) > ? > > > 1902 Set opts = options.length > 0 ? Set.of(options) : Set.of(); > > You can just do: > > Set opts = Set.of(options) > > And/or inline it into the subsequent method call. The implementation of Set.of checks the array length. Great to know.? Thanks. > > 2001 ClassDefiner makeHiddenClassDefiner(byte[] bytes, > > I think you can telescope the methods for non-name and name accepting since IIUC the name is derived from the byte[]. Thereby you can remove some code duplication. i.e. pull ClassDefiner.className out from ClassDefiner and place the logic in the factory methods. Alternative push the factory methods into ClassDefiner to keep all the logic together. > Ok.? I will move the className out. > > 3797 public enum ClassOption { > > Shuffle up to be closer to the defineHiddenClass Moved before defineHiddenClass. > > 3798 /** > 3799 * This class option specifies the hidden class be added to > 3800 * {@linkplain Class#getNestHost nest} of a lookup class as > 3801 * a nestmate. > > Suggest: > > "This class option specifies the hidden class ? -> ?Specifies that a hidden class > > 3812 * This class option specifies the hidden class to have a strong > > ?Specifies that a hidden class have a ?" Specifies that a hidden class has a... > > 3813 * relationship with the class loader marked as its defining loader, > 3814 * as a normal class or interface has with its own defining loader. > 3815 * This means that the hidden class may be unloaded if and only if > 3816 * its defining loader is not reachable and thus may be reclaimed > 3817 * by a garbage collector (JLS 12.7). > > > StringConcatFactory.java > ? > > 861 // use of @ForceInline no longer has any effect > > ? Right, I should have explained this [1]. This @ForceInline is used by BytecodeStringBuilderStrategy that generates code to have the same StringBuilder chain javac would emit. It uses `@ForceInline` annotation which may probably be for performance.? It's believed people rarely uses this non-default strategy.? This patch changes StringConcatFactory to the standard defineHiddenClass method and hence `@ForceInline` has no effect in the generated class for this non-default strategy.? If it turns out to be an issue, then we will determine if it should enable the access to VM annotations (I doubt this is supported strategy). [1] https://bugs.openjdk.java.net/browse/JDK-8241548 From erik.joelsson at oracle.com Fri Mar 27 20:21:43 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 27 Mar 2020 13:21:43 -0700 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> Message-ID: I think the proposed signing mechanism makes sense based on my experience signing and notarizing the JDK itself. /Erik On 2020-03-27 12:35, Andy Herrick wrote: > Please review the fix to issue [1] at [2]. > > This change enables notarization on Mac for dmg images and app-image > zip files. > > /Andy > > [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 > > [2]: http://cr.openjdk.java.net/~herrick/8237490 > From vicente.romero at oracle.com Fri Mar 27 21:15:29 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 27 Mar 2020 17:15:29 -0400 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com> Message-ID: Hi Mandy, The patch for nestmates [1] could be used as a reference. There a new method was added to class `com.sun.tools.javac.jvm.Target`, named: `hasNestmateAccess` which checks if a target is ready for nestmates or not. I think that you can follow a similar approach here. Thanks, Vicente [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7 On 3/27/20 12:29 PM, Mandy Chung wrote: > Hi Jan, > > Good point.? The javac change only applies to JDK 15 and later and the > lambda proxy class is not a nestmate when running on JDK 14 or earlier. > > I probably need the help from langtools team to fix this.? I'll give > it a try. > > Mandy > > On 3/27/20 4:31 AM, Jan Lahoda wrote: >> Hi Mandy, >> >> Regarding the javac changes - should those be switched on/off >> depending the Target? Or, if one compiles with e.g. --release 14, >> will the newly generated output still work on JDK 14? >> >> Jan >> >> On 27. 03. 20 0:57, Mandy Chung wrote: >>> Please review the implementation of JEP 371: Hidden Classes. The >>> main changes are in core-libs and hotspot runtime area.? Small >>> changes are made in javac, VM compiler (intrinsification of >>> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed >>> and is in the finalized state (see specdiff and javadoc below for >>> reference). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >>> >>> >>> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >>> point >>> of view, a hidden class is a normal class except the following: >>> >>> - A hidden class has no initiating class loader and is not >>> registered in any dictionary. >>> - A hidden class has a name containing an illegal character >>> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >>> returns "Lp/Foo.0x1234;". >>> - A hidden class is not modifiable, i.e. cannot be redefined or >>> retransformed. JVM TI IsModifableClass returns false on a hidden. >>> - Final fields in a hidden class is "final".? The value of final >>> fields cannot be overriden via reflection. setAccessible(true) can >>> still be called on reflected objects representing final fields in a >>> hidden class and its access check will be suppressed but only have >>> read-access (i.e. can do Field::getXXX but not setXXX). >>> >>> Brief summary of this patch: >>> >>> 1. A new Lookup::defineHiddenClass method is the API to create a >>> hidden class. >>> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >>> option that >>> ??? can be specified when creating a hidden class. >>> 3. A new Class::isHiddenClass method tests if a class is a hidden >>> class. >>> 4. Field::setXXX method will throw IAE on a final field of a hidden >>> class >>> ??? regardless of the value of the accessible flag. >>> 5. JVM_LookupDefineClass is the new JVM entry point for >>> Lookup::defineClass >>> ??? and defineHiddenClass to create a class from the given bytes. >>> 6. ClassLoaderData implementation is not changed.? There is one >>> primary CLD >>> ??? that holds the classes strongly referenced by its defining >>> loader. There >>> ??? can be zero or more additional CLDs - one per weak class. >>> 7. Nest host determination is updated per revised JVMS 5.4.4. Access >>> control >>> ??? check no longer throws LinkageError but instead it will throw >>> IAE with >>> ??? a clear message if a class fails to resolve/validate the nest >>> host declared >>> ??? in NestHost/NestMembers attribute. >>> 8. JFR, jcmd, JDI are updated to support hidden classes. >>> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >>> ??? and generate a bridge method to desuger a method reference to a >>> protected >>> ??? method in its supertype in a different package >>> >>> This patch also updates StringConcatFactory, LambdaMetaFactory, and >>> LambdaForms >>> to use hidden classes.? The webrev includes changes in nashorn to >>> hidden class >>> and I will update the webrev if JEP 372 removes it any time soon. >>> >>> We uncovered a bug in Lookup::defineClass spec throws LinkageError >>> and intends >>> to have the newly created class linked.? However, the implementation >>> in 14 >>> does not link the class.? A separate CSR [2] proposes to update the >>> implementation to match the spec.? This patch fixes the implementation. >>> >>> The spec update on JVM TI, JDI and Instrumentation will be done as >>> a separate RFE [3].? This patch includes new tests for JVM TI and >>> java.instrument that validates how the existing APIs work for hidden >>> classes. >>> >>> javadoc/specdiff >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >>> >>> >>> JVMS 5.4.4 change: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >>> >>> >>> CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8238359 >>> >>> Thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > From alexander.matveev at oracle.com Fri Mar 27 21:18:59 2020 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 27 Mar 2020 14:18:59 -0700 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> Message-ID: <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> Hi Andy, http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html Line 819,857,902 - Looks like temp debug log message. Remove it or align with rest of code. http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html Line 70 - Capital F. Since we added "--timestamp" and? "--options runtime" to codesign, will it work with older Xcode and macOS we planning to support? Do we need any adjustments to signing tests we have? Otherwise looks fine. Thanks, Alexander On 3/27/20 12:35 PM, Andy Herrick wrote: > Please review the fix to issue [1] at [2]. > > This change enables notarization on Mac for dmg images and app-image > zip files. > > /Andy > > [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 > > [2]: http://cr.openjdk.java.net/~herrick/8237490 > From mandy.chung at oracle.com Fri Mar 27 22:22:19 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 Mar 2020 15:22:19 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <72EC6AFD-412B-4238-B98E-90AF8C185D98@oracle.com> Message-ID: <41b99011-921a-9fc6-c738-98c47e9959c3@oracle.com> Hi Paul, This is the delta incorporating your comment: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-psandoz/ This patch also took Alex's comment to make it clear that the hidden class is the lookup class of the returned Lookup object and drops the sentence you commented on: On 3/27/20 1:18 PM, Mandy Chung wrote: >> MethodHandles.java >> ? >> >> 1786????????? * (Given the {@code Lookup} object returned this >> method, its lookup class >> 1787????????? * is a {@code Class} object for which {@link >> Class#getName()} returns a string >> 1788????????? * that is not a binary name.) >> >> ? >> (The {@code Lookup} object returned from this method has a lookup >> class that is >> a {@code Class} object whose {@link Class#getName()} returns a string >> that is not a binary name.) >> ? Mandy From mandy.chung at oracle.com Fri Mar 27 22:29:03 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 Mar 2020 15:29:03 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com> Message-ID: Hi Vicente, hasNestmateAccess is about VM supports static nestmates on JDK release >= 11. However this is about javac --release 14 and the compiled classes may run on JDK 14 that lambda and string concat spin classes that are not nestmates. I have a patch with Jan's help: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html (you can apply the above patch on valhalla repo "nestmates" branch) About testing, I wanted to run BridgeMethodsForLambdaTest and TestLambdaBytecode test with --release 14 but it turns out not straight-forward.? Any help would be appreciated. thanks Mandy On 3/27/20 2:15 PM, Vicente Romero wrote: > Hi Mandy, > > The patch for nestmates [1] could be used as a reference. There a new > method was added to class `com.sun.tools.javac.jvm.Target`, named: > `hasNestmateAccess` which checks if a target is ready for nestmates or > not. I think that you can follow a similar approach here. > > Thanks, > Vicente > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7 > > On 3/27/20 12:29 PM, Mandy Chung wrote: >> Hi Jan, >> >> Good point.? The javac change only applies to JDK 15 and later and >> the lambda proxy class is not a nestmate when running on JDK 14 or >> earlier. >> >> I probably need the help from langtools team to fix this.? I'll give >> it a try. >> >> Mandy >> >> On 3/27/20 4:31 AM, Jan Lahoda wrote: >>> Hi Mandy, >>> >>> Regarding the javac changes - should those be switched on/off >>> depending the Target? Or, if one compiles with e.g. --release 14, >>> will the newly generated output still work on JDK 14? >>> >>> Jan >>> >>> On 27. 03. 20 0:57, Mandy Chung wrote: >>>> Please review the implementation of JEP 371: Hidden Classes. The >>>> main changes are in core-libs and hotspot runtime area.? Small >>>> changes are made in javac, VM compiler (intrinsification of >>>> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been >>>> reviewed and is in the finalized state (see specdiff and javadoc >>>> below for reference). >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >>>> >>>> >>>> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >>>> point >>>> of view, a hidden class is a normal class except the following: >>>> >>>> - A hidden class has no initiating class loader and is not >>>> registered in any dictionary. >>>> - A hidden class has a name containing an illegal character >>>> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >>>> returns "Lp/Foo.0x1234;". >>>> - A hidden class is not modifiable, i.e. cannot be redefined or >>>> retransformed. JVM TI IsModifableClass returns false on a hidden. >>>> - Final fields in a hidden class is "final".? The value of final >>>> fields cannot be overriden via reflection. setAccessible(true) can >>>> still be called on reflected objects representing final fields in a >>>> hidden class and its access check will be suppressed but only have >>>> read-access (i.e. can do Field::getXXX but not setXXX). >>>> >>>> Brief summary of this patch: >>>> >>>> 1. A new Lookup::defineHiddenClass method is the API to create a >>>> hidden class. >>>> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >>>> option that >>>> ??? can be specified when creating a hidden class. >>>> 3. A new Class::isHiddenClass method tests if a class is a hidden >>>> class. >>>> 4. Field::setXXX method will throw IAE on a final field of a hidden >>>> class >>>> ??? regardless of the value of the accessible flag. >>>> 5. JVM_LookupDefineClass is the new JVM entry point for >>>> Lookup::defineClass >>>> ??? and defineHiddenClass to create a class from the given bytes. >>>> 6. ClassLoaderData implementation is not changed.? There is one >>>> primary CLD >>>> ??? that holds the classes strongly referenced by its defining >>>> loader. There >>>> ??? can be zero or more additional CLDs - one per weak class. >>>> 7. Nest host determination is updated per revised JVMS 5.4.4. >>>> Access control >>>> ??? check no longer throws LinkageError but instead it will throw >>>> IAE with >>>> ??? a clear message if a class fails to resolve/validate the nest >>>> host declared >>>> ??? in NestHost/NestMembers attribute. >>>> 8. JFR, jcmd, JDI are updated to support hidden classes. >>>> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >>>> ??? and generate a bridge method to desuger a method reference to a >>>> protected >>>> ??? method in its supertype in a different package >>>> >>>> This patch also updates StringConcatFactory, LambdaMetaFactory, and >>>> LambdaForms >>>> to use hidden classes.? The webrev includes changes in nashorn to >>>> hidden class >>>> and I will update the webrev if JEP 372 removes it any time soon. >>>> >>>> We uncovered a bug in Lookup::defineClass spec throws LinkageError >>>> and intends >>>> to have the newly created class linked.? However, the >>>> implementation in 14 >>>> does not link the class.? A separate CSR [2] proposes to update the >>>> implementation to match the spec.? This patch fixes the >>>> implementation. >>>> >>>> The spec update on JVM TI, JDI and Instrumentation will be done as >>>> a separate RFE [3].? This patch includes new tests for JVM TI and >>>> java.instrument that validates how the existing APIs work for >>>> hidden classes. >>>> >>>> javadoc/specdiff >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >>>> >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >>>> >>>> >>>> JVMS 5.4.4 change: >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >>>> >>>> >>>> CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8238359 >>>> >>>> Thanks >>>> Mandy >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 >> > From vicente.romero at oracle.com Fri Mar 27 22:48:52 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 27 Mar 2020 18:48:52 -0400 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com> Message-ID: <60348819-ace5-8e52-f1ff-5f9654c915e0@oracle.com> Hi Mandy, On 3/27/20 6:29 PM, Mandy Chung wrote: > Hi Vicente, > > hasNestmateAccess is about VM supports static nestmates on JDK release > >= 11. I was not suggesting the use of `hasNestmateAccess` but to follow the same approach which is adding a new method at class `Target` to check if the new goodies were in the given target > > However this is about javac --release 14 and the compiled classes may > run on JDK 14 that lambda and string concat spin classes that are not > nestmates. I have a patch with Jan's help: > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html which is what the patch above is doing > > (you can apply the above patch on valhalla repo "nestmates" branch) > > About testing, I wanted to run BridgeMethodsForLambdaTest and > TestLambdaBytecode test with --release 14 but it turns out not > straight-forward.? Any help would be appreciated. > > thanks > Mandy Vicente > > On 3/27/20 2:15 PM, Vicente Romero wrote: >> Hi Mandy, >> >> The patch for nestmates [1] could be used as a reference. There a new >> method was added to class `com.sun.tools.javac.jvm.Target`, named: >> `hasNestmateAccess` which checks if a target is ready for nestmates >> or not. I think that you can follow a similar approach here. >> >> Thanks, >> Vicente >> >> [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7 >> >> On 3/27/20 12:29 PM, Mandy Chung wrote: >>> Hi Jan, >>> >>> Good point.? The javac change only applies to JDK 15 and later and >>> the lambda proxy class is not a nestmate when running on JDK 14 or >>> earlier. >>> >>> I probably need the help from langtools team to fix this. I'll give >>> it a try. >>> >>> Mandy >>> >>> On 3/27/20 4:31 AM, Jan Lahoda wrote: >>>> Hi Mandy, >>>> >>>> Regarding the javac changes - should those be switched on/off >>>> depending the Target? Or, if one compiles with e.g. --release 14, >>>> will the newly generated output still work on JDK 14? >>>> >>>> Jan >>>> >>>> On 27. 03. 20 0:57, Mandy Chung wrote: >>>>> Please review the implementation of JEP 371: Hidden Classes. The >>>>> main changes are in core-libs and hotspot runtime area.? Small >>>>> changes are made in javac, VM compiler (intrinsification of >>>>> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been >>>>> reviewed and is in the finalized state (see specdiff and javadoc >>>>> below for reference). >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >>>>> >>>>> >>>>> Hidden class is created via `Lookup::defineHiddenClass`. From >>>>> JVM's point >>>>> of view, a hidden class is a normal class except the following: >>>>> >>>>> - A hidden class has no initiating class loader and is not >>>>> registered in any dictionary. >>>>> - A hidden class has a name containing an illegal character >>>>> `Class::getName` returns `p.Foo/0x1234` whereas >>>>> `GetClassSignature` returns "Lp/Foo.0x1234;". >>>>> - A hidden class is not modifiable, i.e. cannot be redefined or >>>>> retransformed. JVM TI IsModifableClass returns false on a hidden. >>>>> - Final fields in a hidden class is "final".? The value of final >>>>> fields cannot be overriden via reflection. setAccessible(true) can >>>>> still be called on reflected objects representing final fields in >>>>> a hidden class and its access check will be suppressed but only >>>>> have read-access (i.e. can do Field::getXXX but not setXXX). >>>>> >>>>> Brief summary of this patch: >>>>> >>>>> 1. A new Lookup::defineHiddenClass method is the API to create a >>>>> hidden class. >>>>> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >>>>> option that >>>>> ??? can be specified when creating a hidden class. >>>>> 3. A new Class::isHiddenClass method tests if a class is a hidden >>>>> class. >>>>> 4. Field::setXXX method will throw IAE on a final field of a >>>>> hidden class >>>>> ??? regardless of the value of the accessible flag. >>>>> 5. JVM_LookupDefineClass is the new JVM entry point for >>>>> Lookup::defineClass >>>>> ??? and defineHiddenClass to create a class from the given bytes. >>>>> 6. ClassLoaderData implementation is not changed.? There is one >>>>> primary CLD >>>>> ??? that holds the classes strongly referenced by its defining >>>>> loader. There >>>>> ??? can be zero or more additional CLDs - one per weak class. >>>>> 7. Nest host determination is updated per revised JVMS 5.4.4. >>>>> Access control >>>>> ??? check no longer throws LinkageError but instead it will throw >>>>> IAE with >>>>> ??? a clear message if a class fails to resolve/validate the nest >>>>> host declared >>>>> ??? in NestHost/NestMembers attribute. >>>>> 8. JFR, jcmd, JDI are updated to support hidden classes. >>>>> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >>>>> ??? and generate a bridge method to desuger a method reference to >>>>> a protected >>>>> ??? method in its supertype in a different package >>>>> >>>>> This patch also updates StringConcatFactory, LambdaMetaFactory, >>>>> and LambdaForms >>>>> to use hidden classes.? The webrev includes changes in nashorn to >>>>> hidden class >>>>> and I will update the webrev if JEP 372 removes it any time soon. >>>>> >>>>> We uncovered a bug in Lookup::defineClass spec throws LinkageError >>>>> and intends >>>>> to have the newly created class linked.? However, the >>>>> implementation in 14 >>>>> does not link the class.? A separate CSR [2] proposes to update the >>>>> implementation to match the spec.? This patch fixes the >>>>> implementation. >>>>> >>>>> The spec update on JVM TI, JDI and Instrumentation will be done as >>>>> a separate RFE [3].? This patch includes new tests for JVM TI and >>>>> java.instrument that validates how the existing APIs work for >>>>> hidden classes. >>>>> >>>>> javadoc/specdiff >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >>>>> >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >>>>> >>>>> >>>>> JVMS 5.4.4 change: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >>>>> >>>>> >>>>> CSR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8238359 >>>>> >>>>> Thanks >>>>> Mandy >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 >>> >> > From alexey.semenyuk at oracle.com Fri Mar 27 22:57:38 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 27 Mar 2020 18:57:38 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> Message-ID: Agree with Alexander's findings. The rest looks good. - Alexey On 3/27/2020 5:18 PM, Alexander Matveev wrote: > Hi Andy, > > http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html > > Line 819,857,902 - Looks like temp debug log message. Remove it or > align with rest of code. > > http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html > > Line 70 - Capital F. > > Since we added "--timestamp" and? "--options runtime" to codesign, > will it work with older Xcode and macOS we planning to support? > > Do we need any adjustments to signing tests we have? > > Otherwise looks fine. > > Thanks, > Alexander > > On 3/27/20 12:35 PM, Andy Herrick wrote: >> Please review the fix to issue [1] at [2]. >> >> This change enables notarization on Mac for dmg images and app-image >> zip files. >> >> /Andy >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >> >> [2]: http://cr.openjdk.java.net/~herrick/8237490 >> > From david.holmes at oracle.com Fri Mar 27 23:01:58 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 28 Mar 2020 09:01:58 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com> Message-ID: <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com> Hi Mandy, On 28/03/2020 8:29 am, Mandy Chung wrote: > Hi Vicente, > > hasNestmateAccess is about VM supports static nestmates on JDK release > >= 11. > > However this is about javac --release 14 and the compiled classes may > run on JDK 14 that lambda and string concat spin classes that are not > nestmates. I have a patch with Jan's help: > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html + /** + * The VM does not support access across nested classes (8010319). + * Were that ever to change, this should be removed. + */ + boolean isPrivateInOtherClass() { I'm not at all sure what this means - access across different nests? (I'm not even sure what that means.) Thanks, David ----- > > (you can apply the above patch on valhalla repo "nestmates" branch) > > About testing, I wanted to run BridgeMethodsForLambdaTest and > TestLambdaBytecode test with --release 14 but it turns out not > straight-forward.? Any help would be appreciated. > > thanks > Mandy > > On 3/27/20 2:15 PM, Vicente Romero wrote: >> Hi Mandy, >> >> The patch for nestmates [1] could be used as a reference. There a new >> method was added to class `com.sun.tools.javac.jvm.Target`, named: >> `hasNestmateAccess` which checks if a target is ready for nestmates or >> not. I think that you can follow a similar approach here. >> >> Thanks, >> Vicente >> >> [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7 >> >> On 3/27/20 12:29 PM, Mandy Chung wrote: >>> Hi Jan, >>> >>> Good point.? The javac change only applies to JDK 15 and later and >>> the lambda proxy class is not a nestmate when running on JDK 14 or >>> earlier. >>> >>> I probably need the help from langtools team to fix this.? I'll give >>> it a try. >>> >>> Mandy >>> >>> On 3/27/20 4:31 AM, Jan Lahoda wrote: >>>> Hi Mandy, >>>> >>>> Regarding the javac changes - should those be switched on/off >>>> depending the Target? Or, if one compiles with e.g. --release 14, >>>> will the newly generated output still work on JDK 14? >>>> >>>> Jan >>>> >>>> On 27. 03. 20 0:57, Mandy Chung wrote: >>>>> Please review the implementation of JEP 371: Hidden Classes. The >>>>> main changes are in core-libs and hotspot runtime area.? Small >>>>> changes are made in javac, VM compiler (intrinsification of >>>>> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been >>>>> reviewed and is in the finalized state (see specdiff and javadoc >>>>> below for reference). >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >>>>> >>>>> >>>>> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >>>>> point >>>>> of view, a hidden class is a normal class except the following: >>>>> >>>>> - A hidden class has no initiating class loader and is not >>>>> registered in any dictionary. >>>>> - A hidden class has a name containing an illegal character >>>>> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >>>>> returns "Lp/Foo.0x1234;". >>>>> - A hidden class is not modifiable, i.e. cannot be redefined or >>>>> retransformed. JVM TI IsModifableClass returns false on a hidden. >>>>> - Final fields in a hidden class is "final".? The value of final >>>>> fields cannot be overriden via reflection. setAccessible(true) can >>>>> still be called on reflected objects representing final fields in a >>>>> hidden class and its access check will be suppressed but only have >>>>> read-access (i.e. can do Field::getXXX but not setXXX). >>>>> >>>>> Brief summary of this patch: >>>>> >>>>> 1. A new Lookup::defineHiddenClass method is the API to create a >>>>> hidden class. >>>>> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >>>>> option that >>>>> ??? can be specified when creating a hidden class. >>>>> 3. A new Class::isHiddenClass method tests if a class is a hidden >>>>> class. >>>>> 4. Field::setXXX method will throw IAE on a final field of a hidden >>>>> class >>>>> ??? regardless of the value of the accessible flag. >>>>> 5. JVM_LookupDefineClass is the new JVM entry point for >>>>> Lookup::defineClass >>>>> ??? and defineHiddenClass to create a class from the given bytes. >>>>> 6. ClassLoaderData implementation is not changed.? There is one >>>>> primary CLD >>>>> ??? that holds the classes strongly referenced by its defining >>>>> loader. There >>>>> ??? can be zero or more additional CLDs - one per weak class. >>>>> 7. Nest host determination is updated per revised JVMS 5.4.4. >>>>> Access control >>>>> ??? check no longer throws LinkageError but instead it will throw >>>>> IAE with >>>>> ??? a clear message if a class fails to resolve/validate the nest >>>>> host declared >>>>> ??? in NestHost/NestMembers attribute. >>>>> 8. JFR, jcmd, JDI are updated to support hidden classes. >>>>> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >>>>> ??? and generate a bridge method to desuger a method reference to a >>>>> protected >>>>> ??? method in its supertype in a different package >>>>> >>>>> This patch also updates StringConcatFactory, LambdaMetaFactory, and >>>>> LambdaForms >>>>> to use hidden classes.? The webrev includes changes in nashorn to >>>>> hidden class >>>>> and I will update the webrev if JEP 372 removes it any time soon. >>>>> >>>>> We uncovered a bug in Lookup::defineClass spec throws LinkageError >>>>> and intends >>>>> to have the newly created class linked.? However, the >>>>> implementation in 14 >>>>> does not link the class.? A separate CSR [2] proposes to update the >>>>> implementation to match the spec.? This patch fixes the >>>>> implementation. >>>>> >>>>> The spec update on JVM TI, JDI and Instrumentation will be done as >>>>> a separate RFE [3].? This patch includes new tests for JVM TI and >>>>> java.instrument that validates how the existing APIs work for >>>>> hidden classes. >>>>> >>>>> javadoc/specdiff >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >>>>> >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >>>>> >>>>> >>>>> JVMS 5.4.4 change: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >>>>> >>>>> >>>>> CSR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8238359 >>>>> >>>>> Thanks >>>>> Mandy >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 >>> >> > From forax at univ-mlv.fr Fri Mar 27 23:40:59 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 28 Mar 2020 00:40:59 +0100 (CET) Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com> <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com> Message-ID: <405050984.1553152.1585352459094.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "David Holmes" > ?: "mandy chung" , "Vicente Romero" , "jan lahoda" > > Cc: "serviceability-dev" , "hotspot-dev" , > "core-libs-dev" , "valhalla-dev" > Envoy?: Samedi 28 Mars 2020 00:01:58 > Objet: Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes > Hi Mandy, Hi David, > > On 28/03/2020 8:29 am, Mandy Chung wrote: >> Hi Vicente, >> >> hasNestmateAccess is about VM supports static nestmates on JDK release >> >= 11. >> >> However this is about javac --release 14 and the compiled classes may >> run on JDK 14 that lambda and string concat spin classes that are not >> nestmates. I have a patch with Jan's help: >> >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html > > + /** > + * The VM does not support access across nested classes > (8010319). > + * Were that ever to change, this should be removed. > + */ > + boolean isPrivateInOtherClass() { > > I'm not at all sure what this means - access across different nests? > (I'm not even sure what that means.) Access inside the same nest. As you know, until now, a lambda proxy is a VM anonymous class that can only see the private fields of the class declaring the lambda (the host class) and not the private fields of a class of the nest (the enclosing classes in term of Java the language). R?mi > > Thanks, > David > ----- > >> >> (you can apply the above patch on valhalla repo "nestmates" branch) >> >> About testing, I wanted to run BridgeMethodsForLambdaTest and >> TestLambdaBytecode test with --release 14 but it turns out not >> straight-forward.? Any help would be appreciated. >> >> thanks >> Mandy >> >> On 3/27/20 2:15 PM, Vicente Romero wrote: >>> Hi Mandy, >>> >>> The patch for nestmates [1] could be used as a reference. There a new >>> method was added to class `com.sun.tools.javac.jvm.Target`, named: >>> `hasNestmateAccess` which checks if a target is ready for nestmates or >>> not. I think that you can follow a similar approach here. >>> >>> Thanks, >>> Vicente >>> >>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7 >>> >>> On 3/27/20 12:29 PM, Mandy Chung wrote: >>>> Hi Jan, >>>> >>>> Good point.? The javac change only applies to JDK 15 and later and >>>> the lambda proxy class is not a nestmate when running on JDK 14 or >>>> earlier. >>>> >>>> I probably need the help from langtools team to fix this.? I'll give >>>> it a try. >>>> >>>> Mandy >>>> >>>> On 3/27/20 4:31 AM, Jan Lahoda wrote: >>>>> Hi Mandy, >>>>> >>>>> Regarding the javac changes - should those be switched on/off >>>>> depending the Target? Or, if one compiles with e.g. --release 14, >>>>> will the newly generated output still work on JDK 14? >>>>> >>>>> Jan >>>>> >>>>> On 27. 03. 20 0:57, Mandy Chung wrote: >>>>>> Please review the implementation of JEP 371: Hidden Classes. The >>>>>> main changes are in core-libs and hotspot runtime area.? Small >>>>>> changes are made in javac, VM compiler (intrinsification of >>>>>> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been >>>>>> reviewed and is in the finalized state (see specdiff and javadoc >>>>>> below for reference). >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >>>>>> >>>>>> >>>>>> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >>>>>> point >>>>>> of view, a hidden class is a normal class except the following: >>>>>> >>>>>> - A hidden class has no initiating class loader and is not >>>>>> registered in any dictionary. >>>>>> - A hidden class has a name containing an illegal character >>>>>> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >>>>>> returns "Lp/Foo.0x1234;". >>>>>> - A hidden class is not modifiable, i.e. cannot be redefined or >>>>>> retransformed. JVM TI IsModifableClass returns false on a hidden. >>>>>> - Final fields in a hidden class is "final".? The value of final >>>>>> fields cannot be overriden via reflection. setAccessible(true) can >>>>>> still be called on reflected objects representing final fields in a >>>>>> hidden class and its access check will be suppressed but only have >>>>>> read-access (i.e. can do Field::getXXX but not setXXX). >>>>>> >>>>>> Brief summary of this patch: >>>>>> >>>>>> 1. A new Lookup::defineHiddenClass method is the API to create a >>>>>> hidden class. >>>>>> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >>>>>> option that >>>>>> ??? can be specified when creating a hidden class. >>>>>> 3. A new Class::isHiddenClass method tests if a class is a hidden >>>>>> class. >>>>>> 4. Field::setXXX method will throw IAE on a final field of a hidden >>>>>> class >>>>>> ??? regardless of the value of the accessible flag. >>>>>> 5. JVM_LookupDefineClass is the new JVM entry point for >>>>>> Lookup::defineClass >>>>>> ??? and defineHiddenClass to create a class from the given bytes. >>>>>> 6. ClassLoaderData implementation is not changed.? There is one >>>>>> primary CLD >>>>>> ??? that holds the classes strongly referenced by its defining >>>>>> loader. There >>>>>> ??? can be zero or more additional CLDs - one per weak class. >>>>>> 7. Nest host determination is updated per revised JVMS 5.4.4. >>>>>> Access control >>>>>> ??? check no longer throws LinkageError but instead it will throw >>>>>> IAE with >>>>>> ??? a clear message if a class fails to resolve/validate the nest >>>>>> host declared >>>>>> ??? in NestHost/NestMembers attribute. >>>>>> 8. JFR, jcmd, JDI are updated to support hidden classes. >>>>>> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >>>>>> ??? and generate a bridge method to desuger a method reference to a >>>>>> protected >>>>>> ??? method in its supertype in a different package >>>>>> >>>>>> This patch also updates StringConcatFactory, LambdaMetaFactory, and >>>>>> LambdaForms >>>>>> to use hidden classes.? The webrev includes changes in nashorn to >>>>>> hidden class >>>>>> and I will update the webrev if JEP 372 removes it any time soon. >>>>>> >>>>>> We uncovered a bug in Lookup::defineClass spec throws LinkageError >>>>>> and intends >>>>>> to have the newly created class linked.? However, the >>>>>> implementation in 14 >>>>>> does not link the class.? A separate CSR [2] proposes to update the >>>>>> implementation to match the spec.? This patch fixes the >>>>>> implementation. >>>>>> >>>>>> The spec update on JVM TI, JDI and Instrumentation will be done as >>>>>> a separate RFE [3].? This patch includes new tests for JVM TI and >>>>>> java.instrument that validates how the existing APIs work for >>>>>> hidden classes. >>>>>> >>>>>> javadoc/specdiff >>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >>>>>> >>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >>>>>> >>>>>> >>>>>> JVMS 5.4.4 change: >>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >>>>>> >>>>>> >>>>>> CSR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8238359 >>>>>> >>>>>> Thanks >>>>>> Mandy >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 >>>> >>> From mandy.chung at oracle.com Fri Mar 27 23:46:00 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 Mar 2020 16:46:00 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com> <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com> Message-ID: <09126b64-2aa5-9b0d-ec5a-62753a416ea9@oracle.com> On 3/27/20 4:01 PM, David Holmes wrote: > Hi Mandy, > > On 28/03/2020 8:29 am, Mandy Chung wrote: >> Hi Vicente, >> >> hasNestmateAccess is about VM supports static nestmates on JDK >> release ?>= 11. >> >> However this is about javac --release 14 and the compiled classes may >> run on JDK 14 that lambda and string concat spin classes that are not >> nestmates. I have a patch with Jan's help: >> >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html > > > +???????????? /** > +????????????? * The VM does not support access across nested classes > (8010319). > +????????????? * Were that ever to change, this should be removed. > +????????????? */ > +???????????? boolean isPrivateInOtherClass() { > > I'm not at all sure what this means - access across different nests? > (I'm not even sure what that means.) This just reverts? the old code that I removed. What this method is trying to determine if it accesses a private in another class in the same nest (nested classes) that needs a synthetic bridge method to access. Mandy From david.holmes at oracle.com Sat Mar 28 01:15:43 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 28 Mar 2020 11:15:43 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <09126b64-2aa5-9b0d-ec5a-62753a416ea9@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com> <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com> <09126b64-2aa5-9b0d-ec5a-62753a416ea9@oracle.com> Message-ID: <069c76b6-dd85-f8f5-c2dd-1ba994178084@oracle.com> Hi Mandy, On 28/03/2020 9:46 am, Mandy Chung wrote: > > > On 3/27/20 4:01 PM, David Holmes wrote: >> Hi Mandy, >> >> On 28/03/2020 8:29 am, Mandy Chung wrote: >>> Hi Vicente, >>> >>> hasNestmateAccess is about VM supports static nestmates on JDK >>> release ?>= 11. >>> >>> However this is about javac --release 14 and the compiled classes may >>> run on JDK 14 that lambda and string concat spin classes that are not >>> nestmates. I have a patch with Jan's help: >>> >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html >> >> >> +???????????? /** >> +????????????? * The VM does not support access across nested classes >> (8010319). >> +????????????? * Were that ever to change, this should be removed. >> +????????????? */ >> +???????????? boolean isPrivateInOtherClass() { >> >> I'm not at all sure what this means - access across different nests? >> (I'm not even sure what that means.) > > This just reverts? the old code that I removed. Ah I see. This is ancient pre-nestmate code. Can we at least fix the comment as it really doesn't make any sense > What this method is trying to determine if it accesses a private in > another class in the same nest (nested classes) that needs a synthetic > bridge method to access. That would be a good comment to add. Something like: If compiling for a release where the VM does not support access between nested classes, this method indicates if a synthetic bridge method is needed for access. Thanks, David > Mandy From paul.sandoz at oracle.com Sat Mar 28 01:39:46 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 27 Mar 2020 18:39:46 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <41b99011-921a-9fc6-c738-98c47e9959c3@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <72EC6AFD-412B-4238-B98E-90AF8C185D98@oracle.com> <41b99011-921a-9fc6-c738-98c47e9959c3@oracle.com> Message-ID: <2667FFDE-44A9-4584-BF16-897B863D89F3@oracle.com> +1 Paul. > On Mar 27, 2020, at 3:22 PM, Mandy Chung wrote: > > Hi Paul, > > This is the delta incorporating your comment: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-psandoz/ > > This patch also took Alex's comment to make it clear that the hidden class is the lookup class of the returned Lookup object and drops the sentence you commented on: > > On 3/27/20 1:18 PM, Mandy Chung wrote: >>> MethodHandles.java >>> ? >>> >>> 1786 * (Given the {@code Lookup} object returned this method, its lookup class >>> 1787 * is a {@code Class} object for which {@link Class#getName()} returns a string >>> 1788 * that is not a binary name.) >>> >>> ? >>> (The {@code Lookup} object returned from this method has a lookup class that is >>> a {@code Class} object whose {@link Class#getName()} returns a string >>> that is not a binary name.) >>> ? > > > Mandy From dean.long at oracle.com Sat Mar 28 02:25:36 2020 From: dean.long at oracle.com (Dean Long) Date: Fri, 27 Mar 2020 19:25:36 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <13d7ba73-e49f-a55d-7e80-bd10153152a4@oracle.com> I looked at the AOT, C2, and JVMCI changes and I didn't find any issues. dl On 3/26/20 4:57 PM, Mandy Chung wrote: > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area. Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point > of view, a hidden class is a normal class except the following: > > - A hidden class has no initiating class loader and is not registered > in any dictionary. > - A hidden class has a name containing an illegal character > `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` > returns "Lp/Foo.0x1234;". > - A hidden class is not modifiable, i.e. cannot be redefined or > retransformed. JVM TI IsModifableClass returns false on a hidden. > - Final fields in a hidden class is "final".? The value of final > fields cannot be overriden via reflection.? setAccessible(true) can > still be called on reflected objects representing final fields in a > hidden class and its access check will be suppressed but only have > read-access (i.e. can do Field::getXXX but not setXXX). > > Brief summary of this patch: > > 1. A new Lookup::defineHiddenClass method is the API to create a > hidden class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG > option that > ?? can be specified when creating a hidden class. > 3. A new Class::isHiddenClass method tests if a class is a hidden class. > 4. Field::setXXX method will throw IAE on a final field of a hidden class > ?? regardless of the value of the accessible flag. > 5. JVM_LookupDefineClass is the new JVM entry point for > Lookup::defineClass > ?? and defineHiddenClass to create a class from the given bytes. > 6. ClassLoaderData implementation is not changed.? There is one > primary CLD > ?? that holds the classes strongly referenced by its defining loader.? > There > ?? can be zero or more additional CLDs - one per weak class. > 7. Nest host determination is updated per revised JVMS 5.4.4. Access > control > ?? check no longer throws LinkageError but instead it will throw IAE with > ?? a clear message if a class fails to resolve/validate the nest host > declared > ?? in NestHost/NestMembers attribute. > 8. JFR, jcmd, JDI are updated to support hidden classes. > 9. update javac LambdaToMethod as lambda proxy starts using nestmates > ?? and generate a bridge method to desuger a method reference to a > protected > ?? method in its supertype in a different package > > This patch also updates StringConcatFactory, LambdaMetaFactory, and > LambdaForms > to use hidden classes.? The webrev includes changes in nashorn to > hidden class > and I will update the webrev if JEP 372 removes it any time soon. > > We uncovered a bug in Lookup::defineClass spec throws LinkageError and > intends > to have the newly created class linked.? However, the implementation in 14 > does not link the class.? A separate CSR [2] proposes to update the > implementation to match the spec.? This patch fixes the implementation. > > The spec update on JVM TI, JDI and Instrumentation will be done as > a separate RFE [3].? This patch includes new tests for JVM TI and > java.instrument that validates how the existing APIs work for hidden > classes. > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From chris.plummer at oracle.com Sat Mar 28 03:51:37 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 27 Mar 2020 20:51:37 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <90f9276d-2777-88ba-b1ec-9901711fcf02@oracle.com> Hi Mandy, A couple of very minor nits in the jvmtiRedefineClasses.cpp comments: ?153???? // classes for primitives, arrays, hidden and vm unsafe anonymous classes ?154???? // cannot be redefined.? Check here so following code can assume these classes ?155???? // are InstanceKlass. ?156???? if (!is_modifiable_class(mirror)) { ?157?????? _res = JVMTI_ERROR_UNMODIFIABLE_CLASS; ?158?????? return false; ?159???? } I think this code and comment predate anonymous classes. Probably before anonymous classes the check was not for !is_modifiable_class() but instead was just a check for primitive or array class types since they are not an InstanceKlass, and would cause issues when cast to one in the code that lies below this section. When anonymous classes were added, the code got changed to use !is_modifiable_class() and the comment was not correctly updated (anonymous classes are an InstanceKlass). Then with this webrev the mention of hidden classes was added, also incorrectly implying they are not an InstanceKlass. I think you should just leave off the last sentence of the comment. There's some ambiguity in the application of adjectives in the following: ?297?? // Cannot redefine or retransform a hidden or an unsafe anonymous class. I'd suggest: ?297?? // Cannot redefine or retransform a hidden class or an unsafe anonymous class. There are some places in libjdwp that need to be fixed. I spoke to Serguei about those this afternoon. Basically the convertSignatureToClassname() function needs to be fixed to handle hidden classes. Without the fix classname filtering will have problems if the filter contains a pattern with a '/' to filter on hidden classes. Also CLASS_UNLOAD events will not properly convert hidden class names. We also need tests for these cases. I think these are all things that can be addressed later. I still need to look over the JVMTI tests. thanks, Chris On 3/26/20 4:57 PM, Mandy Chung wrote: > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area. Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point > of view, a hidden class is a normal class except the following: > > - A hidden class has no initiating class loader and is not registered > in any dictionary. > - A hidden class has a name containing an illegal character > `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` > returns "Lp/Foo.0x1234;". > - A hidden class is not modifiable, i.e. cannot be redefined or > retransformed. JVM TI IsModifableClass returns false on a hidden. > - Final fields in a hidden class is "final".? The value of final > fields cannot be overriden via reflection.? setAccessible(true) can > still be called on reflected objects representing final fields in a > hidden class and its access check will be suppressed but only have > read-access (i.e. can do Field::getXXX but not setXXX). > > Brief summary of this patch: > > 1. A new Lookup::defineHiddenClass method is the API to create a > hidden class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG > option that > ?? can be specified when creating a hidden class. > 3. A new Class::isHiddenClass method tests if a class is a hidden class. > 4. Field::setXXX method will throw IAE on a final field of a hidden class > ?? regardless of the value of the accessible flag. > 5. JVM_LookupDefineClass is the new JVM entry point for > Lookup::defineClass > ?? and defineHiddenClass to create a class from the given bytes. > 6. ClassLoaderData implementation is not changed.? There is one > primary CLD > ?? that holds the classes strongly referenced by its defining loader.? > There > ?? can be zero or more additional CLDs - one per weak class. > 7. Nest host determination is updated per revised JVMS 5.4.4. Access > control > ?? check no longer throws LinkageError but instead it will throw IAE with > ?? a clear message if a class fails to resolve/validate the nest host > declared > ?? in NestHost/NestMembers attribute. > 8. JFR, jcmd, JDI are updated to support hidden classes. > 9. update javac LambdaToMethod as lambda proxy starts using nestmates > ?? and generate a bridge method to desuger a method reference to a > protected > ?? method in its supertype in a different package > > This patch also updates StringConcatFactory, LambdaMetaFactory, and > LambdaForms > to use hidden classes.? The webrev includes changes in nashorn to > hidden class > and I will update the webrev if JEP 372 removes it any time soon. > > We uncovered a bug in Lookup::defineClass spec throws LinkageError and > intends > to have the newly created class linked.? However, the implementation in 14 > does not link the class.? A separate CSR [2] proposes to update the > implementation to match the spec.? This patch fixes the implementation. > > The spec update on JVM TI, JDI and Instrumentation will be done as > a separate RFE [3].? This patch includes new tests for JVM TI and > java.instrument that validates how the existing APIs work for hidden > classes. > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From joe.darcy at oracle.com Sat Mar 28 04:53:27 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 27 Mar 2020 21:53:27 -0700 Subject: JDK 15 RFR of JDK-8241789: Make citations of JLS and JVMS consistent in java.lang.Class Message-ID: <257cb0e0-d369-5dc7-f97c-018d6a6045b4@oracle.com> Hello, As noticed during the CSR review of JDK-8238359, not all the citations of JVMS and JLS are done consistently in java.lang.Class. These citations should be done uniformly. ??? http://cr.openjdk.java.net/~darcy/8241789.0/ Patch below. The referenced JVMS "table 4.1" had been renumbered so I replaced it with a reference to section 4.1. I did not reflow the paragraphs to make this review easier; I'll do a reflow where appropriate before pushing. Thanks, -Joe --- old/src/java.base/share/classes/java/lang/Class.java 2020-03-27 21:37:41.703808000 -0700 +++ new/src/java.base/share/classes/java/lang/Class.java 2020-03-27 21:37:41.415664000 -0700 @@ -139,7 +139,7 @@ ? * ? * ? *

        It is also possible to get the {@code Class} object for a named - * type (or for void) using a class literal.? See Section 15.8.2 of + * type (or for void) using a class literal.? See Section {@jls 15.8.2} of ? * The Java™ Language Specification. ? * For example: ? * @@ -376,14 +376,14 @@ ????? * ????? * Note that this method throws errors related to loading, linking ????? * or initializing as specified in Sections {@jls 12.2}, {@jls -???? * 12.3}, and {@jls 12.4} of The Java Language -???? * Specification. +???? * 12.3}, and {@jls 12.4} of The Java™ Language +???? * Specification. ????? * Note that this method does not check whether the requested class ????? * is accessible to its caller. ????? * ????? * @param name?????? fully qualified name of the desired class ????? * @param initialize if {@code true} the class will be initialized (which implies linking). -???? *?????????????????? See Section {@jls 12.4} of The Java Language Specification. +???? *?????????????????? See Section {@jls 12.4} of The Java™ Language Specification. ????? * @param loader???? class loader from which the class must be loaded ????? * @return?????????? class object representing the desired class ????? * @@ -660,8 +660,8 @@ ????? *

        Specifically, this method tests whether the type represented by the ????? * specified {@code Class} parameter can be converted to the type ????? * represented by this {@code Class} object via an identity conversion -???? * or via a widening reference conversion. See The Java Language -???? * Specification, sections {@jls 5.1.1} and {@jls 5.1.4}, +???? * or via a widening reference conversion. See The Java™ Language +???? * Specification, sections {@jls 5.1.1} and {@jls 5.1.4}, ????? * for details. ????? * ????? * @param???? cls the {@code Class} object to be checked @@ -745,7 +745,7 @@ ????? * Returns {@code true} if this class is a synthetic class; ????? * returns {@code false} otherwise. ????? * @return {@code true} if and only if this class is a synthetic class as -???? *???????? defined by the Java Language Specification. +???? *???????? defined by The Java™ Language Specification. ????? * @jls 13.1 The Form of a Binary ????? * @since 1.5 ????? */ @@ -896,8 +896,8 @@ ????? *???? the type variables declared by this generic declaration ????? * @throws java.lang.reflect.GenericSignatureFormatError if the generic ????? *???? signature of this generic declaration does not conform to -???? *???? the format specified in -???? *???? The Java™ Virtual Machine Specification +???? *???? the format specified in section {@jvms 4.7.9} of the +???? *???? The Java™ Virtual Machine Specification, ????? * @since 1.5 ????? */ ???? @SuppressWarnings("unchecked") @@ -945,6 +945,7 @@ ????? * ????? * @throws java.lang.reflect.GenericSignatureFormatError if the generic ????? *???? class signature does not conform to the format specified in +???? *???? section {@jvms 4.7.9} of the ????? *???? The Java™ Virtual Machine Specification ????? * @throws TypeNotPresentException if the generic superclass ????? *???? refers to a non-existent type declaration @@ -1143,7 +1144,7 @@ ????? * ????? * @throws java.lang.reflect.GenericSignatureFormatError ????? *???? if the generic class signature does not conform to the format -???? *???? specified in +???? *???? specified in section {@jvms 4.7.9} of the ????? *???? The Java™ Virtual Machine Specification ????? * @throws TypeNotPresentException if any of the generic ????? *???? superinterfaces refers to a non-existent type declaration @@ -1201,8 +1202,8 @@ ????? * {@code false}. The values of its other modifiers are not determined ????? * by this specification. ????? * -???? *

        The modifier encodings are defined in The Java Virtual Machine -???? * Specification, table 4.1. +???? *

        The modifier encodings are defined in section {@jvms 4.1} of the +???? * The Java™ Virtual Machine Specification. ????? * ????? * @return the {@code int} representing the modifiers for this class ????? * @see???? java.lang.reflect.Modifier @@ -1611,7 +1612,7 @@ ???? /** ????? * Returns the canonical name of the underlying class as -???? * defined by the Java Language Specification.? Returns null if +???? * defined by The Java™ Language Specification, section {@jls 6.7}.? Returns null if ????? * the underlying class does not have a canonical name (i.e., if ????? * it is a local or anonymous class or an array whose component ????? * type does not have a canonical name). @@ -1928,7 +1929,8 @@ ????? * class has no public constructors, or if the class is an array class, or ????? * if the class reflects a primitive type or void. ????? * -???? * Note that while this method returns an array of {@code +???? * @apiNote +???? * While this method returns an array of {@code ????? * Constructor} objects (that is an array of constructors from ????? * this class), the return type of this method is {@code ????? * Constructor[]} and not {@code Constructor[]} as @@ -2401,7 +2403,7 @@ ????? * object represents an interface, a primitive type, an array class, or ????? * void. ????? * -???? *

        See The Java Language Specification, section {@jls 8.2}. +???? *

        See The Java™ Language Specification, section {@jls 8.2}. ????? * ????? * @return? the array of {@code Constructor} objects representing all the ????? *????????? declared constructors of this class @@ -3538,9 +3540,10 @@ ????? * otherwise, if this class is not a system class (i.e., it has a ????? * class loader) its class loader's default assertion status is returned; ????? * otherwise, the system class default assertion status is returned. -???? *

        +???? * +???? * @apiNote ????? * Few programmers will have any need for this method; it is provided -???? * for the benefit of the JRE itself.? (It allows a class to determine at +???? * for the benefit of the JDK itself.? (It allows a class to determine at ????? * the time that it is initialized whether assertions should be enabled.) ????? * Note that this method is not guaranteed to return the actual ????? * assertion status that was (or will be) associated with the specified @@ -4025,10 +4028,10 @@ ????? * ????? * @apiNote A {@code class} file of version 55.0 or greater may record the ????? * host of the nest to which it belongs by using the {@code NestHost} -???? * attribute (JVMS 4.7.28). Alternatively, a {@code class} file of +???? * attribute (JVMS {@jvms 4.7.28}). Alternatively, a {@code class} file of ????? * version 55.0 or greater may act as a nest host by enumerating the nest's ????? * other members with the -???? * {@code NestMembers} attribute (JVMS 4.7.29). +???? * {@code NestMembers} attribute (JVMS {@jvms 4.7.29}). ????? * A {@code class} file of version 54.0 or lower does not use these ????? * attributes. ????? * From andy.herrick at oracle.com Sat Mar 28 13:43:12 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Sat, 28 Mar 2020 09:43:12 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> Message-ID: <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> On 3/27/2020 5:18 PM, Alexander Matveev wrote: > Hi Andy, > > http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html > > Line 819,857,902 - Looks like temp debug log message. Remove it or > align with rest of code. I will fix this. > http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html > > Line 70 - Capital F. and this > > Since we added "--timestamp" and? "--options runtime" to codesign, > will it work with older Xcode and macOS we planning to support? not sure - may need some discussion of what we support and possible conditional code here. > > Do we need any adjustments to signing tests we have? The existing tests pass, but this is not unexpected (and really means nothing) since the signing tests are all skipped unless specific test certs are installed on target machine. We need further discussion how one is expected to provision a machine to run these tests. /Andy > > Otherwise looks fine. > > Thanks, > Alexander > > On 3/27/20 12:35 PM, Andy Herrick wrote: >> Please review the fix to issue [1] at [2]. >> >> This change enables notarization on Mac for dmg images and app-image >> zip files. >> >> /Andy >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >> >> [2]: http://cr.openjdk.java.net/~herrick/8237490 >> > From jonathan.gibbons at oracle.com Sat Mar 28 14:59:57 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 28 Mar 2020 07:59:57 -0700 Subject: JDK 15 RFR of JDK-8241789: Make citations of JLS and JVMS consistent in java.lang.Class In-Reply-To: <257cb0e0-d369-5dc7-f97c-018d6a6045b4@oracle.com> References: <257cb0e0-d369-5dc7-f97c-018d6a6045b4@oracle.com> Message-ID: <93c73e92-b37f-5bb9-5e0b-5157d4684965@oracle.com> double "the" 899 * the format specified in section {@jvms 4.7.9} of the 900 * The Java™ Virtual Machine Specification, Otherwise OK, -- Jon On 3/27/20 9:53 PM, Joe Darcy wrote: > Hello, > > As noticed during the CSR review of JDK-8238359, not all the citations > of JVMS and JLS are done consistently in java.lang.Class. These > citations should be done uniformly. > > ??? http://cr.openjdk.java.net/~darcy/8241789.0/ > > Patch below. > > The referenced JVMS "table 4.1" had been renumbered so I replaced it > with a reference to section 4.1. > > I did not reflow the paragraphs to make this review easier; I'll do a > reflow where appropriate before pushing. > > Thanks, > > -Joe > > --- old/src/java.base/share/classes/java/lang/Class.java 2020-03-27 > 21:37:41.703808000 -0700 > +++ new/src/java.base/share/classes/java/lang/Class.java 2020-03-27 > 21:37:41.415664000 -0700 > @@ -139,7 +139,7 @@ > ? * > ? * > ? *

        It is also possible to get the {@code Class} object for a named > - * type (or for void) using a class literal.? See Section 15.8.2 of > + * type (or for void) using a class literal.? See Section {@jls > 15.8.2} of > ? * The Java™ Language Specification. > ? * For example: > ? * > @@ -376,14 +376,14 @@ > ????? * > ????? * Note that this method throws errors related to loading, linking > ????? * or initializing as specified in Sections {@jls 12.2}, {@jls > -???? * 12.3}, and {@jls 12.4} of The Java Language > -???? * Specification. > +???? * 12.3}, and {@jls 12.4} of The Java™ Language > +???? * Specification. > ????? * Note that this method does not check whether the requested class > ????? * is accessible to its caller. > ????? * > ????? * @param name?????? fully qualified name of the desired class > ????? * @param initialize if {@code true} the class will be > initialized (which implies linking). > -???? *?????????????????? See Section {@jls 12.4} of The Java > Language Specification. > +???? *?????????????????? See Section {@jls 12.4} of The > Java™ Language Specification. > ????? * @param loader???? class loader from which the class must be > loaded > ????? * @return?????????? class object representing the desired class > ????? * > @@ -660,8 +660,8 @@ > ????? *

        Specifically, this method tests whether the type > represented by the > ????? * specified {@code Class} parameter can be converted to the type > ????? * represented by this {@code Class} object via an identity > conversion > -???? * or via a widening reference conversion. See The Java Language > -???? * Specification, sections {@jls 5.1.1} and {@jls 5.1.4}, > +???? * or via a widening reference conversion. See The > Java™ Language > +???? * Specification, sections {@jls 5.1.1} and {@jls 5.1.4}, > ????? * for details. > ????? * > ????? * @param???? cls the {@code Class} object to be checked > @@ -745,7 +745,7 @@ > ????? * Returns {@code true} if this class is a synthetic class; > ????? * returns {@code false} otherwise. > ????? * @return {@code true} if and only if this class is a synthetic > class as > -???? *???????? defined by the Java Language Specification. > +???? *???????? defined by The Java™ Language > Specification. > ????? * @jls 13.1 The Form of a Binary > ????? * @since 1.5 > ????? */ > @@ -896,8 +896,8 @@ > ????? *???? the type variables declared by this generic declaration > ????? * @throws java.lang.reflect.GenericSignatureFormatError if the > generic > ????? *???? signature of this generic declaration does not conform to > -???? *???? the format specified in > -???? *???? The Java™ Virtual Machine Specification > +???? *???? the format specified in section {@jvms 4.7.9} of the > +???? *???? The Java™ Virtual Machine Specification, > ????? * @since 1.5 > ????? */ > ???? @SuppressWarnings("unchecked") > @@ -945,6 +945,7 @@ > ????? * > ????? * @throws java.lang.reflect.GenericSignatureFormatError if the > generic > ????? *???? class signature does not conform to the format specified in > +???? *???? section {@jvms 4.7.9} of the > ????? *???? The Java™ Virtual Machine Specification > ????? * @throws TypeNotPresentException if the generic superclass > ????? *???? refers to a non-existent type declaration > @@ -1143,7 +1144,7 @@ > ????? * > ????? * @throws java.lang.reflect.GenericSignatureFormatError > ????? *???? if the generic class signature does not conform to the format > -???? *???? specified in > +???? *???? specified in section {@jvms 4.7.9} of the > ????? *???? The Java™ Virtual Machine Specification > ????? * @throws TypeNotPresentException if any of the generic > ????? *???? superinterfaces refers to a non-existent type declaration > @@ -1201,8 +1202,8 @@ > ????? * {@code false}. The values of its other modifiers are not > determined > ????? * by this specification. > ????? * > -???? *

        The modifier encodings are defined in The Java Virtual > Machine > -???? * Specification, table 4.1. > +???? *

        The modifier encodings are defined in section {@jvms 4.1} > of the > +???? * The Java™ Virtual Machine Specification. > ????? * > ????? * @return the {@code int} representing the modifiers for this class > ????? * @see???? java.lang.reflect.Modifier > @@ -1611,7 +1612,7 @@ > > ???? /** > ????? * Returns the canonical name of the underlying class as > -???? * defined by the Java Language Specification.? Returns null if > +???? * defined by The Java™ Language > Specification, section {@jls 6.7}.? Returns null if > ????? * the underlying class does not have a canonical name (i.e., if > ????? * it is a local or anonymous class or an array whose component > ????? * type does not have a canonical name). > @@ -1928,7 +1929,8 @@ > ????? * class has no public constructors, or if the class is an array > class, or > ????? * if the class reflects a primitive type or void. > ????? * > -???? * Note that while this method returns an array of {@code > +???? * @apiNote > +???? * While this method returns an array of {@code > ????? * Constructor} objects (that is an array of constructors from > ????? * this class), the return type of this method is {@code > ????? * Constructor[]} and not {@code Constructor[]} as > @@ -2401,7 +2403,7 @@ > ????? * object represents an interface, a primitive type, an array > class, or > ????? * void. > ????? * > -???? *

        See The Java Language Specification, section > {@jls 8.2}. > +???? *

        See The Java™ Language Specification, > section {@jls 8.2}. > ????? * > ????? * @return? the array of {@code Constructor} objects representing > all the > ????? *????????? declared constructors of this class > @@ -3538,9 +3540,10 @@ > ????? * otherwise, if this class is not a system class (i.e., it has a > ????? * class loader) its class loader's default assertion status is > returned; > ????? * otherwise, the system class default assertion status is returned. > -???? *

        > +???? * > +???? * @apiNote > ????? * Few programmers will have any need for this method; it is > provided > -???? * for the benefit of the JRE itself.? (It allows a class to > determine at > +???? * for the benefit of the JDK itself.? (It allows a class to > determine at > ????? * the time that it is initialized whether assertions should be > enabled.) > ????? * Note that this method is not guaranteed to return the actual > ????? * assertion status that was (or will be) associated with the > specified > @@ -4025,10 +4028,10 @@ > ????? * > ????? * @apiNote A {@code class} file of version 55.0 or greater may > record the > ????? * host of the nest to which it belongs by using the {@code > NestHost} > -???? * attribute (JVMS 4.7.28). Alternatively, a {@code class} file of > +???? * attribute (JVMS {@jvms 4.7.28}). Alternatively, a {@code > class} file of > ????? * version 55.0 or greater may act as a nest host by enumerating > the nest's > ????? * other members with the > -???? * {@code NestMembers} attribute (JVMS 4.7.29). > +???? * {@code NestMembers} attribute (JVMS {@jvms 4.7.29}). > ????? * A {@code class} file of version 54.0 or lower does not use these > ????? * attributes. > ????? * > From andy.herrick at oracle.com Sat Mar 28 18:49:53 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Sat, 28 Mar 2020 14:49:53 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> Message-ID: <9f9c708f-4dc5-f04a-08ae-dd52201b0a68@oracle.com> On 3/28/2020 9:43 AM, Andy Herrick wrote: > > On 3/27/2020 5:18 PM, Alexander Matveev wrote: >> Hi Andy, >> >> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >> >> Line 819,857,902 - Looks like temp debug log message. Remove it or >> align with rest of code. > I will fix this. >> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >> >> Line 70 - Capital F. > and this >> >> Since we added "--timestamp" and? "--options runtime" to codesign, >> will it work with older Xcode and macOS we planning to support? > not sure - may need some discussion of what we support and possible > conditional code here. The "--timestamp" argument existed in earlier versions of XCode, but the option "runtime" is just since XCode 10.14.0, however the man page for codesign specifically says that macOS versions older than 10.14.0 ignore the presence of this flag in the code signature. /Andy >> >> Do we need any adjustments to signing tests we have? > > The existing tests pass, but this is not unexpected (and really means > nothing) since the signing tests are all skipped unless specific test > certs are installed on target machine. > > We need further discussion how one is expected to provision a machine > to run these tests. > > /Andy > >> >> Otherwise looks fine. >> >> Thanks, >> Alexander >> >> On 3/27/20 12:35 PM, Andy Herrick wrote: >>> Please review the fix to issue [1] at [2]. >>> >>> This change enables notarization on Mac for dmg images and app-image >>> zip files. >>> >>> /Andy >>> >>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>> >>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>> >> From forax at univ-mlv.fr Sat Mar 28 19:52:37 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 28 Mar 2020 20:52:37 +0100 (CET) Subject: ASM 8 is available Message-ID: <728116829.1734618.1585425157713.JavaMail.zimbra@u-pem.fr> Hi all, it's a little bit OT even if the JDK itself as a dependency on ASM. I'm proud to announce that ASM 8 (nicknamed the Quarantine Edition) was released today ! It fully supports Java 14 (the Record attribute) and even support sealed types (the attribute PermittedSubtypes) as an experimental feature. be safe, R?mi From joe.darcy at oracle.com Sat Mar 28 20:34:56 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 28 Mar 2020 13:34:56 -0700 Subject: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact Message-ID: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> Hello, Please review the initial proposed wording of the spec for ??? JDK-8241374: add Math.absExact The eventual wording needs to be replicated four times (Math.absExact(int), Math.absExact(long), StrictMath.absExact(int), StrictMath.absExact(long)) so I want to get the wording agreed to before presenting it in quadruplicate. The other "exact" methods mention overflow so I wanted the spec to absExact to include both "exact" and "overflow" in its description. Tests will follow in subsequent review iterations. Thanks, -Joe diff -r c5d90e8d4a46 src/java.base/share/classes/java/lang/Math.java --- a/src/java.base/share/classes/java/lang/Math.java??? Sat Mar 28 11:00:09 2020 -0400 +++ b/src/java.base/share/classes/java/lang/Math.java??? Sat Mar 28 10:17:39 2020 -0700 @@ -1369,6 +1369,32 @@ ???? } ???? /** +???? * Returns the mathematical absolute value of an {@code int} value +???? * if it is exactly representable as an {@code int}, throwing +???? * {@code ArithmeticException} if the result overflows the +???? * positive {@code int} range. +???? * +???? *

        Since the range of two's complement integers is asymmetric +???? * with one additional negative value, the mathematical absolute +???? * value of {@link Integer#MIN_VALUE} overflows the positive +???? * {@code int} range and an exception is thrown for that argument. +???? * +???? * @param?? a?? the argument whose absolute value is to be determined +???? * @return the absolute value of the argument absent overflow +???? * @throws ArithmeticException if the argument is {@link Integer#MIN_VALUE} +???? * @see Math#abs(int) +???? * @since 15 +???? */ +??? public static int absExact(int a) { +??????? if (a == Integer.MIN_VALUE) +??????????? throw new ArithmeticException("Cannot represent " + +????????????????????????????????????????? "absolute value of " + +????????????????????????????????????????? "Integer.MIN_VALUE"); +??????? else +??????????? return abs(a); +??? } + +??? /** ????? * Returns the absolute value of a {@code long} value. ????? * If the argument is not negative, the argument is returned. ????? * If the argument is negative, the negation of the argument is returned. From stuart.marks at oracle.com Sun Mar 29 02:37:06 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Sat, 28 Mar 2020 19:37:06 -0700 Subject: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact In-Reply-To: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> References: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> Message-ID: Hi Joe, Overall this looks quite good. Thanks for being thorough about this; I certainly would have forgotten about StrictMath. :-) Since this is integer arithmetic, is it true that the StrictMath versions are identical to the Math versions? I have only a couple editorial quibbles. > + * {@code int} range and an exception is thrown for that argument. Recommend adding a comma here: > + * {@code int} range, and an exception is thrown for that argument. -- > + * @return the absolute value of the argument absent overflow I stumbled while reading this. While not incorrect, it seems a bit awkwardly worded to me. How about something like "...the argument, unless overflow occurs." -- > + throw new ArithmeticException("Cannot represent " + > + "absolute value of " + > + "Integer.MIN_VALUE"); In cases like this I usually prefer to put the entire string on its own line, avoiding the concatenation: > + throw new ArithmeticException( > + "Cannot represent absolute value of Integer.MIN_VALUE"); -- Thanks, s'marks On 3/28/20 1:34 PM, Joe Darcy wrote: > Hello, > > Please review the initial proposed wording of the spec for > > ??? JDK-8241374: add Math.absExact > > The eventual wording needs to be replicated four times (Math.absExact(int), > Math.absExact(long), StrictMath.absExact(int), StrictMath.absExact(long)) so I > want to get the wording agreed to before presenting it in quadruplicate. > > The other "exact" methods mention overflow so I wanted the spec to absExact to > include both "exact" and "overflow" in its description. > > Tests will follow in subsequent review iterations. > > Thanks, > > -Joe > > diff -r c5d90e8d4a46 src/java.base/share/classes/java/lang/Math.java > --- a/src/java.base/share/classes/java/lang/Math.java??? Sat Mar 28 11:00:09 > 2020 -0400 > +++ b/src/java.base/share/classes/java/lang/Math.java??? Sat Mar 28 10:17:39 > 2020 -0700 > @@ -1369,6 +1369,32 @@ > ???? } > > ???? /** > +???? * Returns the mathematical absolute value of an {@code int} value > +???? * if it is exactly representable as an {@code int}, throwing > +???? * {@code ArithmeticException} if the result overflows the > +???? * positive {@code int} range. > +???? * > +???? *

        Since the range of two's complement integers is asymmetric > +???? * with one additional negative value, the mathematical absolute > +???? * value of {@link Integer#MIN_VALUE} overflows the positive > +???? * {@code int} range and an exception is thrown for that argument. > +???? * > +???? * @param?? a?? the argument whose absolute value is to be determined > +???? * @return the absolute value of the argument absent overflow > +???? * @throws ArithmeticException if the argument is {@link Integer#MIN_VALUE} > +???? * @see Math#abs(int) > +???? * @since 15 > +???? */ > +??? public static int absExact(int a) { > +??????? if (a == Integer.MIN_VALUE) > +??????????? throw new ArithmeticException("Cannot represent " + > +????????????????????????????????????????? "absolute value of " + > +????????????????????????????????????????? "Integer.MIN_VALUE"); > +??????? else > +??????????? return abs(a); > +??? } > + > +??? /** > ????? * Returns the absolute value of a {@code long} value. > ????? * If the argument is not negative, the argument is returned. > ????? * If the argument is negative, the negation of the argument is returned. > From ivan.gerasimov at oracle.com Sun Mar 29 04:39:39 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 28 Mar 2020 21:39:39 -0700 Subject: [15] RFR 8241727 : Typos: empty lines in javadoc, inconsistent indents, etc. (core-libs only) In-Reply-To: <21FDAF1A-BC4F-4946-BA4A-EBFF0415CF63@oracle.com> References: <21FDAF1A-BC4F-4946-BA4A-EBFF0415CF63@oracle.com> Message-ID: Thank you Pavel! Pushed. On 3/27/20 5:09 AM, Pavel Rappo wrote: > 140 a successful * query to a constant will always remain successful. > > Made me pause and read a bit of the surrounding context > to make sure there's no "*" type of query. > > Looks good to me. Thanks for doing this. > > -Pavel > >> On 27 Mar 2020, at 10:26, Ivan Gerasimov wrote: >> >> Hello! >> >> This is a javadoc-only fix. >> >> There are a few changes that will actually be visible (for example [1], [2]), but the vast majority of changes are to remove redundant empty lines, correct indentation, or otherwise restore harmony. >> >> Would you please help review this rather technical fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8241727 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8241727/00/webrev/ >> >> Thank in advance! >> >> [1] Extra '+' in text: https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/io/ObjectInputStream.html#readObjectOverride() >> >> [2] Extra 'I' in text: https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/annotation/Annotation.html#hashCode() >> >> -- >> >> With kind regards, >> Ivan Gerasimov >> -- With kind regards, Ivan Gerasimov From amaembo at gmail.com Sun Mar 29 08:29:01 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Sun, 29 Mar 2020 15:29:01 +0700 Subject: [PING] RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: References: <87r1xhsayk.fsf@mid.deneb.enyo.de> Message-ID: Thank you for the review! Here's the updated version: http://cr.openjdk.java.net/~tvaleev/webrev/8176894/r5/ Martin, > 676 V newValue; > 677 int mc = modCount; > 678 newValue = mappingFunction.apply(key); > I would never use a C style declaration when an initializing declaration would work equally well. Nice catch, thanks! Fixed > Prevailing whitespace style here is Entry rather than Entry but Intellij is on your side Fixed in my changes as well. Though there are still eight occurrences of outside of my changes. Thomas, > remapValue: > > 711 } else { > 712 // replace old mapping > 713 t.value = newValue; > 714 return newValue; > 715 } > > Should we increase the modification count here? AFAICS Map::computeIfPresent(), Map::compute(), Map::merge() use put() to replace existing value which would have increased TreeMap::modCount . Florian is right: it's not a structural modification. E.g. Entry.setValue() doesn't increase modCount. Also, same operations on HashMap don't update it as well. > At various places, the "@throws ConcurrentModificationException" javadoc: > > 619 * @throws ConcurrentModificationException if it is detected that the > 620 * mapping function modified this map > > is missing the period. Done. > We could exchange all the various > > if (key == null) > throw new NullPointerException(); > > lines on comparator==null paths with > > Objects.requireNonNull(key). Done. Also, updated getEntry() similarly (was not changed before). > Style nits & bikeshedding: > > I would place both versions of getNewValueAndCheckModification() together with the other new low level utility functions (addEntry, addEntryToEmptyMap). I may also have named them somewhat differently, maybe "callMappingFunctionWithCheck" resp. "callRemappingFunctionWithCheck". I grouped together all the added private methods and renamed, as per your suggestion. > private void addEntry(K key, V value, int cmp, Entry parent) { > > For clarity, could we make cmp a boolean "leftOrRight" or are you afraid that would cost too much performance? I don't think this should harm the performance significantly. However, "leftOrRight" name sounds confusing for boolean parameter (it's not evident whether 'true' means 'left' or 'right'). So I named the parameter "addToLeft". I'd like to push this changeset in 3-4 days unless I see any objections or new review comments. Thanks again! With best regards, Tagir Valeev. From martinrb at google.com Sun Mar 29 16:48:46 2020 From: martinrb at google.com (Martin Buchholz) Date: Sun, 29 Mar 2020 09:48:46 -0700 Subject: [PING] RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: References: <87r1xhsayk.fsf@mid.deneb.enyo.de> Message-ID: I'm fine with the latest version On Sun, Mar 29, 2020 at 1:29 AM Tagir Valeev wrote: > > > At various places, the "@throws ConcurrentModificationException" javadoc: > > > > 619 * @throws ConcurrentModificationException if it is detected > that the > > 620 * mapping function modified this map > > > > is missing the period. > > Done. > Sigh ... my own consistent practice has been to *not* put periods at the end of @throws clauses, but obviously other maintainers ended up elsewhere. From thomas.stuefe at gmail.com Sun Mar 29 18:22:54 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 29 Mar 2020 20:22:54 +0200 Subject: [PING] RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: References: <87r1xhsayk.fsf@mid.deneb.enyo.de> Message-ID: On Sun 29. Mar 2020 at 18:48, Martin Buchholz wrote: > I'm fine with the latest version > > On Sun, Mar 29, 2020 at 1:29 AM Tagir Valeev wrote: > >> >> > At various places, the "@throws ConcurrentModificationException" >> javadoc: >> > >> > 619 * @throws ConcurrentModificationException if it is detected >> that the >> > 620 * mapping function modified this map >> > >> > is missing the period. >> >> Done. >> > > Sigh ... my own consistent practice has been to *not* put periods at the > end of @throws clauses, but obviously other maintainers ended up elsewhere. > Oops sorry. If it is important for you, I can live without the period... > From joe.darcy at oracle.com Sun Mar 29 19:03:54 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 29 Mar 2020 12:03:54 -0700 Subject: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact In-Reply-To: References: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> Message-ID: <6a4ede91-d116-7255-a5d2-482a9ea3176a@oracle.com> Hi Stuart, Full webrev for review include including tests: ??? http://cr.openjdk.java.net/~darcy/8241374.0/ and the companion CSR: ??? https://bugs.openjdk.java.net/browse/JDK-8241805 Replies interspersed below. On 3/28/2020 7:37 PM, Stuart Marks wrote: > Hi Joe, > > Overall this looks quite good. Thanks for being thorough about this; I > certainly would have forgotten about StrictMath. :-) I may have initial forgotten about StrictMath myself on at least one prior occasion ;-) > Since this is integer arithmetic, is it true that the StrictMath > versions are identical to the Math versions? Right; conceptually StrictMath is a subclass of Math where certain methods have additional cross-platform reproducibility requirements. However, since all the methods are static, at least the javadoc gets replicated although the StrictMath implementations of integer methods can just call the Math one. (In that case, the delegation could go the other way too, but as Math is called more often, it is a little better to have the real implementation hosted there.) > > I have only a couple editorial quibbles. > >> +???? * {@code int} range and an exception is thrown for that argument. > > Recommend adding a comma here: > >> +???? * {@code int} range, and an exception is thrown for that argument. > Changed to {@code int range}, so an exception is thrown for that argument. > -- > >> +???? * @return the absolute value of the argument absent overflow > > I stumbled while reading this. While not incorrect, it seems a bit > awkwardly worded to me. How about something like "...the argument, > unless overflow occurs." Changed as suggested. Normally the exception behavior is not described in an @return tag, but the point of this method is its exceptional behavior so I think that variance with typical practice is fine. > > -- > >> +??????????? throw new ArithmeticException("Cannot represent " + >> +????????????????????????????????????????? "absolute value of " + >> +????????????????????????????????????????? "Integer.MIN_VALUE"); > > In cases like this I usually prefer to put the entire string on its > own line, avoiding the concatenation: > >> +??????????? throw new ArithmeticException( >> +??????????????? "Cannot represent absolute value of >> Integer.MIN_VALUE"); Okay; also changed wording to: ??? "Overflow to represent absolute value of Integer.MIN_VALUE" Thanks, -Joe From Roger.Riggs at oracle.com Sun Mar 29 21:32:29 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Sun, 29 Mar 2020 17:32:29 -0400 Subject: [PING] RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: References: <87r1xhsayk.fsf@mid.deneb.enyo.de> Message-ID: <89556c4d-c01c-d9d7-d773-a03d583579f4@oracle.com> Hi, Usually the @throws, @param, @return, etc clauses are not complete sentences. Only complete sentences need a period. And most of OpenJDK omits them. $.02, Roger On 3/29/20 2:22 PM, Thomas St?fe wrote: > On Sun 29. Mar 2020 at 18:48, Martin Buchholz wrote: > >> I'm fine with the latest version >> >> On Sun, Mar 29, 2020 at 1:29 AM Tagir Valeev wrote: >> >>>> At various places, the "@throws ConcurrentModificationException" >>> javadoc: >>>> 619 * @throws ConcurrentModificationException if it is detected >>> that the >>>> 620 * mapping function modified this map >>>> >>>> is missing the period. >>> Done. >>> >> Sigh ... my own consistent practice has been to *not* put periods at the >> end of @throws clauses, but obviously other maintainers ended up elsewhere. >> > Oops sorry. If it is important for you, I can live without the period... > From forax at univ-mlv.fr Sun Mar 29 22:26:59 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 30 Mar 2020 00:26:59 +0200 (CEST) Subject: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact In-Reply-To: References: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> Message-ID: <1534666770.16411.1585520819260.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Stuart Marks" > ?: "joe darcy" > Cc: "core-libs-dev" > Envoy?: Dimanche 29 Mars 2020 04:37:06 > Objet: Re: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact > Hi Joe, > > Overall this looks quite good. Thanks for being thorough about this; I certainly > would have forgotten about StrictMath. :-) Since this is integer arithmetic, is > it true that the StrictMath versions are identical to the Math versions? > > I have only a couple editorial quibbles. > >> + * {@code int} range and an exception is thrown for that argument. > > Recommend adding a comma here: > >> + * {@code int} range, and an exception is thrown for that argument. > > -- > >> + * @return the absolute value of the argument absent overflow > > I stumbled while reading this. While not incorrect, it seems a bit awkwardly > worded to me. How about something like "...the argument, unless overflow > occurs." > > -- > >> + throw new ArithmeticException("Cannot represent " + >> + "absolute value of " + >> + "Integer.MIN_VALUE"); > > In cases like this I usually prefer to put the entire string on its own line, > avoiding the concatenation: > >> + throw new ArithmeticException( >> + "Cannot represent absolute value of Integer.MIN_VALUE"); Yes, it's more readable. As a trivia, those concatenation are done by the compiler at compile time because both the left side and the right side of + are compile time constants. So the generated bytecode is identical. > > -- > > Thanks, > > s'marks R?mi > > > > > On 3/28/20 1:34 PM, Joe Darcy wrote: >> Hello, >> >> Please review the initial proposed wording of the spec for >> >> ??? JDK-8241374: add Math.absExact >> >> The eventual wording needs to be replicated four times (Math.absExact(int), >> Math.absExact(long), StrictMath.absExact(int), StrictMath.absExact(long)) so I >> want to get the wording agreed to before presenting it in quadruplicate. >> >> The other "exact" methods mention overflow so I wanted the spec to absExact to >> include both "exact" and "overflow" in its description. >> >> Tests will follow in subsequent review iterations. >> >> Thanks, >> >> -Joe >> >> diff -r c5d90e8d4a46 src/java.base/share/classes/java/lang/Math.java >> --- a/src/java.base/share/classes/java/lang/Math.java??? Sat Mar 28 11:00:09 >> 2020 -0400 >> +++ b/src/java.base/share/classes/java/lang/Math.java??? Sat Mar 28 10:17:39 >> 2020 -0700 >> @@ -1369,6 +1369,32 @@ >> ???? } >> >> ???? /** >> +???? * Returns the mathematical absolute value of an {@code int} value >> +???? * if it is exactly representable as an {@code int}, throwing >> +???? * {@code ArithmeticException} if the result overflows the >> +???? * positive {@code int} range. >> +???? * >> +???? *

        Since the range of two's complement integers is asymmetric >> +???? * with one additional negative value, the mathematical absolute >> +???? * value of {@link Integer#MIN_VALUE} overflows the positive >> +???? * {@code int} range and an exception is thrown for that argument. >> +???? * >> +???? * @param?? a?? the argument whose absolute value is to be determined >> +???? * @return the absolute value of the argument absent overflow >> +???? * @throws ArithmeticException if the argument is {@link Integer#MIN_VALUE} >> +???? * @see Math#abs(int) >> +???? * @since 15 >> +???? */ >> +??? public static int absExact(int a) { >> +??????? if (a == Integer.MIN_VALUE) >> +??????????? throw new ArithmeticException("Cannot represent " + >> +????????????????????????????????????????? "absolute value of " + >> +????????????????????????????????????????? "Integer.MIN_VALUE"); >> +??????? else >> +??????????? return abs(a); >> +??? } >> + >> +??? /** >> ????? * Returns the absolute value of a {@code long} value. >> ????? * If the argument is not negative, the argument is returned. >> ????? * If the argument is negative, the negation of the argument is returned. From mandy.chung at oracle.com Mon Mar 30 02:17:27 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 29 Mar 2020 19:17:27 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <90f9276d-2777-88ba-b1ec-9901711fcf02@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <90f9276d-2777-88ba-b1ec-9901711fcf02@oracle.com> Message-ID: On 3/27/20 8:51 PM, Chris Plummer wrote: > Hi Mandy, > > A couple of very minor nits in the jvmtiRedefineClasses.cpp comments: > > ?153???? // classes for primitives, arrays, hidden and vm unsafe > anonymous classes > ?154???? // cannot be redefined.? Check here so following code can > assume these classes > ?155???? // are InstanceKlass. > ?156???? if (!is_modifiable_class(mirror)) { > ?157?????? _res = JVMTI_ERROR_UNMODIFIABLE_CLASS; > ?158?????? return false; > ?159???? } > > I think this code and comment predate anonymous classes. Probably > before anonymous classes the check was not for !is_modifiable_class() > but instead was just a check for primitive or array class types since > they are not an InstanceKlass, and would cause issues when cast to one > in the code that lies below this section. When anonymous classes were > added, the code got changed to use !is_modifiable_class() and the > comment was not correctly updated (anonymous classes are an > InstanceKlass). Then with this webrev the mention of hidden classes > was added, also incorrectly implying they are not an InstanceKlass. I > think you should just leave off the last sentence of the comment. > I agree with you that this comment needs update.?? Perhaps it should say "primitive, array types and hidden classes are non-modifiable. A modifiable class must be an InstanceKlass." I leave it to Serguei who may have other opinion. > There's some ambiguity in the application of adjectives in the following: > > ?297?? // Cannot redefine or retransform a hidden or an unsafe > anonymous class. > > I'd suggest: > > ?297?? // Cannot redefine or retransform a hidden class or an unsafe > anonymous class. > +1 > There are some places in libjdwp that need to be fixed. I spoke to > Serguei about those this afternoon. Basically the > convertSignatureToClassname() function needs to be fixed to handle > hidden classes. Without the fix classname filtering will have problems > if the filter contains a pattern with a '/' to filter on hidden > classes. Also CLASS_UNLOAD events will not properly convert hidden > class names. We also need tests for these cases. I think these are all > things that can be addressed later. > Good catch.? I have created a subtask under JDK-8230502: ?? https://bugs.openjdk.java.net/browse/JDK-8230502 > I still need to look over the JVMTI tests. > Thanks Mandy > thanks, > > Chris > > On 3/26/20 4:57 PM, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area. Small changes are >> made in javac, VM compiler (intrinsification of >> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed >> and is in the finalized state (see specdiff and javadoc below for >> reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >> point >> of view, a hidden class is a normal class except the following: >> >> - A hidden class has no initiating class loader and is not registered >> in any dictionary. >> - A hidden class has a name containing an illegal character >> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >> returns "Lp/Foo.0x1234;". >> - A hidden class is not modifiable, i.e. cannot be redefined or >> retransformed. JVM TI IsModifableClass returns false on a hidden. >> - Final fields in a hidden class is "final".? The value of final >> fields cannot be overriden via reflection.? setAccessible(true) can >> still be called on reflected objects representing final fields in a >> hidden class and its access check will be suppressed but only have >> read-access (i.e. can do Field::getXXX but not setXXX). >> >> Brief summary of this patch: >> >> 1. A new Lookup::defineHiddenClass method is the API to create a >> hidden class. >> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >> option that >> ?? can be specified when creating a hidden class. >> 3. A new Class::isHiddenClass method tests if a class is a hidden class. >> 4. Field::setXXX method will throw IAE on a final field of a hidden >> class >> ?? regardless of the value of the accessible flag. >> 5. JVM_LookupDefineClass is the new JVM entry point for >> Lookup::defineClass >> ?? and defineHiddenClass to create a class from the given bytes. >> 6. ClassLoaderData implementation is not changed.? There is one >> primary CLD >> ?? that holds the classes strongly referenced by its defining >> loader.? There >> ?? can be zero or more additional CLDs - one per weak class. >> 7. Nest host determination is updated per revised JVMS 5.4.4. Access >> control >> ?? check no longer throws LinkageError but instead it will throw IAE >> with >> ?? a clear message if a class fails to resolve/validate the nest host >> declared >> ?? in NestHost/NestMembers attribute. >> 8. JFR, jcmd, JDI are updated to support hidden classes. >> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >> ?? and generate a bridge method to desuger a method reference to a >> protected >> ?? method in its supertype in a different package >> >> This patch also updates StringConcatFactory, LambdaMetaFactory, and >> LambdaForms >> to use hidden classes.? The webrev includes changes in nashorn to >> hidden class >> and I will update the webrev if JEP 372 removes it any time soon. >> >> We uncovered a bug in Lookup::defineClass spec throws LinkageError >> and intends >> to have the newly created class linked.? However, the implementation >> in 14 >> does not link the class.? A separate CSR [2] proposes to update the >> implementation to match the spec.? This patch fixes the implementation. >> >> The spec update on JVM TI, JDI and Instrumentation will be done as >> a separate RFE [3].? This patch includes new tests for JVM TI and >> java.instrument that validates how the existing APIs work for hidden >> classes. >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > > From linzang at tencent.com Mon Mar 30 02:41:54 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Mon, 30 Mar 2020 02:41:54 +0000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> Message-ID: Dear All, May I ask your help to reivew this tiny patch? Thanks. BRs, Lin From: "linzang(??)" Date: Thursday, March 26, 2020 at 3:13 PM To: "core-libs-dev at openjdk.java.net" Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Dear All, May I ask your help to review this tiny fix? Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ Thanks! BRs, Lin From serguei.spitsyn at oracle.com Mon Mar 30 03:40:43 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 29 Mar 2020 20:40:43 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <90f9276d-2777-88ba-b1ec-9901711fcf02@oracle.com> Message-ID: <7fe9fd65-8bee-beb3-03af-ab56120a4cc1@oracle.com> Hi Mandy and Chris, On 3/29/20 19:17, Mandy Chung wrote: > > > On 3/27/20 8:51 PM, Chris Plummer wrote: >> Hi Mandy, >> >> A couple of very minor nits in the jvmtiRedefineClasses.cpp comments: >> >> ?153???? // classes for primitives, arrays, hidden and vm unsafe >> anonymous classes >> ?154???? // cannot be redefined.? Check here so following code can >> assume these classes >> ?155???? // are InstanceKlass. >> ?156???? if (!is_modifiable_class(mirror)) { >> ?157?????? _res = JVMTI_ERROR_UNMODIFIABLE_CLASS; >> ?158?????? return false; >> ?159???? } >> >> I think this code and comment predate anonymous classes. Probably >> before anonymous classes the check was not for !is_modifiable_class() >> but instead was just a check for primitive or array class types since >> they are not an InstanceKlass, and would cause issues when cast to >> one in the code that lies below this section. When anonymous classes >> were added, the code got changed to use !is_modifiable_class() and >> the comment was not correctly updated (anonymous classes are an >> InstanceKlass). Then with this webrev the mention of hidden classes >> was added, also incorrectly implying they are not an InstanceKlass. I >> think you should just leave off the last sentence of the comment. >> > > I agree with you that this comment needs update.?? Perhaps it should > say "primitive, array types and hidden classes are non-modifiable. A > modifiable class must be an InstanceKlass." > > I leave it to Serguei who may have other opinion. We already had a chat with Chris about this. This suggestion looks right. >> There's some ambiguity in the application of adjectives in the >> following: >> >> ?297?? // Cannot redefine or retransform a hidden or an unsafe >> anonymous class. >> >> I'd suggest: >> >> ?297?? // Cannot redefine or retransform a hidden class or an unsafe >> anonymous class. >> > > +1 +1 >> There are some places in libjdwp that need to be fixed. I spoke to >> Serguei about those this afternoon. Basically the >> convertSignatureToClassname() function needs to be fixed to handle >> hidden classes. Without the fix classname filtering will have >> problems if the filter contains a pattern with a '/' to filter on >> hidden classes. Also CLASS_UNLOAD events will not properly convert >> hidden class names. We also need tests for these cases. I think these >> are all things that can be addressed later. >> > > Good catch.? I have created a subtask under JDK-8230502: > ?? https://bugs.openjdk.java.net/browse/JDK-8230502 Yes, it is good catch. Thank you for filing the subtask. We discussed this with Chris. This was expected to be found with new test coverage and fixed in the JDI chunk of work which we have decided to separate from JEP 371. Thanks, Serguei >> I still need to look over the JVMTI tests. >> > > Thanks > Mandy >> thanks, >> >> Chris >> >> On 3/26/20 4:57 PM, Mandy Chung wrote: >>> Please review the implementation of JEP 371: Hidden Classes. The >>> main changes are in core-libs and hotspot runtime area. Small >>> changes are made in javac, VM compiler (intrinsification of >>> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed >>> and is in the finalized state (see specdiff and javadoc below for >>> reference). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >>> >>> >>> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >>> point >>> of view, a hidden class is a normal class except the following: >>> >>> - A hidden class has no initiating class loader and is not >>> registered in any dictionary. >>> - A hidden class has a name containing an illegal character >>> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >>> returns "Lp/Foo.0x1234;". >>> - A hidden class is not modifiable, i.e. cannot be redefined or >>> retransformed. JVM TI IsModifableClass returns false on a hidden. >>> - Final fields in a hidden class is "final".? The value of final >>> fields cannot be overriden via reflection. setAccessible(true) can >>> still be called on reflected objects representing final fields in a >>> hidden class and its access check will be suppressed but only have >>> read-access (i.e. can do Field::getXXX but not setXXX). >>> >>> Brief summary of this patch: >>> >>> 1. A new Lookup::defineHiddenClass method is the API to create a >>> hidden class. >>> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >>> option that >>> ?? can be specified when creating a hidden class. >>> 3. A new Class::isHiddenClass method tests if a class is a hidden >>> class. >>> 4. Field::setXXX method will throw IAE on a final field of a hidden >>> class >>> ?? regardless of the value of the accessible flag. >>> 5. JVM_LookupDefineClass is the new JVM entry point for >>> Lookup::defineClass >>> ?? and defineHiddenClass to create a class from the given bytes. >>> 6. ClassLoaderData implementation is not changed.? There is one >>> primary CLD >>> ?? that holds the classes strongly referenced by its defining >>> loader.? There >>> ?? can be zero or more additional CLDs - one per weak class. >>> 7. Nest host determination is updated per revised JVMS 5.4.4. Access >>> control >>> ?? check no longer throws LinkageError but instead it will throw IAE >>> with >>> ?? a clear message if a class fails to resolve/validate the nest >>> host declared >>> ?? in NestHost/NestMembers attribute. >>> 8. JFR, jcmd, JDI are updated to support hidden classes. >>> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >>> ?? and generate a bridge method to desuger a method reference to a >>> protected >>> ?? method in its supertype in a different package >>> >>> This patch also updates StringConcatFactory, LambdaMetaFactory, and >>> LambdaForms >>> to use hidden classes.? The webrev includes changes in nashorn to >>> hidden class >>> and I will update the webrev if JEP 372 removes it any time soon. >>> >>> We uncovered a bug in Lookup::defineClass spec throws LinkageError >>> and intends >>> to have the newly created class linked.? However, the implementation >>> in 14 >>> does not link the class.? A separate CSR [2] proposes to update the >>> implementation to match the spec.? This patch fixes the implementation. >>> >>> The spec update on JVM TI, JDI and Instrumentation will be done as >>> a separate RFE [3].? This patch includes new tests for JVM TI and >>> java.instrument that validates how the existing APIs work for hidden >>> classes. >>> >>> javadoc/specdiff >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >>> >>> >>> JVMS 5.4.4 change: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >>> >>> >>> CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8238359 >>> >>> Thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 >> >> > From amaembo at gmail.com Mon Mar 30 06:02:00 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 30 Mar 2020 13:02:00 +0700 Subject: [PING] RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: <89556c4d-c01c-d9d7-d773-a03d583579f4@oracle.com> References: <87r1xhsayk.fsf@mid.deneb.enyo.de> <89556c4d-c01c-d9d7-d773-a03d583579f4@oracle.com> Message-ID: Ok, I will remove the periods. They are also absent in the corresponding methods in HashMap. On Mon, Mar 30, 2020 at 4:33 AM Roger Riggs wrote: > > Hi, > > Usually the @throws, @param, @return, etc clauses are not complete > sentences. > Only complete sentences need a period. > And most of OpenJDK omits them. > > $.02, Roger > > On 3/29/20 2:22 PM, Thomas St?fe wrote: > > On Sun 29. Mar 2020 at 18:48, Martin Buchholz wrote: > > > >> I'm fine with the latest version > >> > >> On Sun, Mar 29, 2020 at 1:29 AM Tagir Valeev wrote: > >> > >>>> At various places, the "@throws ConcurrentModificationException" > >>> javadoc: > >>>> 619 * @throws ConcurrentModificationException if it is detected > >>> that the > >>>> 620 * mapping function modified this map > >>>> > >>>> is missing the period. > >>> Done. > >>> > >> Sigh ... my own consistent practice has been to *not* put periods at the > >> end of @throws clauses, but obviously other maintainers ended up elsewhere. > >> > > Oops sorry. If it is important for you, I can live without the period... > > > From Alan.Bateman at oracle.com Mon Mar 30 08:37:16 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Mar 2020 09:37:16 +0100 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> Message-ID: <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> On 30/03/2020 03:41, linzang(??) wrote: > Dear All, > May I ask your help to reivew this tiny patch? Thanks. > > > > BRs, > Lin > > From: "linzang(??)" > Date: Thursday, March 26, 2020 at 3:13 PM > To: "core-libs-dev at openjdk.java.net" > Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set > > Dear All, > May I ask your help to review this tiny fix? > Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 > Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ > Thanks! > Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? -Alan From serguei.spitsyn at oracle.com Mon Mar 30 09:30:54 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 30 Mar 2020 02:30:54 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: Hi Mandy, I have just one comment so far. http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03/src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp.frames.html ?356?? void add_classes(LoadedClassInfo* first_class, int num_classes, bool has_class_mirror_holder) { ?357???? LoadedClassInfo** p_list_to_add_to; ?358???? bool is_hidden = first_class->_klass->is_hidden(); ?359???? if (has_class_mirror_holder) { ?360?????? p_list_to_add_to = is_hidden ? &_hidden_weak_classes : &_anon_classes; ?361???? } else { ?362?????? p_list_to_add_to = &_classes; ?363???? } ?364???? // Search tail. ?365???? while ((*p_list_to_add_to) != NULL) { ?366?????? p_list_to_add_to = &(*p_list_to_add_to)->_next; ?367???? } ?368???? *p_list_to_add_to = first_class; ?369???? if (has_class_mirror_holder) { ?370?????? if (is_hidden) { ?371???????? _num_hidden_weak_classes += num_classes; ?372?????? } else { ?373???????? _num_anon_classes += num_classes; ?374?????? } ?375???? } else { ?376?????? _num_classes += num_classes; ?377???? } ?378?? } ?Q1: I'm just curious, what happens if a cld has arrays of hidden classes? ???? Is the bottom_klass always expected to be the first? Thanks, Serguei On 3/26/20 16:57, Mandy Chung wrote: > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area.? Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > > Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point > of view, a hidden class is a normal class except the following: > > - A hidden class has no initiating class loader and is not registered > in any dictionary. > - A hidden class has a name containing an illegal character > `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` > returns "Lp/Foo.0x1234;". > - A hidden class is not modifiable, i.e. cannot be redefined or > retransformed. JVM TI IsModifableClass returns false on a hidden. > - Final fields in a hidden class is "final".? The value of final > fields cannot be overriden via reflection.? setAccessible(true) can > still be called on reflected objects representing final fields in a > hidden class and its access check will be suppressed but only have > read-access (i.e. can do Field::getXXX but not setXXX). > > Brief summary of this patch: > > 1. A new Lookup::defineHiddenClass method is the API to create a > hidden class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG > option that > ?? can be specified when creating a hidden class. > 3. A new Class::isHiddenClass method tests if a class is a hidden class. > 4. Field::setXXX method will throw IAE on a final field of a hidden class > ?? regardless of the value of the accessible flag. > 5. JVM_LookupDefineClass is the new JVM entry point for > Lookup::defineClass > ?? and defineHiddenClass to create a class from the given bytes. > 6. ClassLoaderData implementation is not changed.? There is one > primary CLD > ?? that holds the classes strongly referenced by its defining loader.? > There > ?? can be zero or more additional CLDs - one per weak class. > 7. Nest host determination is updated per revised JVMS 5.4.4. Access > control > ?? check no longer throws LinkageError but instead it will throw IAE with > ?? a clear message if a class fails to resolve/validate the nest host > declared > ?? in NestHost/NestMembers attribute. > 8. JFR, jcmd, JDI are updated to support hidden classes. > 9. update javac LambdaToMethod as lambda proxy starts using nestmates > ?? and generate a bridge method to desuger a method reference to a > protected > ?? method in its supertype in a different package > > This patch also updates StringConcatFactory, LambdaMetaFactory, and > LambdaForms > to use hidden classes.? The webrev includes changes in nashorn to > hidden class > and I will update the webrev if JEP 372 removes it any time soon. > > We uncovered a bug in Lookup::defineClass spec throws LinkageError and > intends > to have the newly created class linked.? However, the implementation > in 14 > does not link the class.? A separate CSR [2] proposes to update the > implementation to match the spec.? This patch fixes the implementation. > > The spec update on JVM TI, JDI and Instrumentation will be done as > a separate RFE [3].? This patch includes new tests for JVM TI and > java.instrument that validates how the existing APIs work for hidden > classes. > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From david.holmes at oracle.com Mon Mar 30 09:54:51 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 30 Mar 2020 19:54:51 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <546cf8e4-00e4-1d22-6402-6620b8d7b2db@oracle.com> Sorry to jump in on this but it caught my eye though I may be missing a larger context ... On 30/03/2020 7:30 pm, serguei.spitsyn at oracle.com wrote: > Hi Mandy, > > I have just one comment so far. > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03/src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp.frames.html > > > ?356?? void add_classes(LoadedClassInfo* first_class, int num_classes, > bool has_class_mirror_holder) { > ?357???? LoadedClassInfo** p_list_to_add_to; > ?358???? bool is_hidden = first_class->_klass->is_hidden(); > ?359???? if (has_class_mirror_holder) { > ?360?????? p_list_to_add_to = is_hidden ? &_hidden_weak_classes : > &_anon_classes; > ?361???? } else { > ?362?????? p_list_to_add_to = &_classes; > ?363???? } > ?364???? // Search tail. > ?365???? while ((*p_list_to_add_to) != NULL) { > ?366?????? p_list_to_add_to = &(*p_list_to_add_to)->_next; > ?367???? } > ?368???? *p_list_to_add_to = first_class; > ?369???? if (has_class_mirror_holder) { > ?370?????? if (is_hidden) { > ?371???????? _num_hidden_weak_classes += num_classes; Why does hidden imply weak here? David ----- > ?372?????? } else { > ?373???????? _num_anon_classes += num_classes; > ?374?????? } > ?375???? } else { > ?376?????? _num_classes += num_classes; > ?377???? } > ?378?? } > > ?Q1: I'm just curious, what happens if a cld has arrays of hidden classes? > ???? Is the bottom_klass always expected to be the first? > > > Thanks, > Serguei > > > On 3/26/20 16:57, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area.? Small changes are >> made in javac, VM compiler (intrinsification of Class::isHiddenClass), >> JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized >> state (see specdiff and javadoc below for reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point >> of view, a hidden class is a normal class except the following: >> >> - A hidden class has no initiating class loader and is not registered >> in any dictionary. >> - A hidden class has a name containing an illegal character >> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >> returns "Lp/Foo.0x1234;". >> - A hidden class is not modifiable, i.e. cannot be redefined or >> retransformed. JVM TI IsModifableClass returns false on a hidden. >> - Final fields in a hidden class is "final".? The value of final >> fields cannot be overriden via reflection.? setAccessible(true) can >> still be called on reflected objects representing final fields in a >> hidden class and its access check will be suppressed but only have >> read-access (i.e. can do Field::getXXX but not setXXX). >> >> Brief summary of this patch: >> >> 1. A new Lookup::defineHiddenClass method is the API to create a >> hidden class. >> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >> option that >> ?? can be specified when creating a hidden class. >> 3. A new Class::isHiddenClass method tests if a class is a hidden class. >> 4. Field::setXXX method will throw IAE on a final field of a hidden class >> ?? regardless of the value of the accessible flag. >> 5. JVM_LookupDefineClass is the new JVM entry point for >> Lookup::defineClass >> ?? and defineHiddenClass to create a class from the given bytes. >> 6. ClassLoaderData implementation is not changed.? There is one >> primary CLD >> ?? that holds the classes strongly referenced by its defining loader. >> There >> ?? can be zero or more additional CLDs - one per weak class. >> 7. Nest host determination is updated per revised JVMS 5.4.4. Access >> control >> ?? check no longer throws LinkageError but instead it will throw IAE with >> ?? a clear message if a class fails to resolve/validate the nest host >> declared >> ?? in NestHost/NestMembers attribute. >> 8. JFR, jcmd, JDI are updated to support hidden classes. >> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >> ?? and generate a bridge method to desuger a method reference to a >> protected >> ?? method in its supertype in a different package >> >> This patch also updates StringConcatFactory, LambdaMetaFactory, and >> LambdaForms >> to use hidden classes.? The webrev includes changes in nashorn to >> hidden class >> and I will update the webrev if JEP 372 removes it any time soon. >> >> We uncovered a bug in Lookup::defineClass spec throws LinkageError and >> intends >> to have the newly created class linked.? However, the implementation >> in 14 >> does not link the class.? A separate CSR [2] proposes to update the >> implementation to match the spec.? This patch fixes the implementation. >> >> The spec update on JVM TI, JDI and Instrumentation will be done as >> a separate RFE [3].? This patch includes new tests for JVM TI and >> java.instrument that validates how the existing APIs work for hidden >> classes. >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > From chris.hegarty at oracle.com Mon Mar 30 13:31:37 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Mar 2020 14:31:37 +0100 Subject: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact In-Reply-To: <6a4ede91-d116-7255-a5d2-482a9ea3176a@oracle.com> References: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> <6a4ede91-d116-7255-a5d2-482a9ea3176a@oracle.com> Message-ID: <021E7072-EDB7-4213-BF54-D5BDC24D7081@oracle.com> Joe, > On 29 Mar 2020, at 20:03, Joe Darcy wrote: > > Hi Stuart, > > Full webrev for review include including tests: > > http://cr.openjdk.java.net/~darcy/8241374.0/ > > and the companion CSR: > > https://bugs.openjdk.java.net/browse/JDK-8241805 Looks good to me. I do like the explanatory paragraph about the asymmetry in the range of two's complement integer values. An alternative, or addition, would be a link to JLS 4.2.1 - Integral Types and Values [1], which shows the asymmetry from a language perspective. -Chris. [1] https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.2.1 From coleen.phillimore at oracle.com Mon Mar 30 14:18:58 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 30 Mar 2020 10:18:58 -0400 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <546cf8e4-00e4-1d22-6402-6620b8d7b2db@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <546cf8e4-00e4-1d22-6402-6620b8d7b2db@oracle.com> Message-ID: <9cd71367-edc6-efc8-0a53-2e703ffbbfab@oracle.com> On 3/30/20 5:54 AM, David Holmes wrote: > Sorry to jump in on this but it caught my eye though I may be missing > a larger context ... > > On 30/03/2020 7:30 pm, serguei.spitsyn at oracle.com wrote: >> Hi Mandy, >> >> I have just one comment so far. >> >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03/src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp.frames.html >> >> >> ??356?? void add_classes(LoadedClassInfo* first_class, int >> num_classes, bool has_class_mirror_holder) { >> ??357???? LoadedClassInfo** p_list_to_add_to; >> ??358???? bool is_hidden = first_class->_klass->is_hidden(); >> ??359???? if (has_class_mirror_holder) { >> ??360?????? p_list_to_add_to = is_hidden ? &_hidden_weak_classes : >> &_anon_classes; >> ??361???? } else { >> ??362?????? p_list_to_add_to = &_classes; >> ??363???? } >> ??364???? // Search tail. >> ??365???? while ((*p_list_to_add_to) != NULL) { >> ??366?????? p_list_to_add_to = &(*p_list_to_add_to)->_next; >> ??367???? } >> ??368???? *p_list_to_add_to = first_class; >> ??369???? if (has_class_mirror_holder) { >> ??370?????? if (is_hidden) { >> ??371???????? _num_hidden_weak_classes += num_classes; > > Why does hidden imply weak here? has_class_mirror_holder() implies weak. Coleen > > David > ----- > >> ??372?????? } else { >> ??373???????? _num_anon_classes += num_classes; >> ??374?????? } >> ??375???? } else { >> ??376?????? _num_classes += num_classes; >> ??377???? } >> ??378?? } >> >> ??Q1: I'm just curious, what happens if a cld has arrays of hidden >> classes? >> ????? Is the bottom_klass always expected to be the first? >> >> >> Thanks, >> Serguei >> >> >> On 3/26/20 16:57, Mandy Chung wrote: >>> Please review the implementation of JEP 371: Hidden Classes. The >>> main changes are in core-libs and hotspot runtime area.? Small >>> changes are made in javac, VM compiler (intrinsification of >>> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed >>> and is in the finalized state (see specdiff and javadoc below for >>> reference). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >>> >>> >>> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >>> point >>> of view, a hidden class is a normal class except the following: >>> >>> - A hidden class has no initiating class loader and is not >>> registered in any dictionary. >>> - A hidden class has a name containing an illegal character >>> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >>> returns "Lp/Foo.0x1234;". >>> - A hidden class is not modifiable, i.e. cannot be redefined or >>> retransformed. JVM TI IsModifableClass returns false on a hidden. >>> - Final fields in a hidden class is "final".? The value of final >>> fields cannot be overriden via reflection. setAccessible(true) can >>> still be called on reflected objects representing final fields in a >>> hidden class and its access check will be suppressed but only have >>> read-access (i.e. can do Field::getXXX but not setXXX). >>> >>> Brief summary of this patch: >>> >>> 1. A new Lookup::defineHiddenClass method is the API to create a >>> hidden class. >>> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >>> option that >>> ?? can be specified when creating a hidden class. >>> 3. A new Class::isHiddenClass method tests if a class is a hidden >>> class. >>> 4. Field::setXXX method will throw IAE on a final field of a hidden >>> class >>> ?? regardless of the value of the accessible flag. >>> 5. JVM_LookupDefineClass is the new JVM entry point for >>> Lookup::defineClass >>> ?? and defineHiddenClass to create a class from the given bytes. >>> 6. ClassLoaderData implementation is not changed.? There is one >>> primary CLD >>> ?? that holds the classes strongly referenced by its defining >>> loader. There >>> ?? can be zero or more additional CLDs - one per weak class. >>> 7. Nest host determination is updated per revised JVMS 5.4.4. Access >>> control >>> ?? check no longer throws LinkageError but instead it will throw IAE >>> with >>> ?? a clear message if a class fails to resolve/validate the nest >>> host declared >>> ?? in NestHost/NestMembers attribute. >>> 8. JFR, jcmd, JDI are updated to support hidden classes. >>> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >>> ?? and generate a bridge method to desuger a method reference to a >>> protected >>> ?? method in its supertype in a different package >>> >>> This patch also updates StringConcatFactory, LambdaMetaFactory, and >>> LambdaForms >>> to use hidden classes.? The webrev includes changes in nashorn to >>> hidden class >>> and I will update the webrev if JEP 372 removes it any time soon. >>> >>> We uncovered a bug in Lookup::defineClass spec throws LinkageError >>> and intends >>> to have the newly created class linked.? However, the implementation >>> in 14 >>> does not link the class.? A separate CSR [2] proposes to update the >>> implementation to match the spec.? This patch fixes the implementation. >>> >>> The spec update on JVM TI, JDI and Instrumentation will be done as >>> a separate RFE [3].? This patch includes new tests for JVM TI and >>> java.instrument that validates how the existing APIs work for hidden >>> classes. >>> >>> javadoc/specdiff >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >>> >>> >>> JVMS 5.4.4 change: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >>> >>> >>> CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8238359 >>> >>> Thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 >> From serguei.spitsyn at oracle.com Mon Mar 30 16:19:19 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 30 Mar 2020 09:19:19 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <50b1658d-2195-53af-ea0b-e13842e00496@oracle.com> On 3/30/20 02:30, serguei.spitsyn at oracle.com wrote: > Hi Mandy, > > I have just one comment so far. > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03/src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp.frames.html > > > ?356?? void add_classes(LoadedClassInfo* first_class, int num_classes, > bool has_class_mirror_holder) { > ?357???? LoadedClassInfo** p_list_to_add_to; > ?358???? bool is_hidden = first_class->_klass->is_hidden(); > ?359???? if (has_class_mirror_holder) { > ?360?????? p_list_to_add_to = is_hidden ? &_hidden_weak_classes : > &_anon_classes; > ?361???? } else { > ?362?????? p_list_to_add_to = &_classes; > ?363???? } > ?364???? // Search tail. > ?365???? while ((*p_list_to_add_to) != NULL) { > ?366?????? p_list_to_add_to = &(*p_list_to_add_to)->_next; > ?367???? } > ?368???? *p_list_to_add_to = first_class; > ?369???? if (has_class_mirror_holder) { > ?370?????? if (is_hidden) { > ?371???????? _num_hidden_weak_classes += num_classes; > ?372?????? } else { > ?373???????? _num_anon_classes += num_classes; > ?374?????? } > ?375???? } else { > ?376?????? _num_classes += num_classes; > ?377???? } > ?378?? } > > ?Q1: I'm just curious, what happens if a cld has arrays of hidden > classes? > ???? Is the bottom_klass always expected to be the first? Please, skip it. I've got the answer. The array classes were not included into the LoadedClassInfo* by the classes_do. Thanks, Serguei > > Thanks, > Serguei > > > On 3/26/20 16:57, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area.? Small changes are >> made in javac, VM compiler (intrinsification of >> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed >> and is in the finalized state (see specdiff and javadoc below for >> reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >> point >> of view, a hidden class is a normal class except the following: >> >> - A hidden class has no initiating class loader and is not registered >> in any dictionary. >> - A hidden class has a name containing an illegal character >> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >> returns "Lp/Foo.0x1234;". >> - A hidden class is not modifiable, i.e. cannot be redefined or >> retransformed. JVM TI IsModifableClass returns false on a hidden. >> - Final fields in a hidden class is "final".? The value of final >> fields cannot be overriden via reflection.? setAccessible(true) can >> still be called on reflected objects representing final fields in a >> hidden class and its access check will be suppressed but only have >> read-access (i.e. can do Field::getXXX but not setXXX). >> >> Brief summary of this patch: >> >> 1. A new Lookup::defineHiddenClass method is the API to create a >> hidden class. >> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >> option that >> ?? can be specified when creating a hidden class. >> 3. A new Class::isHiddenClass method tests if a class is a hidden class. >> 4. Field::setXXX method will throw IAE on a final field of a hidden >> class >> ?? regardless of the value of the accessible flag. >> 5. JVM_LookupDefineClass is the new JVM entry point for >> Lookup::defineClass >> ?? and defineHiddenClass to create a class from the given bytes. >> 6. ClassLoaderData implementation is not changed.? There is one >> primary CLD >> ?? that holds the classes strongly referenced by its defining >> loader.? There >> ?? can be zero or more additional CLDs - one per weak class. >> 7. Nest host determination is updated per revised JVMS 5.4.4. Access >> control >> ?? check no longer throws LinkageError but instead it will throw IAE >> with >> ?? a clear message if a class fails to resolve/validate the nest host >> declared >> ?? in NestHost/NestMembers attribute. >> 8. JFR, jcmd, JDI are updated to support hidden classes. >> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >> ?? and generate a bridge method to desuger a method reference to a >> protected >> ?? method in its supertype in a different package >> >> This patch also updates StringConcatFactory, LambdaMetaFactory, and >> LambdaForms >> to use hidden classes.? The webrev includes changes in nashorn to >> hidden class >> and I will update the webrev if JEP 372 removes it any time soon. >> >> We uncovered a bug in Lookup::defineClass spec throws LinkageError >> and intends >> to have the newly created class linked.? However, the implementation >> in 14 >> does not link the class.? A separate CSR [2] proposes to update the >> implementation to match the spec.? This patch fixes the implementation. >> >> The spec update on JVM TI, JDI and Instrumentation will be done as >> a separate RFE [3].? This patch includes new tests for JVM TI and >> java.instrument that validates how the existing APIs work for hidden >> classes. >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > From brian.burkhalter at oracle.com Mon Mar 30 16:29:16 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 30 Mar 2020 09:29:16 -0700 Subject: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact In-Reply-To: <021E7072-EDB7-4213-BF54-D5BDC24D7081@oracle.com> References: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> <6a4ede91-d116-7255-a5d2-482a9ea3176a@oracle.com> <021E7072-EDB7-4213-BF54-D5BDC24D7081@oracle.com> Message-ID: Hi Joe, > On Mar 30, 2020, at 6:31 AM, Chris Hegarty wrote: > >> Full webrev for review include including tests: >> >> http://cr.openjdk.java.net/~darcy/8241374.0/ >> >> and the companion CSR: >> >> https://bugs.openjdk.java.net/browse/JDK-8241805 > > Looks good to me. Likewise. > I do like the explanatory paragraph about the asymmetry in the range of two's complement integer values. An alternative, or addition, would be a link to JLS 4.2.1 - Integral Types and Values [1], which shows the asymmetry from a language perspective. I also like this suggestion. Brian > -Chris. > > [1] https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.2.1 From joe.darcy at oracle.com Mon Mar 30 16:31:53 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 30 Mar 2020 09:31:53 -0700 Subject: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact In-Reply-To: References: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> <6a4ede91-d116-7255-a5d2-482a9ea3176a@oracle.com> <021E7072-EDB7-4213-BF54-D5BDC24D7081@oracle.com> Message-ID: Hi Brian and Chris, I was considering adding such as JLS link myself; I'll work one in and post a revised webrev. Thanks, -Joe On 3/30/2020 9:29 AM, Brian Burkhalter wrote: > Hi Joe, > >> On Mar 30, 2020, at 6:31 AM, Chris Hegarty > > wrote: >> >>> Full webrev for review include including tests: >>> >>> http://cr.openjdk.java.net/~darcy/8241374.0/ >>> >>> and the companion CSR: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8241805 >> >> Looks good to me. > > Likewise. > >> I do like the explanatory paragraph about the asymmetry in the range >> of two's complement integer values. An alternative, or addition, >> would be a link to JLS 4.2.1 - Integral Types and Values [1], which >> shows the asymmetry from a language perspective. > > I also like this suggestion. > > Brian > >> -Chris. >> >> [1]https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.2.1 > From andy.herrick at oracle.com Mon Mar 30 17:19:25 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 30 Mar 2020 13:19:25 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> Message-ID: <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> revised with minor fixes as per below - webrev at [3] [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ /Andy On 3/28/2020 9:43 AM, Andy Herrick wrote: > > On 3/27/2020 5:18 PM, Alexander Matveev wrote: >> Hi Andy, >> >> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >> >> Line 819,857,902 - Looks like temp debug log message. Remove it or >> align with rest of code. > I will fix this. >> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >> >> Line 70 - Capital F. > and this >> >> Since we added "--timestamp" and? "--options runtime" to codesign, >> will it work with older Xcode and macOS we planning to support? > not sure - may need some discussion of what we support and possible > conditional code here. >> >> Do we need any adjustments to signing tests we have? > > The existing tests pass, but this is not unexpected (and really means > nothing) since the signing tests are all skipped unless specific test > certs are installed on target machine. > > We need further discussion how one is expected to provision a machine > to run these tests. > > /Andy > >> >> Otherwise looks fine. >> >> Thanks, >> Alexander >> >> On 3/27/20 12:35 PM, Andy Herrick wrote: >>> Please review the fix to issue [1] at [2]. >>> >>> This change enables notarization on Mac for dmg images and app-image >>> zip files. >>> >>> /Andy >>> >>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>> >>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>> >> From joe.darcy at oracle.com Mon Mar 30 17:53:54 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 30 Mar 2020 10:53:54 -0700 Subject: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact In-Reply-To: References: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> <6a4ede91-d116-7255-a5d2-482a9ea3176a@oracle.com> <021E7072-EDB7-4213-BF54-D5BDC24D7081@oracle.com> Message-ID: <08db6fb1-7211-f6d9-55bf-ac56604a1e00@oracle.com> Hello, Updated webrev at: ??? http://cr.openjdk.java.net/~darcy/8241374.1/ One of the four pieces of the update to discuss below. A few comments, I added links from the abs methods to its sibling absExact method along with an additional note on referring the differing absExact behavior on a MIN_VALUE argument. I'll reflow the paragraphs and update the copyright year before pushing. Link to the relevant JLS section included in the absExact javadoc. --- old/src/java.base/share/classes/java/lang/Math.java 2020-03-30 10:28:41.314472163 -0700 +++ new/src/java.base/share/classes/java/lang/Math.java 2020-03-30 10:28:40.930472163 -0700 @@ -1359,9 +1359,12 @@ ????? * {@link Integer#MIN_VALUE}, the most negative representable ????? * {@code int} value, the result is that same value, which is ????? * negative. +???? * In contrast, the {@link Math#absExact(int)} method throws an +???? * {@code ArithmeticException} for this value. ????? * ????? * @param?? a?? the argument whose absolute value is to be determined ????? * @return? the absolute value of the argument. +???? * @see Math#absExact(int) ????? */ ???? @HotSpotIntrinsicCandidate ???? public static int abs(int a) { @@ -1369,6 +1372,32 @@ ???? } ???? /** +???? * Returns the mathematical absolute value of an {@code int} value +???? * if it is exactly representable as an {@code int}, throwing +???? * {@code ArithmeticException} if the result overflows the +???? * positive {@code int} range. +???? * +???? *

        Since the range of two's complement integers is asymmetric +???? * with one additional negative value (JLS {@jls 4.2.1}), the +???? * mathematical absolute value of {@link Integer#MIN_VALUE} +???? * overflows the positive {@code int} range, so an exception is +???? * thrown for that argument. +???? * +???? * @param? a? the argument whose absolute value is to be determined +???? * @return the absolute value of the argument, unless overflow occurs +???? * @throws ArithmeticException if the argument is {@link Integer#MIN_VALUE} +???? * @see Math#abs(int) +???? * @since 15 +???? */ +??? public static int absExact(int a) { +??????? if (a == Integer.MIN_VALUE) +??????????? throw new ArithmeticException( +??????????????? "Overflow to represent absolute value of Integer.MIN_VALUE"); +??????? else +??????????? return abs(a); +??? } For the StrictMath methods, I include links to the Math equivalent, as the other fooExact StrictMath methods do. Thanks, -Joe On 3/30/2020 9:31 AM, Joe Darcy wrote: > > Hi Brian and Chris, > > I was considering adding such as JLS link myself; I'll work one in and > post a revised webrev. > > Thanks, > > -Joe > > On 3/30/2020 9:29 AM, Brian Burkhalter wrote: >> Hi Joe, >> >>> On Mar 30, 2020, at 6:31 AM, Chris Hegarty >> > wrote: >>> >>>> Full webrev for review include including tests: >>>> >>>> http://cr.openjdk.java.net/~darcy/8241374.0/ >>>> >>>> and the companion CSR: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8241805 >>> >>> Looks good to me. >> >> Likewise. >> >>> I do like the explanatory paragraph about the asymmetry in the range >>> of two's complement integer values. An alternative, or addition, >>> would be a link to JLS 4.2.1 - Integral Types and Values [1], which >>> shows the asymmetry from a language perspective. >> >> I also like this suggestion. >> >> Brian >> >>> -Chris. >>> >>> [1]https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.2.1 >> From huizhe.wang at oracle.com Mon Mar 30 18:02:37 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 30 Mar 2020 11:02:37 -0700 Subject: RFR [15/java.xml] 8238183: SAX2StAXStreamWriter cannot deal with comments prior to the root element Message-ID: Hi, Please review a fix for the StAXResult impl. The issue was that it output comment prior to the declaration, resulting in an invalid XML document. The patch focuses on fixing this issue, but it does not cover other issues the StAXResult impl may have (e.g. JDK-8241711). JBS: https://bugs.openjdk.java.net/browse/JDK-8238183 webrev: http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev/ Thanks, Joe From henry.jen at oracle.com Mon Mar 30 18:08:43 2020 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 30 Mar 2020 11:08:43 -0700 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> Message-ID: Based on my understanding to gethrtime(), the main benefit is not to be affected by settimeofday or adjtime. I think it is probably better to use clock_gettime(CLOCK_MONOTONIC_RAW, ts); which I checked seems to be available on both Linux and Mac. Haven?t test it though. Cheers, Henry > On Mar 30, 2020, at 1:37 AM, Alan Bateman wrote: > > On 30/03/2020 03:41, linzang(??) wrote: >> Dear All, >> May I ask your help to reivew this tiny patch? Thanks. >> >> >> >> BRs, >> Lin >> >> From: "linzang(??)" >> Date: Thursday, March 26, 2020 at 3:13 PM >> To: "core-libs-dev at openjdk.java.net" >> Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set >> >> Dear All, >> May I ask your help to review this tiny fix? >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 >> Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ >> Thanks! >> > Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? > > -Alan From brian.burkhalter at oracle.com Mon Mar 30 18:17:37 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 30 Mar 2020 11:17:37 -0700 Subject: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact In-Reply-To: <08db6fb1-7211-f6d9-55bf-ac56604a1e00@oracle.com> References: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> <6a4ede91-d116-7255-a5d2-482a9ea3176a@oracle.com> <021E7072-EDB7-4213-BF54-D5BDC24D7081@oracle.com> <08db6fb1-7211-f6d9-55bf-ac56604a1e00@oracle.com> Message-ID: +1 Brian > On Mar 30, 2020, at 10:53 AM, Joe Darcy wrote: > > Updated webrev at: > > http://cr.openjdk.java.net/~darcy/8241374.1/ > One of the four pieces of the update to discuss below. A few comments, I added links from the abs methods to its sibling absExact method along with an additional note on referring the differing absExact behavior on a MIN_VALUE argument. I'll reflow the paragraphs and update the copyright year before pushing. Link to the relevant JLS section included in the absExact javadoc. > > [?] > > For the StrictMath methods, I include links to the Math equivalent, as the other fooExact StrictMath methods do. > From naoto.sato at oracle.com Mon Mar 30 18:23:06 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 30 Mar 2020 11:23:06 -0700 Subject: RFR [15/java.xml] 8238183: SAX2StAXStreamWriter cannot deal with comments prior to the root element In-Reply-To: References: Message-ID: Hi Joe, Can writeStartDocument() be simplified by checking "docLocator instanceof Locator2"? This way it won't need to catch CCE and issue no-arg version. Otherwise looks good to me. Naoto On 3/30/20 11:02 AM, Joe Wang wrote: > Hi, > > Please review a fix for the StAXResult impl. The issue was that it > output comment prior to the declaration, resulting in an invalid XML > document. The patch focuses on fixing this issue, but it does not cover > other issues the StAXResult impl may have (e.g. JDK-8241711). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8238183 > webrev: http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev/ > > Thanks, > Joe > From chris.hegarty at oracle.com Mon Mar 30 18:49:01 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Mar 2020 19:49:01 +0100 Subject: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact In-Reply-To: <08db6fb1-7211-f6d9-55bf-ac56604a1e00@oracle.com> References: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> <6a4ede91-d116-7255-a5d2-482a9ea3176a@oracle.com> <021E7072-EDB7-4213-BF54-D5BDC24D7081@oracle.com> <08db6fb1-7211-f6d9-55bf-ac56604a1e00@oracle.com> Message-ID: <1CFCB558-2DFE-4E02-BAA9-A6FF208CCEC1@oracle.com> > On 30 Mar 2020, at 18:53, Joe Darcy wrote: > > Hello, > > Updated webrev at: > > http://cr.openjdk.java.net/~darcy/8241374.1/ LGTM. -Chris. From mandy.chung at oracle.com Mon Mar 30 19:13:57 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Mar 2020 12:13:57 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com> Message-ID: <528c7933-be32-9863-6cc5-92223a75bbee@oracle.com> This is the patch to keep the JDK 14 behavior if target release to 14 (thanks to Jan for helping making change in javac to get the tests working) http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/ Mandy On 3/27/20 9:29 AM, Mandy Chung wrote: > Hi Jan, > > Good point.? The javac change only applies to JDK 15 and later and the > lambda proxy class is not a nestmate when running on JDK 14 or earlier. > > I probably need the help from langtools team to fix this.? I'll give > it a try. > > Mandy From naoto.sato at oracle.com Mon Mar 30 21:31:22 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 30 Mar 2020 14:31:22 -0700 Subject: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes In-Reply-To: <6a4e59d2e0028d80da9655cb1f724697bd516461.camel@paratix.ch> References: <44EE1961-6729-4F96-8885-439FED393A81@oracle.com> <026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch> <10485888-3ac8-c967-0131-08fe52d2694d@oracle.com> <6a4e59d2e0028d80da9655cb1f724697bd516461.camel@paratix.ch> Message-ID: <1d249f65-8086-4806-ef91-d7ecdfcf15bc@oracle.com> Hi Philipp, Sorry for the delay. On 3/25/20 11:52 AM, Philipp Kunz wrote: > Hi Naoto, > > See another patch attached with Locale.ROOT for the BreakIterator. I > will be glad to hear of any feedback. I wonder how your change affects the performance, as it will do String.getBytes(UTF-8) per each character. I think this can definitely be improved by adding some fastpath, e.g., for ASCII. The usage of the BreakIterator is fine, though. > > There is another patch [1] around dealing with manifest attributes > during application launch. It certainly is related to 6202130 but feels > like a distinct set of changes with a slightly different concern. Any > opinion as how to proceed with that one? I am not quite sure which patch you are referring to, but I agree that creating an issue would not hurt. Naoto > > Regards, > Philipp > > > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-February/064720.html > > > On Mon, 2020-03-23 at 09:05 -0700, naoto.sato at oracle.com wrote: >> Hi Philipp, >> >> Right, Locale.ROOT is more appropriate here by definition, though the >> implementation is the same. >> >> Naoto >> >> On 3/21/20 5:19 AM, Philipp Kunz wrote: >>> Hi Naoto and everyone, >>> >>> There are almost as many occurrences of Locale.ROOT as Locale.US which >>> made me wonder which one is more appropriately locale-independent and >>> which is probably another topic and not actually relevant here because >>> BreakIterator.getCharacterInstance is locale-agnostic as far as I can tell. >>> >>> See attached patch with another attempt to fix bug 6202130. >>> >>> Regards, >>> Philipp >>> >>> >>> On Tue, 2020-03-10 at 10:45 -0700, >>> naoto.sato at oracle.com >>> >>> wrote: >>>> Hi Philipp, >>>> >>>> ..., so using BreakIterator (with >>>> Locale.US) is more preferred solution to me. >>>> >>>> Naoto >>> From huizhe.wang at oracle.com Mon Mar 30 21:56:23 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 30 Mar 2020 14:56:23 -0700 Subject: RFR [15/java.xml] 8238183: SAX2StAXStreamWriter cannot deal with comments prior to the root element In-Reply-To: References: Message-ID: <3f028029-46e4-26c2-4547-78a58eb89a2c@oracle.com> Hi Naoto, Thanks for the review! I refactored the code around getting the XML version and encoding from the locator to get rid of the CCE. The impls with EventWriter and StreamWriter share a base class. All three classes are therefore refactored. No material change to the EventWriter impl. Two fields, xmlVersion and encoding, are added since I expect they will be needed later when we work on fixing the declaration. Note that, as of the current impl, encoding is not referenced in the StreamWriter impl, which is part of the issue in transforming the declaration (JDK-8241711). Here's webrev version 2: http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev_02/ -Joe On 3/30/20 11:23 AM, naoto.sato at oracle.com wrote: > Hi Joe, > > Can writeStartDocument() be simplified by checking "docLocator > instanceof Locator2"? This way it won't need to catch CCE and issue > no-arg version. > > Otherwise looks good to me. > > Naoto > > On 3/30/20 11:02 AM, Joe Wang wrote: >> Hi, >> >> Please review a fix for the StAXResult impl. The issue was that it >> output comment prior to the declaration, resulting in an invalid XML >> document. The patch focuses on fixing this issue, but it does not >> cover other issues the StAXResult impl may have (e.g. JDK-8241711). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8238183 >> webrev: http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev/ >> >> Thanks, >> Joe >> From lance.andersen at oracle.com Mon Mar 30 22:03:18 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 30 Mar 2020 18:03:18 -0400 Subject: RFR [15/java.xml] 8238183: SAX2StAXStreamWriter cannot deal with comments prior to the root element In-Reply-To: <3f028029-46e4-26c2-4547-78a58eb89a2c@oracle.com> References: <3f028029-46e4-26c2-4547-78a58eb89a2c@oracle.com> Message-ID: HI Joe, This version looks OK Best Lance > On Mar 30, 2020, at 5:56 PM, Joe Wang wrote: > > Hi Naoto, > > Thanks for the review! > > I refactored the code around getting the XML version and encoding from the locator to get rid of the CCE. The impls with EventWriter and StreamWriter share a base class. All three classes are therefore refactored. No material change to the EventWriter impl. Two fields, xmlVersion and encoding, are added since I expect they will be needed later when we work on fixing the declaration. Note that, as of the current impl, encoding is not referenced in the StreamWriter impl, which is part of the issue in transforming the declaration (JDK-8241711). > > Here's webrev version 2: > http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev_02/ > > -Joe > > On 3/30/20 11:23 AM, naoto.sato at oracle.com wrote: >> Hi Joe, >> >> Can writeStartDocument() be simplified by checking "docLocator instanceof Locator2"? This way it won't need to catch CCE and issue no-arg version. >> >> Otherwise looks good to me. >> >> Naoto >> >> On 3/30/20 11:02 AM, Joe Wang wrote: >>> Hi, >>> >>> Please review a fix for the StAXResult impl. The issue was that it output comment prior to the declaration, resulting in an invalid XML document. The patch focuses on fixing this issue, but it does not cover other issues the StAXResult impl may have (e.g. JDK-8241711). >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238183 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev/ >>> >>> Thanks, >>> Joe >>> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Mon Mar 30 22:12:41 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 30 Mar 2020 15:12:41 -0700 Subject: RFR [15/java.xml] 8238183: SAX2StAXStreamWriter cannot deal with comments prior to the root element In-Reply-To: <3f028029-46e4-26c2-4547-78a58eb89a2c@oracle.com> References: <3f028029-46e4-26c2-4547-78a58eb89a2c@oracle.com> Message-ID: <5b485777-b133-e7c5-131a-d1852e6d25c7@oracle.com> Hi Joe, Much better and cleaner! One nit is that you could remove "docLocator != null &&" as instanceof checks null. Naoto On 3/30/20 2:56 PM, Joe Wang wrote: > Hi Naoto, > > Thanks for the review! > > I refactored the code around getting the XML version and encoding from > the locator to get rid of the CCE. The impls with EventWriter and > StreamWriter share a base class. All three classes are therefore > refactored. No material change to the EventWriter impl. Two fields, > xmlVersion and encoding, are added since I expect they will be needed > later when we work on fixing the declaration. Note that, as of the > current impl, encoding is not referenced in the StreamWriter impl, which > is part of the issue in transforming the declaration (JDK-8241711). > > Here's webrev version 2: > http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev_02/ > > -Joe > > On 3/30/20 11:23 AM, naoto.sato at oracle.com wrote: >> Hi Joe, >> >> Can writeStartDocument() be simplified by checking "docLocator >> instanceof Locator2"? This way it won't need to catch CCE and issue >> no-arg version. >> >> Otherwise looks good to me. >> >> Naoto >> >> On 3/30/20 11:02 AM, Joe Wang wrote: >>> Hi, >>> >>> Please review a fix for the StAXResult impl. The issue was that it >>> output comment prior to the declaration, resulting in an invalid XML >>> document. The patch focuses on fixing this issue, but it does not >>> cover other issues the StAXResult impl may have (e.g. JDK-8241711). >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238183 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev/ >>> >>> Thanks, >>> Joe >>> > From alexey.semenyuk at oracle.com Mon Mar 30 22:44:20 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 30 Mar 2020 18:44:20 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> Message-ID: Looks good. - Alexey On 3/30/2020 1:19 PM, Andy Herrick wrote: > revised with minor fixes as per below - webrev at [3] > > [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ > > /Andy > > On 3/28/2020 9:43 AM, Andy Herrick wrote: >> >> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>> Hi Andy, >>> >>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >>> >>> Line 819,857,902 - Looks like temp debug log message. Remove it or >>> align with rest of code. >> I will fix this. >>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >>> >>> Line 70 - Capital F. >> and this >>> >>> Since we added "--timestamp" and? "--options runtime" to codesign, >>> will it work with older Xcode and macOS we planning to support? >> not sure - may need some discussion of what we support and possible >> conditional code here. >>> >>> Do we need any adjustments to signing tests we have? >> >> The existing tests pass, but this is not unexpected (and really means >> nothing) since the signing tests are all skipped unless specific test >> certs are installed on target machine. >> >> We need further discussion how one is expected to provision a machine >> to run these tests. >> >> /Andy >> >>> >>> Otherwise looks fine. >>> >>> Thanks, >>> Alexander >>> >>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>> Please review the fix to issue [1] at [2]. >>>> >>>> This change enables notarization on Mac for dmg images and >>>> app-image zip files. >>>> >>>> /Andy >>>> >>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>> >>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>> >>> From huizhe.wang at oracle.com Mon Mar 30 22:44:28 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 30 Mar 2020 15:44:28 -0700 Subject: RFR [15/java.xml] 8238183: SAX2StAXStreamWriter cannot deal with comments prior to the root element In-Reply-To: <5b485777-b133-e7c5-131a-d1852e6d25c7@oracle.com> References: <3f028029-46e4-26c2-4547-78a58eb89a2c@oracle.com> <5b485777-b133-e7c5-131a-d1852e6d25c7@oracle.com> Message-ID: <9cc11dec-b00f-55cb-6996-95e2d19c2f08@oracle.com> On 3/30/20 3:12 PM, naoto.sato at oracle.com wrote: > Hi Joe, > > Much better and cleaner! One nit is that you could remove "docLocator > != null &&" as instanceof checks null. Indeed, null check is removed: http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev_03/ Thanks, Joe > > Naoto > > On 3/30/20 2:56 PM, Joe Wang wrote: >> Hi Naoto, >> >> Thanks for the review! >> >> I refactored the code around getting the XML version and encoding >> from the locator to get rid of the CCE. The impls with EventWriter >> and StreamWriter share a base class. All three classes are therefore >> refactored. No material change to the EventWriter impl. Two fields, >> xmlVersion and encoding, are added since I expect they will be needed >> later when we work on fixing the declaration. Note that, as of the >> current impl, encoding is not referenced in the StreamWriter impl, >> which is part of the issue in transforming the declaration >> (JDK-8241711). >> >> Here's webrev version 2: >> http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev_02/ >> >> -Joe >> >> On 3/30/20 11:23 AM, naoto.sato at oracle.com wrote: >>> Hi Joe, >>> >>> Can writeStartDocument() be simplified by checking "docLocator >>> instanceof Locator2"? This way it won't need to catch CCE and issue >>> no-arg version. >>> >>> Otherwise looks good to me. >>> >>> Naoto >>> >>> On 3/30/20 11:02 AM, Joe Wang wrote: >>>> Hi, >>>> >>>> Please review a fix for the StAXResult impl. The issue was that it >>>> output comment prior to the declaration, resulting in an invalid >>>> XML document. The patch focuses on fixing this issue, but it does >>>> not cover other issues the StAXResult impl may have (e.g. >>>> JDK-8241711). >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238183 >>>> webrev: http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev/ >>>> >>>> Thanks, >>>> Joe >>>> >> From naoto.sato at oracle.com Mon Mar 30 22:46:59 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 30 Mar 2020 15:46:59 -0700 Subject: RFR [15/java.xml] 8238183: SAX2StAXStreamWriter cannot deal with comments prior to the root element In-Reply-To: <9cc11dec-b00f-55cb-6996-95e2d19c2f08@oracle.com> References: <3f028029-46e4-26c2-4547-78a58eb89a2c@oracle.com> <5b485777-b133-e7c5-131a-d1852e6d25c7@oracle.com> <9cc11dec-b00f-55cb-6996-95e2d19c2f08@oracle.com> Message-ID: Looks good. Thanks for the update. Naoto On 3/30/20 3:44 PM, Joe Wang wrote: > > On 3/30/20 3:12 PM, naoto.sato at oracle.com wrote: >> Hi Joe, >> >> Much better and cleaner! One nit is that you could remove "docLocator >> != null &&" as instanceof checks null. > > Indeed, null check is removed: > http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev_03/ > > Thanks, > Joe > >> >> Naoto >> >> On 3/30/20 2:56 PM, Joe Wang wrote: >>> Hi Naoto, >>> >>> Thanks for the review! >>> >>> I refactored the code around getting the XML version and encoding >>> from the locator to get rid of the CCE. The impls with EventWriter >>> and StreamWriter share a base class. All three classes are therefore >>> refactored. No material change to the EventWriter impl. Two fields, >>> xmlVersion and encoding, are added since I expect they will be needed >>> later when we work on fixing the declaration. Note that, as of the >>> current impl, encoding is not referenced in the StreamWriter impl, >>> which is part of the issue in transforming the declaration >>> (JDK-8241711). >>> >>> Here's webrev version 2: >>> http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev_02/ >>> >>> -Joe >>> >>> On 3/30/20 11:23 AM, naoto.sato at oracle.com wrote: >>>> Hi Joe, >>>> >>>> Can writeStartDocument() be simplified by checking "docLocator >>>> instanceof Locator2"? This way it won't need to catch CCE and issue >>>> no-arg version. >>>> >>>> Otherwise looks good to me. >>>> >>>> Naoto >>>> >>>> On 3/30/20 11:02 AM, Joe Wang wrote: >>>>> Hi, >>>>> >>>>> Please review a fix for the StAXResult impl. The issue was that it >>>>> output comment prior to the declaration, resulting in an invalid >>>>> XML document. The patch focuses on fixing this issue, but it does >>>>> not cover other issues the StAXResult impl may have (e.g. >>>>> JDK-8241711). >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238183 >>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev/ >>>>> >>>>> Thanks, >>>>> Joe >>>>> >>> > From lance.andersen at oracle.com Mon Mar 30 22:49:11 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 30 Mar 2020 18:49:11 -0400 Subject: RFR [15/java.xml] 8238183: SAX2StAXStreamWriter cannot deal with comments prior to the root element In-Reply-To: <9cc11dec-b00f-55cb-6996-95e2d19c2f08@oracle.com> References: <3f028029-46e4-26c2-4547-78a58eb89a2c@oracle.com> <5b485777-b133-e7c5-131a-d1852e6d25c7@oracle.com> <9cc11dec-b00f-55cb-6996-95e2d19c2f08@oracle.com> Message-ID: <6A5AD7B9-B5B9-4F7E-A191-56FA504338A5@oracle.com> +1 Good catch Naoto > On Mar 30, 2020, at 6:44 PM, Joe Wang wrote: > > > On 3/30/20 3:12 PM, naoto.sato at oracle.com wrote: >> Hi Joe, >> >> Much better and cleaner! One nit is that you could remove "docLocator != null &&" as instanceof checks null. > > Indeed, null check is removed: > http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev_03/ > > Thanks, > Joe > >> >> Naoto >> >> On 3/30/20 2:56 PM, Joe Wang wrote: >>> Hi Naoto, >>> >>> Thanks for the review! >>> >>> I refactored the code around getting the XML version and encoding from the locator to get rid of the CCE. The impls with EventWriter and StreamWriter share a base class. All three classes are therefore refactored. No material change to the EventWriter impl. Two fields, xmlVersion and encoding, are added since I expect they will be needed later when we work on fixing the declaration. Note that, as of the current impl, encoding is not referenced in the StreamWriter impl, which is part of the issue in transforming the declaration (JDK-8241711). >>> >>> Here's webrev version 2: >>> http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev_02/ >>> >>> -Joe >>> >>> On 3/30/20 11:23 AM, naoto.sato at oracle.com wrote: >>>> Hi Joe, >>>> >>>> Can writeStartDocument() be simplified by checking "docLocator instanceof Locator2"? This way it won't need to catch CCE and issue no-arg version. >>>> >>>> Otherwise looks good to me. >>>> >>>> Naoto >>>> >>>> On 3/30/20 11:02 AM, Joe Wang wrote: >>>>> Hi, >>>>> >>>>> Please review a fix for the StAXResult impl. The issue was that it output comment prior to the declaration, resulting in an invalid XML document. The patch focuses on fixing this issue, but it does not cover other issues the StAXResult impl may have (e.g. JDK-8241711). >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238183 >>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk15/8238183/webrev/ >>>>> >>>>> Thanks, >>>>> Joe >>>>> >>> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From david.holmes at oracle.com Tue Mar 31 00:03:48 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Mar 2020 10:03:48 +1000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> Message-ID: <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> On 31/03/2020 4:08 am, Henry Jen wrote: > Based on my understanding to gethrtime(), the main benefit is not to be affected by settimeofday or adjtime. I think it is probably better to use > > clock_gettime(CLOCK_MONOTONIC_RAW, ts); > > which I checked seems to be available on both Linux and Mac. Haven?t test it though. Not guaranteed to be available - either clock_gettime function or that particular clock - at build time or runtime. We use a check in the build system to determine build-time availability for hotspot, and then use dl_lookup etc at runtime to determine if actually available. We should be able to get rid of this one day but we checked fairly recently and there were still some issues. gettimeofday is a lot better than returning 1. Otherwise call into the VM and use JVM_NanoTime. Cheers, David ----- > Cheers, > Henry > >> On Mar 30, 2020, at 1:37 AM, Alan Bateman wrote: >> >> On 30/03/2020 03:41, linzang(??) wrote: >>> Dear All, >>> May I ask your help to reivew this tiny patch? Thanks. >>> >>> >>> >>> BRs, >>> Lin >>> >>> From: "linzang(??)" >>> Date: Thursday, March 26, 2020 at 3:13 PM >>> To: "core-libs-dev at openjdk.java.net" >>> Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set >>> >>> Dear All, >>> May I ask your help to review this tiny fix? >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 >>> Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ >>> Thanks! >>> >> Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? >> >> -Alan > From linzang at tencent.com Tue Mar 31 02:39:21 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Tue, 31 Mar 2020 02:39:21 +0000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> Message-ID: <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> Hi David, Henry, Alan, Thanks a lot for your review. I have considered use clock_gettime() first, but I seached the code and found there is a marco SUPPORTS_CLOCK_MONOTONIC guard the usage of it. Which makes me think it may not be available under specific situation. So I choosed gettimeofday. Do you think the patch need to be refined to remove HAVE_GETHRTIME as Alan suggested? Thanks. BRs, Lin ?>On 2020/3/31, 8:05 AM, "David Holmes" wrote: > > On 31/03/2020 4:08 am, Henry Jen wrote: > > Based on my understanding to gethrtime(), the main benefit is not to be affected by settimeofday or adjtime. I think it is probably better to use > > > > clock_gettime(CLOCK_MONOTONIC_RAW, ts); > > > > which I checked seems to be available on both Linux and Mac. Haven?t test it though. > > Not guaranteed to be available - either clock_gettime function or that > particular clock - at build time or runtime. We use a check in the build > system to determine build-time availability for hotspot, and then use > dl_lookup etc at runtime to determine if actually available. We should > be able to get rid of this one day but we checked fairly recently and > there were still some issues. > gettimeofday is a lot better than returning 1. Otherwise call into the > VM and use JVM_NanoTime. > > Cheers, > David > ----- > > > Cheers, > > Henry > > > >> On Mar 30, 2020, at 1:37 AM, Alan Bateman wrote: > >> > >> On 30/03/2020 03:41, linzang(??) wrote: > >>> Dear All, > >>> May I ask your help to reivew this tiny patch? Thanks. > >>> > >>> > >>> > >>> BRs, > >>> Lin > >>> > >>> From: "linzang(??)" > >>> Date: Thursday, March 26, 2020 at 3:13 PM > >>> To: "core-libs-dev at openjdk.java.net" > >>> Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set > >>> > >>> Dear All, > >>> May I ask your help to review this tiny fix? > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 > >>> Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ > >>> Thanks! > >>> > >> Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris >and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? > >> > >> -Alan > > From amaembo at gmail.com Tue Mar 31 04:00:33 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 31 Mar 2020 11:00:33 +0700 Subject: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact In-Reply-To: <08db6fb1-7211-f6d9-55bf-ac56604a1e00@oracle.com> References: <8e299b9f-0a2c-874e-d914-8d627575a760@oracle.com> <6a4ede91-d116-7255-a5d2-482a9ea3176a@oracle.com> <021E7072-EDB7-4213-BF54-D5BDC24D7081@oracle.com> <08db6fb1-7211-f6d9-55bf-ac56604a1e00@oracle.com> Message-ID: Hello! Speaking about implementation, how about this? return (a < 0) ? negateExact(a) : a; This would require only one branch for positive numbers and also will utilize already intrinsified negateExact. The cost is a less verbose message ("integer overflow" or "long overflow"). However, when one sees the exception from absExact, its meaning becomes completely clear after reading the spec. With best regards, Tagir Valeev. On Tue, Mar 31, 2020 at 12:54 AM Joe Darcy wrote: > > Hello, > > Updated webrev at: > > http://cr.openjdk.java.net/~darcy/8241374.1/ > > One of the four pieces of the update to discuss below. A few comments, I > added links from the abs methods to its sibling absExact method along > with an additional note on referring the differing absExact behavior on > a MIN_VALUE argument. I'll reflow the paragraphs and update the > copyright year before pushing. Link to the relevant JLS section included > in the absExact javadoc. > > --- old/src/java.base/share/classes/java/lang/Math.java 2020-03-30 > 10:28:41.314472163 -0700 > +++ new/src/java.base/share/classes/java/lang/Math.java 2020-03-30 > 10:28:40.930472163 -0700 > @@ -1359,9 +1359,12 @@ > * {@link Integer#MIN_VALUE}, the most negative representable > * {@code int} value, the result is that same value, which is > * negative. > + * In contrast, the {@link Math#absExact(int)} method throws an > + * {@code ArithmeticException} for this value. > * > * @param a the argument whose absolute value is to be determined > * @return the absolute value of the argument. > + * @see Math#absExact(int) > */ > @HotSpotIntrinsicCandidate > public static int abs(int a) { > @@ -1369,6 +1372,32 @@ > } > > /** > + * Returns the mathematical absolute value of an {@code int} value > + * if it is exactly representable as an {@code int}, throwing > + * {@code ArithmeticException} if the result overflows the > + * positive {@code int} range. > + * > + *

        Since the range of two's complement integers is asymmetric > + * with one additional negative value (JLS {@jls 4.2.1}), the > + * mathematical absolute value of {@link Integer#MIN_VALUE} > + * overflows the positive {@code int} range, so an exception is > + * thrown for that argument. > + * > + * @param a the argument whose absolute value is to be determined > + * @return the absolute value of the argument, unless overflow occurs > + * @throws ArithmeticException if the argument is {@link > Integer#MIN_VALUE} > + * @see Math#abs(int) > + * @since 15 > + */ > + public static int absExact(int a) { > + if (a == Integer.MIN_VALUE) > + throw new ArithmeticException( > + "Overflow to represent absolute value of > Integer.MIN_VALUE"); > + else > + return abs(a); > + } > > For the StrictMath methods, I include links to the Math equivalent, as > the other fooExact StrictMath methods do. > > Thanks, > > -Joe > > > On 3/30/2020 9:31 AM, Joe Darcy wrote: > > > > Hi Brian and Chris, > > > > I was considering adding such as JLS link myself; I'll work one in and > > post a revised webrev. > > > > Thanks, > > > > -Joe > > > > On 3/30/2020 9:29 AM, Brian Burkhalter wrote: > >> Hi Joe, > >> > >>> On Mar 30, 2020, at 6:31 AM, Chris Hegarty >>> > wrote: > >>> > >>>> Full webrev for review include including tests: > >>>> > >>>> http://cr.openjdk.java.net/~darcy/8241374.0/ > >>>> > >>>> and the companion CSR: > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8241805 > >>> > >>> Looks good to me. > >> > >> Likewise. > >> > >>> I do like the explanatory paragraph about the asymmetry in the range > >>> of two's complement integer values. An alternative, or addition, > >>> would be a link to JLS 4.2.1 - Integral Types and Values [1], which > >>> shows the asymmetry from a language perspective. > >> > >> I also like this suggestion. > >> > >> Brian > >> > >>> -Chris. > >>> > >>> [1]https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.2.1 > >> From alexander.matveev at oracle.com Tue Mar 31 04:14:00 2020 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 30 Mar 2020 21:14:00 -0700 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> Message-ID: <5f2a90e3-442b-03b8-6f6b-e6122f5d979a@oracle.com> Hi Andy, Looks good. Thanks, Alexander On 3/30/20 3:44 PM, Alexey Semenyuk wrote: > Looks good. > > - Alexey > > On 3/30/2020 1:19 PM, Andy Herrick wrote: >> revised with minor fixes as per below - webrev at [3] >> >> [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ >> >> /Andy >> >> On 3/28/2020 9:43 AM, Andy Herrick wrote: >>> >>> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>>> Hi Andy, >>>> >>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >>>> >>>> Line 819,857,902 - Looks like temp debug log message. Remove it or >>>> align with rest of code. >>> I will fix this. >>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >>>> >>>> Line 70 - Capital F. >>> and this >>>> >>>> Since we added "--timestamp" and? "--options runtime" to codesign, >>>> will it work with older Xcode and macOS we planning to support? >>> not sure - may need some discussion of what we support and possible >>> conditional code here. >>>> >>>> Do we need any adjustments to signing tests we have? >>> >>> The existing tests pass, but this is not unexpected (and really >>> means nothing) since the signing tests are all skipped unless >>> specific test certs are installed on target machine. >>> >>> We need further discussion how one is expected to provision a >>> machine to run these tests. >>> >>> /Andy >>> >>>> >>>> Otherwise looks fine. >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>>> Please review the fix to issue [1] at [2]. >>>>> >>>>> This change enables notarization on Mac for dmg images and >>>>> app-image zip files. >>>>> >>>>> /Andy >>>>> >>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>>> >>>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>>> >>>> > From henry.jen at oracle.com Tue Mar 31 04:29:33 2020 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 30 Mar 2020 21:29:33 -0700 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> Message-ID: <6A8A5F2C-9D7B-4BC6-8627-5D40FDC11608@oracle.com> OK, I agree with David gettimeofday is an improvement than 1, so we can go ahead with the patch. Not sure if the caveat should be disclosed or not, I don?t think it?s important enough, just a known fact probably worth to leave a trace(perhaps a comment in code or the bug entry). As whether to change the ifdef to simply detect Solaris, I prefer just to leave it as is for two reasons: 1. It?s not broken, why change it? 2. I checked the code, it?s just a simply macro defined by the make file. Realtime Linux extension would have that function and special custom build can still use that, even though that probably is not happening. Cheers, Henry > On Mar 30, 2020, at 7:39 PM, linzang(??) wrote: > > Hi David, Henry, Alan, > Thanks a lot for your review. > I have considered use clock_gettime() first, but I seached the code and found there is a marco SUPPORTS_CLOCK_MONOTONIC guard the usage of it. Which makes me think it may not be available under specific situation. So I choosed gettimeofday. > Do you think the patch need to be refined to remove HAVE_GETHRTIME as Alan suggested? Thanks. > > BRs, > Lin > > ?>On 2020/3/31, 8:05 AM, "David Holmes" wrote: >> >> On 31/03/2020 4:08 am, Henry Jen wrote: >>> Based on my understanding to gethrtime(), the main benefit is not to be affected by settimeofday or adjtime. I think it is probably better to use >>> >>> clock_gettime(CLOCK_MONOTONIC_RAW, ts); >>> >>> which I checked seems to be available on both Linux and Mac. Haven?t test it though. >> >> Not guaranteed to be available - either clock_gettime function or that >> particular clock - at build time or runtime. We use a check in the build >> system to determine build-time availability for hotspot, and then use >> dl_lookup etc at runtime to determine if actually available. We should >> be able to get rid of this one day but we checked fairly recently and >> there were still some issues. > >> gettimeofday is a lot better than returning 1. Otherwise call into the >> VM and use JVM_NanoTime. >> >> Cheers, >> David >> ----- >> >>> Cheers, >>> Henry >>> >>>> On Mar 30, 2020, at 1:37 AM, Alan Bateman wrote: >>>> >>>> On 30/03/2020 03:41, linzang(??) wrote: >>>>> Dear All, >>>>> May I ask your help to reivew this tiny patch? Thanks. >>>>> >>>>> >>>>> >>>>> BRs, >>>>> Lin >>>>> >>>>> From: "linzang(??)" >>>>> Date: Thursday, March 26, 2020 at 3:13 PM >>>>> To: "core-libs-dev at openjdk.java.net" >>>>> Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set >>>>> >>>>> Dear All, >>>>> May I ask your help to review this tiny fix? >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 >>>>> Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ >>>>> Thanks! >>>>> >>>> Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris >and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? >>>> >>>> -Alan >>> > > > From vipinmv1 at in.ibm.com Tue Mar 31 07:02:26 2020 From: vipinmv1 at in.ibm.com (Vipin Mv1) Date: Tue, 31 Mar 2020 07:02:26 +0000 Subject: RFR 8015413 Reformat line in Class.privateGetPublicFields() to be more debugger-friendly Message-ID: Hi All, Please find the below changes for the issue https://bugs.openjdk.java.net/browse/JDK-8015413 diff -r 53568400fec3 src/java.base/share/classes/java/lang/Class.java --- a/src/java.base/share/classes/java/lang/Class.java Thu Mar 26 15:26:51 2020 +0000 +++ b/src/java.base/share/classes/java/lang/Class.java Mon Mar 30 17:31:04 2020 +0530 @@ -3163,7 +3163,8 @@ ReflectionData rd = reflectionData(); if (rd != null) { res = rd.publicFields; - if (res != null) return res; + if (res != null) + return res; } // Use a linked hash set to ensure order is preserved and Thanks & Regards Vipin MV From denghui.ddh at alibaba-inc.com Tue Mar 31 09:06:54 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 31 Mar 2020 17:06:54 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIzODY2NTogQWRkIEpGUiBldmVudCBmb3IgZGlyZWN0IG1lbW9yeSBzdGF0?= =?UTF-8?B?aXN0aWNz?= In-Reply-To: <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> <401741d6-cb99-d170-9a1f-a8793a8b1dd8@oracle.com>, <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com> Message-ID: <33bcb20a-f92e-4e59-847f-50d877eb3247.denghui.ddh@alibaba-inc.com> PING. @Erik Could you review it? Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2020?3?19?(???) 16:35 To:Alan Bateman ; Erik Gahlin Cc:hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi, On Mar 18, 2020, at 11:46 PM, Alan Bateman wrote: On 13/03/2020 14:54, Denghui Dong wrote: Good suggestion, moved. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.03/ This looks much better. What would you think about renaming the JFR event to "DirectBufferStatistics"? The concern I have with the proposed naming is that it will be really awkward to extend it to support mapped buffers. It?s ok for me. The implementation changes look okay, hopefully Erik will skim over them. One small suggestion for for ManagementFactoryHelper is that you can stream().collect(Collectors.toList()) to create the value for bufferPools. You could even change it to volatile so that getBufferMXBeans isn't a synchronized method. Make sense, updated. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.04/ @Erik, could you help review it? -Alan. Denghui Dong From Alan.Bateman at oracle.com Tue Mar 31 09:22:33 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Mar 2020 10:22:33 +0100 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> <401741d6-cb99-d170-9a1f-a8793a8b1dd8@oracle.com> <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com> Message-ID: On 19/03/2020 08:35, Denghui Dong wrote: > > Make sense, updated. > > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.04/ > Thanks for the updates, looks much better. A minor comment on ManagementFactoryHelper is that bufferPools doesn't have to initialized to null. That will avoid a volatile write. -Alan. From denghui.ddh at alibaba-inc.com Tue Mar 31 09:57:11 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 31 Mar 2020 17:57:11 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIzODY2NTogQWRkIEpGUiBldmVudCBmb3IgZGlyZWN0IG1lbW9yeSBzdGF0?= =?UTF-8?B?aXN0aWNz?= In-Reply-To: References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> <401741d6-cb99-d170-9a1f-a8793a8b1dd8@oracle.com> <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com>, Message-ID: <4cbc324a-7004-4845-94b4-28c4846da3c4.denghui.ddh@alibaba-inc.com> thanks for the review! updated, still in http://cr.openjdk.java.net/~ddong/8238665/webrev.04/ could you sponsor it if everything is okay? Thanks, Denghui ------------------------------------------------------------------ From:Alan Bateman Send Time:2020?3?31?(???) 17:22 To:???(??) ; Erik Gahlin Cc:hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics On 19/03/2020 08:35, Denghui Dong wrote: > > Make sense, updated. > > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.04/ > Thanks for the updates, looks much better. A minor comment on ManagementFactoryHelper is that bufferPools doesn't have to initialized to null. That will avoid a volatile write. -Alan. From chris.hegarty at oracle.com Tue Mar 31 10:40:35 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 31 Mar 2020 11:40:35 +0100 Subject: RFR [15] 8241921: Remove leftover diagnostic from test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java Message-ID: Remove leftover diagnostic that dumps generated class from test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java At one point it was useful to be able to inspect the generated bytecode using javap, but it was noticed recently for a different reason that the output file is always R1.class, which is clearly wrong. Anyway, this can simply be removed. --- a/test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java +++ b/test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java @@ -25,28 +25,26 @@ * @test * @summary Basic tests for prohibited magic serialPersistentFields * @library /test/lib * @modules java.base/jdk.internal.org.objectweb.asm * @compile --enable-preview -source ${jdk.version} SerialPersistentFieldsTest.java * @run testng/othervm --enable-preview SerialPersistentFieldsTest */ import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; -import java.io.FileOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.ObjectStreamClass; import java.io.ObjectStreamField; import java.io.Serializable; -import java.io.UncheckedIOException; import java.lang.reflect.Field; import java.lang.reflect.Modifier; import java.math.BigDecimal; import jdk.internal.org.objectweb.asm.ClassReader; import jdk.internal.org.objectweb.asm.ClassVisitor; import jdk.internal.org.objectweb.asm.ClassWriter; import jdk.internal.org.objectweb.asm.FieldVisitor; import jdk.internal.org.objectweb.asm.MethodVisitor; import jdk.internal.org.objectweb.asm.Type; import jdk.test.lib.ByteCodeLoader; @@ -222,27 +220,20 @@ return deserialize(serialize(obj)); } // -- machinery for augmenting a record class with prohibited serial field -- static byte[] addSerialPersistentFields(byte[] classBytes, ObjectStreamField[] spf) { ClassReader reader = new ClassReader(classBytes); ClassWriter writer = new ClassWriter(reader, COMPUTE_MAXS | COMPUTE_FRAMES); reader.accept(new SerialPersistentFieldsVisitor(writer, spf), 0); - try { - FileOutputStream fos = new FileOutputStream("R1.class"); - fos.write(writer.toByteArray()); - fos.close(); - } catch (IOException ioe) { - throw new UncheckedIOException(ioe); - } return writer.toByteArray(); } /** A visitor that adds a serialPersistentFields field, and assigns it in clinit. */ static final class SerialPersistentFieldsVisitor extends ClassVisitor { static final String FIELD_NAME = "serialPersistentFields"; static final String FIELD_DESC = "[Ljava/io/ObjectStreamField;"; final ObjectStreamField[] spf; String className; SerialPersistentFieldsVisitor(ClassVisitor cv, ObjectStreamField[] spf) { -Chris. From erik.gahlin at oracle.com Tue Mar 31 11:18:12 2020 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 31 Mar 2020 13:18:12 +0200 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: <33bcb20a-f92e-4e59-847f-50d877eb3247.denghui.ddh@alibaba-inc.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> <401741d6-cb99-d170-9a1f-a8793a8b1dd8@oracle.com> <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com> <33bcb20a-f92e-4e59-847f-50d877eb3247.denghui.ddh@alibaba-inc.com> Message-ID: <8D25EB0F-7456-4BE7-A1D0-CB733B150061@oracle.com> Hi Denghui, I think there should be one event type per pool, or there should be a text field specifying which pool it is. If we believe there will be many pools in the future, it may make sense for a field, otherwise I think an event type could be used. The benefit of one event type per pool is that there can be a description per pool and it also allows easy filtering and configuration. If there would be four pools, they could all derive from an abstract event class and only add @Label and @Description per event subclass. If there would be forty pools, it would be too much noise and a field would be better. Erik > On 31 Mar 2020, at 11:06, Denghui Dong wrote: > > PING. > > @Erik Could you review it? > > Denghui Dong > > > > ------------------------------------------------------------------ > From:???(??) > Send Time:2020?3?19?(???) 16:35 > To:Alan Bateman ; Erik Gahlin > Cc:hotspot-jfr-dev ; core-libs-dev > Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics > > Hi, > > On Mar 18, 2020, at 11:46 PM, Alan Bateman > wrote: > > > > On 13/03/2020 14:54, Denghui Dong wrote: > Good suggestion, moved. > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.03/ > This looks much better. > > What would you think about renaming the JFR event to "DirectBufferStatistics"? The concern I have with the proposed naming is that it will be really awkward to extend it to support mapped buffers. > > It?s ok for me. > > > The implementation changes look okay, hopefully Erik will skim over them. One small suggestion for for ManagementFactoryHelper is that you can stream().collect(Collectors.toList()) to create the value for bufferPools. You could even change it to volatile so that getBufferMXBeans isn't a synchronized method. > > > Make sense, updated. > > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.04/ > > @Erik, could you help review it? > > > -Alan. > > Denghui Dong From lance.andersen at oracle.com Tue Mar 31 11:59:59 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 31 Mar 2020 07:59:59 -0400 Subject: RFR [15] 8241921: Remove leftover diagnostic from test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java In-Reply-To: References: Message-ID: <42E98FE8-10BB-49CB-A097-9C13250352B1@oracle.com> +1 > On Mar 31, 2020, at 6:40 AM, Chris Hegarty wrote: > > Remove leftover diagnostic that dumps generated class from test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > > At one point it was useful to be able to inspect the generated bytecode using javap, but it was noticed recently for a different reason that the output file is always R1.class, which is clearly wrong. Anyway, this can simply be removed. > > --- a/test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > +++ b/test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > @@ -25,28 +25,26 @@ > * @test > * @summary Basic tests for prohibited magic serialPersistentFields > * @library /test/lib > * @modules java.base/jdk.internal.org.objectweb.asm > * @compile --enable-preview -source ${jdk.version} SerialPersistentFieldsTest.java > * @run testng/othervm --enable-preview SerialPersistentFieldsTest > */ > > import java.io.ByteArrayInputStream; > import java.io.ByteArrayOutputStream; > -import java.io.FileOutputStream; > import java.io.IOException; > import java.io.ObjectInputStream; > import java.io.ObjectOutputStream; > import java.io.ObjectStreamClass; > import java.io.ObjectStreamField; > import java.io.Serializable; > -import java.io.UncheckedIOException; > import java.lang.reflect.Field; > import java.lang.reflect.Modifier; > import java.math.BigDecimal; > import jdk.internal.org.objectweb.asm.ClassReader; > import jdk.internal.org.objectweb.asm.ClassVisitor; > import jdk.internal.org.objectweb.asm.ClassWriter; > import jdk.internal.org.objectweb.asm.FieldVisitor; > import jdk.internal.org.objectweb.asm.MethodVisitor; > import jdk.internal.org.objectweb.asm.Type; > import jdk.test.lib.ByteCodeLoader; > @@ -222,27 +220,20 @@ > return deserialize(serialize(obj)); > } > > // -- machinery for augmenting a record class with prohibited serial field -- > > static byte[] addSerialPersistentFields(byte[] classBytes, > ObjectStreamField[] spf) { > ClassReader reader = new ClassReader(classBytes); > ClassWriter writer = new ClassWriter(reader, COMPUTE_MAXS | COMPUTE_FRAMES); > reader.accept(new SerialPersistentFieldsVisitor(writer, spf), 0); > - try { > - FileOutputStream fos = new FileOutputStream("R1.class"); > - fos.write(writer.toByteArray()); > - fos.close(); > - } catch (IOException ioe) { > - throw new UncheckedIOException(ioe); > - } > return writer.toByteArray(); > } > > /** A visitor that adds a serialPersistentFields field, and assigns it in clinit. */ > static final class SerialPersistentFieldsVisitor extends ClassVisitor { > static final String FIELD_NAME = "serialPersistentFields"; > static final String FIELD_DESC = "[Ljava/io/ObjectStreamField;"; > final ObjectStreamField[] spf; > String className; > SerialPersistentFieldsVisitor(ClassVisitor cv, ObjectStreamField[] spf) { > > > -Chris. > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From christoph.langer at sap.com Tue Mar 31 14:56:44 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 31 Mar 2020 14:56:44 +0000 Subject: RFR (S): 8241947: Minor comment fixes for system property handling Message-ID: Hi, please review a small fix that updates two comments. The first one, in make/autoconf/spec.gmk.in, is probably quite old. It talks about handling of a property "vm.vendor" in VersionProps.java.template. However, there is no property "vm.vendor", it must rather be "java.vendor". I stumbled over that when looking at the change of JDK-4947890 (Minimize JNI upcalls in system-properties initialization). The second one is the code comment attached to "private static Properties props;" in java.lang.System. After JDK-8197927 (Allow the system property `java.vendor.version` to be undefined), "java.vendor.version" can be undefined, so this should be reflected in the comment. I also took the liberty to remove an unneeded import statement. Bug: https://bugs.openjdk.java.net/browse/JDK-8241947 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8241947.0/ Thanks Christoph From magnus.ihse.bursie at oracle.com Tue Mar 31 15:32:53 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 31 Mar 2020 17:32:53 +0200 Subject: RFR (S): 8241947: Minor comment fixes for system property handling In-Reply-To: References: Message-ID: <9a7ca419-23c2-41b2-639e-0467dc74784a@oracle.com> From a build perspective this looks fine. But it seems you are changing the interface for java.lang.System. Don't you need a CSR for that? Or is your claim that the interface was indeed changed by JDK-8197927, and it is a bug that the documentation was not updated to match this? /Magnus On 2020-03-31 16:56, Langer, Christoph wrote: > Hi, > > please review a small fix that updates two comments. > > The first one, in make/autoconf/spec.gmk.in, is probably quite old. It talks about handling of a property "vm.vendor" in VersionProps.java.template. However, there is no property "vm.vendor", it must rather be "java.vendor". I stumbled over that when looking at the change of JDK-4947890 (Minimize JNI upcalls in system-properties initialization). > > The second one is the code comment attached to "private static Properties props;" in java.lang.System. After JDK-8197927 (Allow the system property `java.vendor.version` to be undefined), "java.vendor.version" can be undefined, so this should be reflected in the comment. I also took the liberty to remove an unneeded import statement. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241947 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8241947.0/ > > Thanks > Christoph > From joe.darcy at oracle.com Tue Mar 31 15:49:03 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 31 Mar 2020 08:49:03 -0700 Subject: [15] RFR: 8214694: cleanup rawtypes warnings in open jndi tests In-Reply-To: <7850C8C2-6457-48F6-ADE4-A27B81F7D7B8@oracle.com> References: <29BE8612-A772-45AC-AEB3-55C5C3FBAED0@oracle.com> <7850C8C2-6457-48F6-ADE4-A27B81F7D7B8@oracle.com> Message-ID: <934baf9d-2eb4-3b38-2969-2268661a4be5@oracle.com> Hi Chris, Revised version looks better; thanks, -Joe On 3/27/2020 1:30 AM, Chris Yin wrote: > Hi, Joe > > Thank you for reviewing and comments. > > I agree that some part of the change could be as precise as they could be, and yes, after fix them, a round of redundant ?cast? warnings just show up as you mentioned, both fixed now > For rest of them, I could see most are due to the API return value or parameter are imprecise (such as Class.forName, Context.getEnvironment etc), to avoid useless cast, just kept the same declaration, please kindly advise if you have any suggestion about that too, thanks. Updated webrev as below > > http://cr.openjdk.java.net/~xyin/8214694/webrev.01/ > > Regards, > Chris > >> On 27 Mar 2020, at 4:41 AM, Joe Darcy wrote: >> >> Hi Chris, >> >> The changes don't appear incorrect, but at least from a cursory inspection, they don't appear as precise as they could be. Usually generifying a classes like this will next yield a round of redundant "cast" warnings; in my cleanup efforts, getting cast warnings was usually a sign the right generifiation was found. >> >> HTH, >> >> -Joe >> >> On 3/25/2020 12:57 AM, Chris Yin wrote: >>> Hello >>> >>> Please review following simple changes to cleanup raw types warning for open jndi tests (under test/jdk/com/sun/jndi and test/jdk/javax/naming), thanks >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214694 >>> Webrev: http://cr.openjdk.java.net/~xyin/8214694/webrev.00/ >>> >>> >>> The changes should be straightforward, only fix raw types warnings, no test logic change, no code optimization or cleanup. Minor change to each test file, just a little surprised about the affected tests count, hope this covers all. Run related jndi tests on 4 platforms for total 200 times, all passed. >>> >>> Thanks, >>> Chris From denghui.ddh at alibaba-inc.com Tue Mar 31 16:22:23 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 01 Apr 2020 00:22:23 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIzODY2NTogQWRkIEpGUiBldmVudCBmb3IgZGlyZWN0IG1lbW9yeSBzdGF0?= =?UTF-8?B?aXN0aWNz?= In-Reply-To: <8D25EB0F-7456-4BE7-A1D0-CB733B150061@oracle.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> <401741d6-cb99-d170-9a1f-a8793a8b1dd8@oracle.com> <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com> <33bcb20a-f92e-4e59-847f-50d877eb3247.denghui.ddh@alibaba-inc.com>, <8D25EB0F-7456-4BE7-A1D0-CB733B150061@oracle.com> Message-ID: Hi Erik, IMO, one event type per pool is a better choice, because: 1. easy filtering and configuration as you said, and I don't think there will be too many buffer pool types in the future 2. some buffer pools may have extra fields, e.g. direct memory has max capacity limit. webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.05/ diff with webrev.04: http://cr.openjdk.java.net/~ddong/8238665/v4-v5.diff please review it, thanks! Denghui Dong ------------------------------------------------------------------ From:Erik Gahlin Send Time:2020?3?31?(???) 19:18 To:???(??) Cc:Alan Bateman ; hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Denghui, I think there should be one event type per pool, or there should be a text field specifying which pool it is. If we believe there will be many pools in the future, it may make sense for a field, otherwise I think an event type could be used. The benefit of one event type per pool is that there can be a description per pool and it also allows easy filtering and configuration. If there would be four pools, they could all derive from an abstract event class and only add @Label and @Description per event subclass. If there would be forty pools, it would be too much noise and a field would be better. Erik On 31 Mar 2020, at 11:06, Denghui Dong wrote: PING. @Erik Could you review it? Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2020?3?19?(???) 16:35 To:Alan Bateman ; Erik Gahlin Cc:hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi, On Mar 18, 2020, at 11:46 PM, Alan Bateman wrote: On 13/03/2020 14:54, Denghui Dong wrote: Good suggestion, moved. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.03/ This looks much better. What would you think about renaming the JFR event to "DirectBufferStatistics"? The concern I have with the proposed naming is that it will be really awkward to extend it to support mapped buffers. It?s ok for me. The implementation changes look okay, hopefully Erik will skim over them. One small suggestion for for ManagementFactoryHelper is that you can stream().collect(Collectors.toList()) to create the value for bufferPools. You could even change it to volatile so that getBufferMXBeans isn't a synchronized method. Make sense, updated. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.04/ @Erik, could you help review it? -Alan. Denghui Dong From erik.gahlin at oracle.com Tue Mar 31 16:59:17 2020 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 31 Mar 2020 18:59:17 +0200 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com> <33bcb20a-f92e-4e59-847f-50d877eb3247.denghui.ddh@alibaba-inc.com> <8D25EB0F-7456-4BE7-A1D0-CB733B150061@oracle.com> Message-ID: <71F22B86-2175-4E40-AFE6-A2F16D63ACB1@oracle.com> Looks good. Erik > On 31 Mar 2020, at 18:22, Denghui Dong wrote: > > Hi Erik, > > IMO, one event type per pool is a better choice, because: > 1. easy filtering and configuration as you said, and I don't think there will be too many buffer pool types in the future > 2. some buffer pools may have extra fields, e.g. direct memory has max capacity limit. > > webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.05/ > diff with webrev.04: http://cr.openjdk.java.net/~ddong/8238665/v4-v5.diff > > please review it, thanks! > > Denghui Dong > ------------------------------------------------------------------ > From:Erik Gahlin > Send Time:2020?3?31?(???) 19:18 > To:???(??) > Cc:Alan Bateman ; hotspot-jfr-dev ; core-libs-dev > Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics > > Hi Denghui, > > I think there should be one event type per pool, or there should be a text field specifying which pool it is. > > If we believe there will be many pools in the future, it may make sense for a field, otherwise I think an event type could be used. The benefit of one event type per pool is that there can be a description per pool and it also allows easy filtering and configuration. > > If there would be four pools, they could all derive from an abstract event class and only add @Label and @Description per event subclass. If there would be forty pools, it would be too much noise and a field would be better. > > Erik > > On 31 Mar 2020, at 11:06, Denghui Dong > wrote: > > PING. > > @Erik Could you review it? > > Denghui Dong > > > > ------------------------------------------------------------------ > From:???(??) > > Send Time:2020?3?19?(???) 16:35 > To:Alan Bateman >; Erik Gahlin > > Cc:hotspot-jfr-dev >; core-libs-dev > > Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics > > Hi, > > On Mar 18, 2020, at 11:46 PM, Alan Bateman > wrote: > > > > On 13/03/2020 14:54, Denghui Dong wrote: > Good suggestion, moved. > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.03/ > This looks much better. > > What would you think about renaming the JFR event to "DirectBufferStatistics"? The concern I have with the proposed naming is that it will be really awkward to extend it to support mapped buffers. > > It?s ok for me. > > > The implementation changes look okay, hopefully Erik will skim over them. One small suggestion for for ManagementFactoryHelper is that you can stream().collect(Collectors.toList()) to create the value for bufferPools. You could even change it to volatile so that getBufferMXBeans isn't a synchronized method. > > > Make sense, updated. > > Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.04/ > > @Erik, could you help review it? > > > -Alan. > > Denghui Dong > From mandy.chung at oracle.com Tue Mar 31 17:33:59 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Mar 2020 10:33:59 -0700 Subject: RFR (S): 8241947: Minor comment fixes for system property handling In-Reply-To: References: Message-ID: <4a869bcd-c4ca-69b3-dc17-1dea871b1a4a@oracle.com> On 3/31/20 7:56 AM, Langer, Christoph wrote: > Hi, > > please review a small fix that updates two comments. > > The first one, in make/autoconf/spec.gmk.in, is probably quite old. It talks about handling of a property "vm.vendor" in VersionProps.java.template. However, there is no property "vm.vendor", it must rather be "java.vendor". I stumbled over that when looking at the change of JDK-4947890 (Minimize JNI upcalls in system-properties initialization). > > The second one is the code comment attached to "private static Properties props;" in java.lang.System. After JDK-8197927 (Allow the system property `java.vendor.version` to be undefined), "java.vendor.version" can be undefined, so this should be reflected in the comment. I also took the liberty to remove an unneeded import statement. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241947 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8241947.0/ > I wonder if we still want to keep this block of comments listing a subset of system properties.? Anyway the minor comment looks okay. Mandy From mandy.chung at oracle.com Tue Mar 31 18:06:58 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Mar 2020 11:06:58 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <940c6907-612e-8744-376c-5362991d4a42@oracle.com> This patch addresses Joe's feedback on the CSR [1]: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-jdarcy/ Specifically, it adds to the class specification of java.lang.Class to describe how the relevant methods behave for hidden classes.? In addition, use the new inline @jvms tag. Thanks Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8238359 On 3/26/20 4:57 PM, Mandy Chung wrote: > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area.? Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > > Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point > of view, a hidden class is a normal class except the following: > > - A hidden class has no initiating class loader and is not registered > in any dictionary. > - A hidden class has a name containing an illegal character > `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` > returns "Lp/Foo.0x1234;". > - A hidden class is not modifiable, i.e. cannot be redefined or > retransformed. JVM TI IsModifableClass returns false on a hidden. > - Final fields in a hidden class is "final".? The value of final > fields cannot be overriden via reflection.? setAccessible(true) can > still be called on reflected objects representing final fields in a > hidden class and its access check will be suppressed but only have > read-access (i.e. can do Field::getXXX but not setXXX). > > Brief summary of this patch: > > 1. A new Lookup::defineHiddenClass method is the API to create a > hidden class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG > option that > ?? can be specified when creating a hidden class. > 3. A new Class::isHiddenClass method tests if a class is a hidden class. > 4. Field::setXXX method will throw IAE on a final field of a hidden class > ?? regardless of the value of the accessible flag. > 5. JVM_LookupDefineClass is the new JVM entry point for > Lookup::defineClass > ?? and defineHiddenClass to create a class from the given bytes. > 6. ClassLoaderData implementation is not changed.? There is one > primary CLD > ?? that holds the classes strongly referenced by its defining loader.? > There > ?? can be zero or more additional CLDs - one per weak class. > 7. Nest host determination is updated per revised JVMS 5.4.4. Access > control > ?? check no longer throws LinkageError but instead it will throw IAE with > ?? a clear message if a class fails to resolve/validate the nest host > declared > ?? in NestHost/NestMembers attribute. > 8. JFR, jcmd, JDI are updated to support hidden classes. > 9. update javac LambdaToMethod as lambda proxy starts using nestmates > ?? and generate a bridge method to desuger a method reference to a > protected > ?? method in its supertype in a different package > > This patch also updates StringConcatFactory, LambdaMetaFactory, and > LambdaForms > to use hidden classes.? The webrev includes changes in nashorn to > hidden class > and I will update the webrev if JEP 372 removes it any time soon. > > We uncovered a bug in Lookup::defineClass spec throws LinkageError and > intends > to have the newly created class linked.? However, the implementation > in 14 > does not link the class.? A separate CSR [2] proposes to update the > implementation to match the spec.? This patch fixes the implementation. > > The spec update on JVM TI, JDI and Instrumentation will be done as > a separate RFE [3].? This patch includes new tests for JVM TI and > java.instrument that validates how the existing APIs work for hidden > classes. > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From christoph.langer at sap.com Tue Mar 31 18:46:06 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 31 Mar 2020 18:46:06 +0000 Subject: RFR (S): 8241947: Minor comment fixes for system property handling In-Reply-To: <9a7ca419-23c2-41b2-639e-0467dc74784a@oracle.com> References: <9a7ca419-23c2-41b2-639e-0467dc74784a@oracle.com> Message-ID: Hi Magnus, > From a build perspective this looks fine. Thanks for the review. > But it seems you are changing the interface for java.lang.System. Don't > you need a CSR for that? Or is your claim that the interface was indeed > changed by JDK-8197927, and it is a bug that the documentation was not > updated to match this? Yes, the second is true. The interface/spec was already changed with JDK-8197927 which also has a CSR attached. The commit is this: http://hg.openjdk.java.net/jdk/jdk/rev/d80becbcd3c1. What I'm modifying here is only the non API relevant doc of the private field props. The actual interface is documented in the Javadoc of method java.lang.System::getProperties(). Cheers Christoph From christoph.langer at sap.com Tue Mar 31 18:57:41 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 31 Mar 2020 18:57:41 +0000 Subject: RFR (S): 8241947: Minor comment fixes for system property handling In-Reply-To: <4a869bcd-c4ca-69b3-dc17-1dea871b1a4a@oracle.com> References: <4a869bcd-c4ca-69b3-dc17-1dea871b1a4a@oracle.com> Message-ID: Hi Mandy, this is a good suggestion. The listing of system properties at the props field declaration seems somewhat redundant, given that it already exists more exactly and with API normativity in the doc of System::getProperties(). So what do you think of this version: http://cr.openjdk.java.net/~clanger/webrevs/8241947.1/ ? Thanks Christoph From: Mandy Chung Sent: Dienstag, 31. M?rz 2020 19:34 To: Langer, Christoph ; core-libs-dev at openjdk.java.net Cc: build-dev Subject: Re: RFR (S): 8241947: Minor comment fixes for system property handling On 3/31/20 7:56 AM, Langer, Christoph wrote: Hi, please review a small fix that updates two comments. The first one, in make/autoconf/spec.gmk.in, is probably quite old. It talks about handling of a property "vm.vendor" in VersionProps.java.template. However, there is no property "vm.vendor", it must rather be "java.vendor". I stumbled over that when looking at the change of JDK-4947890 (Minimize JNI upcalls in system-properties initialization). The second one is the code comment attached to "private static Properties props;" in java.lang.System. After JDK-8197927 (Allow the system property `java.vendor.version` to be undefined), "java.vendor.version" can be undefined, so this should be reflected in the comment. I also took the liberty to remove an unneeded import statement. Bug: https://bugs.openjdk.java.net/browse/JDK-8241947 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8241947.0/ I wonder if we still want to keep this block of comments listing a subset of system properties. Anyway the minor comment looks okay. Mandy From mandy.chung at oracle.com Tue Mar 31 19:25:53 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Mar 2020 12:25:53 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <940c6907-612e-8744-376c-5362991d4a42@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <940c6907-612e-8744-376c-5362991d4a42@oracle.com> Message-ID: Alex's feedback:? rename isHiddenClass to isHidden as it can be a hidden class or interface. `isLocalClass` and `sAnonymousClass` are correct because the Java language only has local classes and anon classes, not local interfaces or anon. interfaces.? `isHidden` is like `isSynthetic`, it could be a class or interface. Although isHiddenClass seems clearer, I'm okay to rename it to `isHidden`. Mandy On 3/31/20 11:06 AM, Mandy Chung wrote: > This patch addresses Joe's feedback on the CSR [1]: > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-jdarcy/ > > > Specifically, it adds to the class specification of java.lang.Class to > describe how the relevant methods behave for hidden classes.? In > addition, use the new inline @jvms tag. > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > > On 3/26/20 4:57 PM, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area.? Small changes are >> made in javac, VM compiler (intrinsification of >> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed >> and is in the finalized state (see specdiff and javadoc below for >> reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >> point >> of view, a hidden class is a normal class except the following: >> >> - A hidden class has no initiating class loader and is not registered >> in any dictionary. >> - A hidden class has a name containing an illegal character >> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >> returns "Lp/Foo.0x1234;". >> - A hidden class is not modifiable, i.e. cannot be redefined or >> retransformed. JVM TI IsModifableClass returns false on a hidden. >> - Final fields in a hidden class is "final".? The value of final >> fields cannot be overriden via reflection.? setAccessible(true) can >> still be called on reflected objects representing final fields in a >> hidden class and its access check will be suppressed but only have >> read-access (i.e. can do Field::getXXX but not setXXX). >> >> Brief summary of this patch: >> >> 1. A new Lookup::defineHiddenClass method is the API to create a >> hidden class. >> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >> option that >> ?? can be specified when creating a hidden class. >> 3. A new Class::isHiddenClass method tests if a class is a hidden class. >> 4. Field::setXXX method will throw IAE on a final field of a hidden >> class >> ?? regardless of the value of the accessible flag. >> 5. JVM_LookupDefineClass is the new JVM entry point for >> Lookup::defineClass >> ?? and defineHiddenClass to create a class from the given bytes. >> 6. ClassLoaderData implementation is not changed.? There is one >> primary CLD >> ?? that holds the classes strongly referenced by its defining >> loader.? There >> ?? can be zero or more additional CLDs - one per weak class. >> 7. Nest host determination is updated per revised JVMS 5.4.4. Access >> control >> ?? check no longer throws LinkageError but instead it will throw IAE >> with >> ?? a clear message if a class fails to resolve/validate the nest host >> declared >> ?? in NestHost/NestMembers attribute. >> 8. JFR, jcmd, JDI are updated to support hidden classes. >> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >> ?? and generate a bridge method to desuger a method reference to a >> protected >> ?? method in its supertype in a different package >> >> This patch also updates StringConcatFactory, LambdaMetaFactory, and >> LambdaForms >> to use hidden classes.? The webrev includes changes in nashorn to >> hidden class >> and I will update the webrev if JEP 372 removes it any time soon. >> >> We uncovered a bug in Lookup::defineClass spec throws LinkageError >> and intends >> to have the newly created class linked.? However, the implementation >> in 14 >> does not link the class.? A separate CSR [2] proposes to update the >> implementation to match the spec.? This patch fixes the implementation. >> >> The spec update on JVM TI, JDI and Instrumentation will be done as >> a separate RFE [3].? This patch includes new tests for JVM TI and >> java.instrument that validates how the existing APIs work for hidden >> classes. >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > From mandy.chung at oracle.com Tue Mar 31 23:15:57 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Mar 2020 16:15:57 -0700 Subject: (XS) Review Request JDK-8241964: Clean up java.lang.Class javadoc Message-ID: ?This patch cleans up the javadoc in java.lang.Class and replaces "this object" and "this class object" with "this {@code Class} object" Webrev at: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8241964/webrev.00/ thanks Mandy From joe.darcy at oracle.com Tue Mar 31 23:22:43 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 31 Mar 2020 16:22:43 -0700 Subject: (XS) Review Request JDK-8241964: Clean up java.lang.Class javadoc In-Reply-To: References: Message-ID: Looks fine Mandy; thanks for doing this cleanup, -Joe On 3/31/2020 4:15 PM, Mandy Chung wrote: > ?This patch cleans up the javadoc in java.lang.Class and replaces > "this object" and "this class object" with "this {@code Class} object" > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8241964/webrev.00/ > > thanks > Mandy From mandy.chung at oracle.com Tue Mar 31 23:23:46 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Mar 2020 16:23:46 -0700 Subject: (XS) Review Request JDK-8241964: Clean up java.lang.Class javadoc In-Reply-To: References: Message-ID: <42a5511d-0361-ff9e-5739-067ae5992c9b@oracle.com> Thanks Joe for the quick review. Mandy On 3/31/20 4:22 PM, Joe Darcy wrote: > Looks fine Mandy; thanks for doing this cleanup, > > -Joe > > On 3/31/2020 4:15 PM, Mandy Chung wrote: >> ?This patch cleans up the javadoc in java.lang.Class and replaces >> "this object" and "this class object" with "this {@code Class} object" >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8241964/webrev.00/ >> >> thanks >> Mandy