From fujie at loongson.cn Fri Feb 1 00:51:51 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 1 Feb 2019 08:51:51 +0800 Subject: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp In-Reply-To: References: <587e0e2c-4297-03b1-76ef-fe020fc8b3cd@loongson.cn> <3c9b9a58-503b-bcbb-4ef8-28001fca3f43@loongson.cn> <8b24bdc4-5a90-8c8c-89a2-4ae40437d8fe@oracle.com> <5c758310-3639-01b3-0f1b-744cb306c5a0@loongson.cn> <7d3fad3e-3c1d-e4ed-871b-8387017d2b96@oracle.com> <48adb9d6-27de-ca1a-9d63-44185846f389@loongson.cn> <7416e1f6-14a6-07bf-a066-baa8f1e3e696@loongson.cn> <7c74daaa-7aff-ed22-8e93-64f64e462505@oracle.com> Message-ID: Thanks Roger. On 2019/1/31 ??11:16, Roger Riggs wrote: > Pushed > > On 01/30/2019 10:12 PM, Jie Fu wrote: >> Hi Roger, >> >> I really hope you can still sponsor this. >> Could you help me, please? >> Thanks again. >> >> Best regards, >> Jie >> >> >> On 2019/1/31 ??10:59, David Holmes wrote: >>> On 31/01/2019 12:44 pm, Jie Fu wrote: >>>> Hi David, >>>> >>>> I prefer the original patch[1]. >>>> >>>> Could you please sponsor this issue or help me find a sponsor. >>>> I really appreciate it. Thank you very much. >>> >>> Hopefully Roger will still sponsor this. >>> >>> Thanks, >>> David >>> >>>> Also thanks Roger. We had a pleasant discussion offlist. >>>> >>>> Best regards, >>>> Jie >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html >>>> >>>> >>>> >>>> On 2019/1/31 ??10:09, David Holmes wrote: >>>>> Hi Jie, Roger, >>>>> >>>>> I think this has now consumed far too many cycles for everyone, >>>>> dealing with a test that is checking for a leak that can't even >>>>> exist any more. Alan was fine with the original proposed patch, as >>>>> was I, so I think we can should proceed with that. Obviously there >>>>> is more than one way to tackle the Xcomp problem here, and there >>>>> will always be issues with any test relying on GC interaction, but >>>>> the proposed patch seems "good enough" to me. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 29/01/2019 11:46 am, Jie Fu wrote: >>>>>> Hi, >>>>>> >>>>>> I agree that the simplest way to fix the issue is just adding the >>>>>> reachabilityFence. >>>>>> But this patch might also fail since the VM doesn't guarantee >>>>>> that a GC would be performed. >>>>>> >>>>>> I didn't make such patch since I've learned from Sergey and Alan >>>>>> that calling "System.gc()" several times is unreliable to trigger >>>>>> a gc[1]. >>>>>> So I still prefer the original one[2]. >>>>>> >>>>>> Thanks a lot. >>>>>> >>>>>> Best regards, >>>>>> Jie >>>>>> >>>>>> [1] >>>>>> https://mail.openjdk.java.net/pipermail/beans-dev/2019-January/000396.html >>>>>> >>>>>> [2] >>>>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html >>>>>> >>>>>> >>>>>> >>>>>> On 2019/1/28 ??11:39, Roger Riggs wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The simplest fix for this failing test is to add a call to >>>>>>> reachabilityFence to prevent >>>>>>> the loader and loaderRef from going out of scope early. It >>>>>>> maintains getting debug >>>>>>> output on a failure. >>>>>>> >>>>>>> Offlist, Jie and I explored some alternate ways to write the >>>>>>> test and settled on this one. >>>>>>> >>>>>>> Please review: >>>>>>> >>>>>>> diff --git >>>>>>> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>>>> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>>>> >>>>>>> --- >>>>>>> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>>>> >>>>>>> +++ >>>>>>> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java >>>>>>> >>>>>>> @@ -113,11 +113,13 @@ public class RuntimeThreadInheritanceLea >>>>>>> ???????????? Reference dequeued = refQueue.remove(TIMEOUT); >>>>>>> ???????????? if (dequeued == null) { >>>>>>> ???????????????? System.err.println( >>>>>>> -??????????????????? "TEST FAILED: loader not deteced weakly >>>>>>> reachable"); >>>>>>> +??????????????????? "TEST FAILED: loader not detected weakly >>>>>>> reachable"); >>>>>>> ???????????????? dumpThreads(); >>>>>>> ???????????????? throw new RuntimeException( >>>>>>> ???????????????????? "TEST FAILED: loader not detected weakly >>>>>>> reachable"); >>>>>>> ???????????? } >>>>>>> +??????????? Reference.reachabilityFence(loader); >>>>>>> +??????????? Reference.reachabilityFence(loaderRef); >>>>>>> >>>>>>> ???????????? System.err.println( >>>>>>> ???????????????? "TEST PASSED: loader detected weakly reachable"); >>>>>>> >>>>>>> Thanks, Roger >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 01/11/2019 07:25 PM, Jie Fu wrote: >>>>>>>> Thanks David and Roger. >>>>>>>> >>>>>>>> >>>>>>>> On 2019?01?12? 06:52, David Holmes wrote: >>>>>>>>> Hi Roger, >>>>>>>>> >>>>>>>>> On 12/01/2019 2:22 am, Roger Riggs wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> The proposed patch changes the test in a way that is unintended. >>>>>>>>>> >>>>>>>>>> Adding the infinite loop of gc() and sleep, will change the >>>>>>>>>> timeout behavior >>>>>>>>>> from the existing timeout of TIMEOUT to the jtreg default >>>>>>>>>> timeout of the whole test. >>>>>>>>> >>>>>>>>> Partially true. If the new loop gets stuck then yes the jtreg >>>>>>>>> default timeout will apply - I don't see that is necessarily a >>>>>>>>> bad thing. The existing timeout only applies to the >>>>>>>>> refQueue.remove operation itself, you don't know how much time >>>>>>>>> was spent before you got there, nor how much will be spent >>>>>>>>> after in the dumpThreads() calls - so the jtreg timeout can >>>>>>>>> still come into affect. >>>>>>>>> >>>>>>>>>> Further, it renders the check at lines 114-120 irrelevant >>>>>>>>>> since loaderRef.get() >>>>>>>>>> will have returned null and the ref will have been enqueued >>>>>>>>>> by then. >>>>>>>>> >>>>>>>>> I wouldn't say irrelevant as it double-checks the interaction >>>>>>>>> between the ref.get() and the queue.remove() - the result of >>>>>>>>> one should imply the result of the other, but if enqueuing had >>>>>>>>> a bug .... >>>>>>>>> >>>>>>>>>> While it is true that calling gc() only once is unreliable, a >>>>>>>>>> better fix is to >>>>>>>>>> put the code from 108-120 in a loop with a fixed number of >>>>>>>>>> durations >>>>>>>>> >>>>>>>>> That would also work - say 5 loops and reduce TIMEOUT to 4000. >>>>>>>>> >>>>>>>>>> and add Reachability.reachabilityFence(loaderRef) to ensure >>>>>>>>>> the ref is not ignored. >>>>>>>>> >>>>>>>>> Adding ReachabilityFence, alone, may solve the observed >>>>>>>>> problem given one gc() seems to be working in practice (and >>>>>>>>> because we don't actually have the leaked loaders anymore >>>>>>>>> because those threads (sun.misc.GC threads) don't exist anymore). >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Regards, Roger >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> > From alexander.matveev at oracle.com Fri Feb 1 04:22:58 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 31 Jan 2019 20:22:58 -0800 Subject: RFR: JDK-8217317 : Create jpackage native library for windows Message-ID: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - jpackage launcher will now build same as Linux and OS X using SetupBuildLauncher. - jpackage.dll was added based on Windows jpackage.exe launcher which will have icon swap and version swap functionality called via JNI. - Some code formatting, clean up and minor improvements where done to icon and version swap code. No functional changes. - Windows registry will be read and enumerated via JNI as well. - isDirectoryInExclusionPath() will use native path comparison, since paths in registry and temp folder returned by Java code can be in short or long format, thus simple string comparison will not work. - Windows Defender workaround warning will be checked for --build-root as well if it is set. - Removed extra escaping from JPackageHelper for Windows, otherwise tests fails due to incorrect escaping. Our launcher used CreateProcess to launch java.exe by passing args from main() to CreateProcess. This is why I think we required extra escaping. [1] https://bugs.openjdk.java.net/browse/JDK-8217317 [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ Thanks, Alexander From ecki at zusammenkunft.net Fri Feb 1 09:09:28 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 1 Feb 2019 09:09:28 +0000 Subject: PreparedStatement.setBinaryStream Javadoc Message-ID: Hello, The JavaDoc for some of the setBinary/ASCII... methods of PS say something about ?more practical? but it is not clear if it means this method is more practical than another method, or if this method should not be used in favor of another. When a very large binary value is input to a LONGVARBINARY parameter, it may be more practical to send it via a java.io.InputStream object. Also, does this not apply to BLOB or VARBINARY? I would clarify this to something like (if I understood the meaning correctly): For large content the use of an InputStream/Reader can avoid keeping the data in memory, It however depends on the driver how the data is internally processed or buffered. BTW those functions do not mention if the stream is closed or not. After the method returns the stream is not closed. Some more clarifications could also be given (not sure if all of them are correct): The stream is positioned after the specified length. The reading blocks till the end of stream is signaled (will not return when abailable()==0) EOFException is thrown If stream is shorter than specified length. Gruss Bernd -- http://bernd.eckenfels.net From magnus.ihse.bursie at oracle.com Fri Feb 1 10:50:08 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 1 Feb 2019 11:50:08 +0100 Subject: RFR: JDK-8218186 Clean up CLDR generation in build Message-ID: The CLDR data is, since Jigsaw, used in two different modules -- java.base and jdk.localedata. Unfortunately, the split between these two modules were not fully finished as part of the Jigsaw project. This patch aims to resolving most of this. The CLDRConverter build tool is now called from Gensrc-java.base and Gensrc-jdk.localedata, for their respective module. The calls have been updated to match modern build-infra standards. Also, the raw CLDR data was located mixed in with the Java source, in jdk.localedata. This patch also moves the data to make/data/cldr, to align with input data to all other build tools. Bug: https://bugs.openjdk.java.net/browse/JDK-8218186 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8218186-cleanup-CLDR/webrev.01 /Magnus From volker.simonis at gmail.com Fri Feb 1 10:52:20 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 1 Feb 2019 11:52:20 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: <1666991f-fafb-8845-de5b-894134f9b2a5@oracle.com> References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> <089E01D7-D783-4ED7-9624-0273A94774D6@sap.com> <1666991f-fafb-8845-de5b-894134f9b2a5@oracle.com> Message-ID: On Wed, Jan 23, 2019 at 5:44 PM Alan Bateman wrote: > > On 23/01/2019 15:59, Haug, Gunter wrote: > > : > > > > As Volker writes, we still think that the overhead of the up-calls is acceptable but it would be possible to introduce a switch which is based on a system property. > > > There are concerns with the approach and patch. The replies from David > hint that he also has concerns. David had concerns about the number of up-calls into the VM. If you've read Gunters last mail and looked at his performance numbers you can see that the proposed instrumentation has no measurable performance impact. So can we agree on the fact that the proposed solution doesn't introduce any performance issues? > I think it would be useful to start out > with a summary of what the app server is looking to do with these stats. > I think we need to understand if collecting by thread is really the > right way to do this as it may not be the right approach in the long > term. As I wrote in my previous mail - this information has proved very valuable for both, our support engineers as well as our developers. What do you mean by "start with a summary"? The feature is trivial - you get exact, per thread IO information in the same way you currently already get allocation information per thread. Why should the one be useful and the other not? > The granularity is also important as you've instrumented a bunch > of places that are surprising as they aren't regular file or socket I/O. > I think it's important to understand what prototypes were done with > instrumentation at the java level rather than in the native methods. > This goes to the maintenance concern. There were suggestions of > performance issues but it's not clear if those experiments were recent > or from 10 years ago. For me this is a strange argument. We propose a new feature and you ask us to implement a different feature and compare them. It's a little bit like somebody proposes a new GC and you reject it because there may be other GCs. > For the libraries area then we really should be > reducing the native code for maintenance and debugging reasons, maybe > performance reasons too once we can start to make use of Panama. I don't see Panama and the changes you envision arriving in the next one or two years. I therefore I don't see why we shouldn't be able to implement this feature now because eventually a feature which isn't nearly stabilized may interfere with it. And by the way, I still don't think that they will really interfere. The proposed change may change quite some places but the changes themselves are actually trivial. We could even make them smaller by using macros for example if that's something you think may help. In the end, I don't expect that maintaining this code will impose and fundamental problems. And I re-iterate that we're committed do that (in the same way we're already maintaining the PPC/AIX and s390 ports). > Finally > I think it's important to see how this fits with the instrumentation > that JFR and other potential instrumentation of the libraries going > forward (native method tracking was mentioned). These features are orthogonal. Please read Gunter's answer about the difference in his previous mail (https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058030.html) repeated here for your convenience: "The existing events are triggered only if the time the IO operation takes, exceeds a threshold (10ms/20ms for profile/default settings respectively). They are aimed for providing information on the time IO operations take and do not provide per thread IO statistics. What we are interested in is per thread information similar to the jdk.ThreadAllocationStatistics event." > So overall I think there > is a lot to discuss and write-up. > Sure, lets discuss this in Brussels at the Committers workshop :) Regards, Volker > -Alan From goetz.lindenmaier at sap.com Fri Feb 1 11:19:03 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 1 Feb 2019 11:19:03 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> <089E01D7-D783-4ED7-9624-0273A94774D6@sap.com> <1666991f-fafb-8845-de5b-894134f9b2a5@oracle.com> Message-ID: <303325779ce7465abfa343f8e1b08e74@sap.com> Hi, > These features are orthogonal. Please read Gunter's answer about the > difference in his previous mail > (https://mail.openjdk.java.net/pipermail/core-libs-dev/2019- > January/058030.html) > repeated here for your convenience: > > "The existing events are triggered only if the time the IO operation > takes, exceeds a threshold (10ms/20ms for profile/default settings > respectively). They are aimed for providing information on the time IO > operations take and do not provide per thread IO statistics. What we > are interested in is per thread information similar to the > jdk.ThreadAllocationStatistics event." To kick in here, too: The existing solution tells you which threads spend a lot of time in IO operations. This is a good hint to problems in the infrastructure. You might just write a few bytes, but still get long delays because the disc is too slow or saturated etc. The numbers Gunter collects give information about what your code intends to do: how much bytes does the code write? Should you optimize your application to communicate less? ... to write less to file? If you have both numbers, you can even better recognize threads that wait too long on the network: they write few bytes but still spend a lot of time in the calls. So I see enough arguments to have both metrics. Best regards, Goetz. > > > So overall I think there > > is a lot to discuss and write-up. > > > > Sure, lets discuss this in Brussels at the Committers workshop :) > > Regards, > Volker > > > -Alan From Alan.Bateman at oracle.com Fri Feb 1 11:37:18 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 1 Feb 2019 11:37:18 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: <303325779ce7465abfa343f8e1b08e74@sap.com> References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> <089E01D7-D783-4ED7-9624-0273A94774D6@sap.com> <1666991f-fafb-8845-de5b-894134f9b2a5@oracle.com> <303325779ce7465abfa343f8e1b08e74@sap.com> Message-ID: On 01/02/2019 11:19, Lindenmaier, Goetz wrote: > : > To kick in here, too: > The existing solution tells you which threads spend a lot of time > in IO operations. This is a good hint to problems in the infrastructure. > You might just write a few bytes, but still get long delays because the > disc is too slow or saturated etc. > The numbers Gunter collects give information about what your > code intends to do: how much bytes does the code write? Should > you optimize your application to communicate less? ... to write > less to file? > > If you have both numbers, you can even better recognize threads > that wait too long on the network: they write few bytes but still > spend a lot of time in the calls. > > So I see enough arguments to have both metrics. > Erik Gahlin put in support in JDK 12 to allow for code in java.base to generate JFR events. I think the only user so far is in the security area where there are events to log usages of weak crypto. I think this is one of the approaches that will need to be looked at as part of the exploration on the right way to add serviceability support to the libraries. -Alan From magnus.ihse.bursie at oracle.com Fri Feb 1 11:39:26 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 1 Feb 2019 12:39:26 +0100 Subject: RFR: JDK-8217317 : Create jpackage native library for windows In-Reply-To: References: Message-ID: <5ba0a754-bbeb-3aca-d574-f5274fd200e2@oracle.com> Hi Alexander, On 2019-02-01 05:22, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - jpackage launcher will now build same as Linux and OS X using > SetupBuildLauncher. > - jpackage.dll was added based on Windows jpackage.exe launcher which > will have icon swap and version swap functionality called via JNI. > - Some code formatting, clean up and minor improvements where done to > icon and version swap code. No functional changes. > - Windows registry will be read and enumerated via JNI as well. > - isDirectoryInExclusionPath() will use native path comparison, since > paths in registry and temp folder returned by Java code can be in > short or long format, thus simple string comparison will not work. > - Windows Defender workaround warning will be checked for --build-root > as well if it is set. > - Removed extra escaping from JPackageHelper for Windows, otherwise > tests fails due to incorrect escaping. Our launcher used CreateProcess > to launch java.exe by passing args from main() to CreateProcess. This > is why I think we required extra escaping. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217317 > > [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ It basically looks good from a build perspective. There is one change I'd like to request, however, and that is that you place the source code according to the standard layout. This means moving the source files from src/jdk.jpackage/windows/native/jpackage to src/jdk.jpackage/windows/native/libjpackage. Also, when you do this, you don't need JPACKAGELIB_SRC; the location of the files will be determined by SetupJdkLibrary based on the name "jpackage" of the library. I'm also surprised to see that I can't find the removal of the old WinMain() method? /Magnus > > Thanks, > Alexander From goetz.lindenmaier at sap.com Fri Feb 1 12:06:35 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 1 Feb 2019 12:06:35 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> <089E01D7-D783-4ED7-9624-0273A94774D6@sap.com> <1666991f-fafb-8845-de5b-894134f9b2a5@oracle.com> <303325779ce7465abfa343f8e1b08e74@sap.com> Message-ID: Hi Alan, Are you referring to this? 8148188: Enhance the security libraries to record events of interest http://hg.openjdk.java.net/jdk/jdk12/rev/f7309a1491d9 Which, presumably, needed this 8203629: Produce events in the JDK without a dependency on jdk.jfr http://hg.openjdk.java.net/jdk/jdk12/rev/a181612f0715?revcount=40 Best regards, Goetz. > -----Original Message----- > From: Alan Bateman > Sent: Freitag, 1. Februar 2019 12:37 > To: Lindenmaier, Goetz > Cc: hotspot-jfr-dev at openjdk.java.net; Java Core Libs dev at openjdk.java.net>; Hotspot dev runtime dev at openjdk.java.net> > Subject: Re: [RFR]: Per thread IO statistics in JFR > > On 01/02/2019 11:19, Lindenmaier, Goetz wrote: > > : > > To kick in here, too: > > The existing solution tells you which threads spend a lot of time > > in IO operations. This is a good hint to problems in the infrastructure. > > You might just write a few bytes, but still get long delays because the > > disc is too slow or saturated etc. > > The numbers Gunter collects give information about what your > > code intends to do: how much bytes does the code write? Should > > you optimize your application to communicate less? ... to write > > less to file? > > > > If you have both numbers, you can even better recognize threads > > that wait too long on the network: they write few bytes but still > > spend a lot of time in the calls. > > > > So I see enough arguments to have both metrics. > > > Erik Gahlin put in support in JDK 12 to allow for code in java.base to > generate JFR events. I think the only user so far is in the security > area where there are events to log usages of weak crypto. I think this > is one of the approaches that will need to be looked at as part of the > exploration on the right way to add serviceability support to the libraries. > > -Alan From Alan.Bateman at oracle.com Fri Feb 1 12:20:01 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 1 Feb 2019 12:20:01 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> <089E01D7-D783-4ED7-9624-0273A94774D6@sap.com> <1666991f-fafb-8845-de5b-894134f9b2a5@oracle.com> Message-ID: <056758ad-983e-1931-38b9-5667f2f300b0@oracle.com> On 01/02/2019 10:52, Volker Simonis wrote: > : > As I wrote in my previous mail - this information has proved very > valuable for both, our support engineers as well as our developers. > What do you mean by "start with a summary"? The feature is trivial - > you get exact, per thread IO information in the same way you currently > already get allocation information per thread. Why should the one be > useful and the other not? > Allocation rates are useful for tuning and troubleshooting and are better understood.? I think I/O events require a lot more discussion. I've no doubt that your app server or support folks have found it useful but all the discussion and info on how they use it is missing here. We are also missing the bigger discussion on extending serviceability features to the libraries, and this at least partly related to a discussion on how serviceability features will work when more of the runtime and compilers are written in Java. There was some ground work done on this in JDK 12 to allow code in java.base generate JFR events that may be part of the discussion and exploration. The other thing that is missing is a write up of the different approaches that you have tried. From a maintenance point of view it is important to see the solution that does the instrumentation in the java code, rather the native methods as we want less native code. Finally there is a issue on where the approaches fit with the bigger projects, hence the concerns/questions on where I/O stats per thread might go in the future. -Alan. From naoto.sato at oracle.com Fri Feb 1 13:43:03 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 1 Feb 2019 05:43:03 -0800 Subject: RFR: JDK-8218186 Clean up CLDR generation in build In-Reply-To: References: Message-ID: Hi Magnus, I am assuming that the generated resource bundles are exactly the same as before this fix, correct? Naoto On 2/1/19 2:50 AM, Magnus Ihse Bursie wrote: > The CLDR data is, since Jigsaw, used in two different modules -- > java.base and jdk.localedata. Unfortunately, the split between these two > modules were not fully finished as part of the Jigsaw project. > > This patch aims to resolving most of this. The CLDRConverter build tool > is now called from Gensrc-java.base and Gensrc-jdk.localedata, for their > respective module. The calls have been updated to match modern > build-infra standards. > > Also, the raw CLDR data was located mixed in with the Java source, in > jdk.localedata. This patch also moves the data to make/data/cldr, to > align with input data to all other build tools. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218186 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8218186-cleanup-CLDR/webrev.01 > > /Magnus From andy.herrick at oracle.com Fri Feb 1 14:54:23 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 1 Feb 2019 09:54:23 -0500 Subject: RFR: JDK-8217751: jpackage messages and failures Message-ID: <4c86b9da-0b70-77d4-2c86-ccb231f5b255@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). RFR:? JDK-8217751: jpackage messages and failures This is a fix to Error and Warning processing and Error message content. [1] JDK-8217751 [2] http://cr.openjdk.java.net/~herrick/8217751/webrev.01/ From andy.herrick at oracle.com Fri Feb 1 15:03:23 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 1 Feb 2019 10:03:23 -0500 Subject: RFR: JDK-8217317 : Create jpackage native library for windows In-Reply-To: <5ba0a754-bbeb-3aca-d574-f5274fd200e2@oracle.com> References: <5ba0a754-bbeb-3aca-d574-f5274fd200e2@oracle.com> Message-ID: This looks good once Magnus's concerns are addressed. /Andy On 2/1/2019 6:39 AM, Magnus Ihse Bursie wrote: > Hi Alexander, > > On 2019-02-01 05:22, Alexander Matveev wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> - jpackage launcher will now build same as Linux and OS X using >> SetupBuildLauncher. >> - jpackage.dll was added based on Windows jpackage.exe launcher which >> will have icon swap and version swap functionality called via JNI. >> - Some code formatting, clean up and minor improvements where done to >> icon and version swap code. No functional changes. >> - Windows registry will be read and enumerated via JNI as well. >> - isDirectoryInExclusionPath() will use native path comparison, since >> paths in registry and temp folder returned by Java code can be in >> short or long format, thus simple string comparison will not work. >> - Windows Defender workaround warning will be checked for >> --build-root as well if it is set. >> - Removed extra escaping from JPackageHelper for Windows, otherwise >> tests fails due to incorrect escaping. Our launcher used >> CreateProcess to launch java.exe by passing args from main() to >> CreateProcess. This is why I think we required extra escaping. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217317 >> >> [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ > It basically looks good from a build perspective. There is one change > I'd like to request, however, and that is that you place the source > code according to the standard layout. This means moving the source > files from src/jdk.jpackage/windows/native/jpackage to > src/jdk.jpackage/windows/native/libjpackage. Also, when you do this, > you don't need JPACKAGELIB_SRC; the location of the files will be > determined by SetupJdkLibrary based on the name "jpackage" of the > library. > > I'm also surprised to see that I can't find the removal of the old > WinMain() method? > > /Magnus > > >> >> Thanks, >> Alexander > From erik.joelsson at oracle.com Fri Feb 1 16:43:36 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Feb 2019 08:43:36 -0800 Subject: RFR: JDK-8218186 Clean up CLDR generation in build In-Reply-To: References: Message-ID: Looks good. /Erik On 2019-02-01 02:50, Magnus Ihse Bursie wrote: > The CLDR data is, since Jigsaw, used in two different modules -- > java.base and jdk.localedata. Unfortunately, the split between these > two modules were not fully finished as part of the Jigsaw project. > > This patch aims to resolving most of this. The CLDRConverter build > tool is now called from Gensrc-java.base and Gensrc-jdk.localedata, > for their respective module. The calls have been updated to match > modern build-infra standards. > > Also, the raw CLDR data was located mixed in with the Java source, in > jdk.localedata. This patch also moves the data to make/data/cldr, to > align with input data to all other build tools. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218186 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8218186-cleanup-CLDR/webrev.01 > > /Magnus From Roger.Riggs at oracle.com Fri Feb 1 16:47:42 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 1 Feb 2019 11:47:42 -0500 Subject: RFR 8218195: [testlibrary] Diagnostic output for test library ProcessTools Message-ID: Please review the addition of diagnostic output to the test library ProcessTools.executeProcess to aid in diagnosing several unexplained timeouts. It adds a second check for process being aliev using ProcessHandle and prints information about the current process and its descendents and all processes. Webrev: ?? http://cr.openjdk.java.net/~rriggs/webrev-pt-alive-patch-1/ Thanks, Roger From igor.ignatyev at oracle.com Fri Feb 1 17:19:40 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 1 Feb 2019 09:19:40 -0800 Subject: RFR 8218195: [testlibrary] Diagnostic output for test library ProcessTools In-Reply-To: References: Message-ID: <6D746493-6A7E-477D-93D9-509438359B8C@oracle.com> Hi Roger, it looks like we might get false-positive "Process terminated unexpectedly" w/ this patch and as JDK-8218197 seems to better explain the evidence, I don't think we need this patch at all. Thanks, -- Igor > On Feb 1, 2019, at 8:47 AM, Roger Riggs wrote: > > Please review the addition of diagnostic output to the test library ProcessTools.executeProcess > to aid in diagnosing several unexplained timeouts. > > It adds a second check for process being aliev using ProcessHandle and prints > information about the current process and its descendents and all processes. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-pt-alive-patch-1/ > > Thanks, Roger > From Roger.Riggs at oracle.com Fri Feb 1 17:48:01 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 1 Feb 2019 12:48:01 -0500 Subject: RFR 8218195: [testlibrary] Diagnostic output for test library ProcessTools In-Reply-To: <6D746493-6A7E-477D-93D9-509438359B8C@oracle.com> References: <6D746493-6A7E-477D-93D9-509438359B8C@oracle.com> Message-ID: Hi Igor, ok, no need to add useless code. And yes there might be timing issue;? but the output is purely diagnostic and it does not throw an exception so by itself would not cause the test to misbehave. Roger On 02/01/2019 12:19 PM, Igor Ignatyev wrote: > Hi Roger, > > it looks like we might get false-positive "Process terminated unexpectedly" w/ this patch and as JDK-8218197 seems to better explain the evidence, I don't think we need this patch at all. > > Thanks, > -- Igor > >> On Feb 1, 2019, at 8:47 AM, Roger Riggs wrote: >> >> Please review the addition of diagnostic output to the test library ProcessTools.executeProcess >> to aid in diagnosing several unexplained timeouts. >> >> It adds a second check for process being aliev using ProcessHandle and prints >> information about the current process and its descendents and all processes. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-pt-alive-patch-1/ >> >> Thanks, Roger >> From daniel.fuchs at oracle.com Fri Feb 1 17:57:50 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 1 Feb 2019 17:57:50 +0000 Subject: RFR 8218195: [testlibrary] Diagnostic output for test library ProcessTools In-Reply-To: References: Message-ID: <54e6017c-a062-a27d-1f7e-ed3131b086b7@oracle.com> Hi Roger, Looks good to me - although it might hide bugs in Process.waitFor ? best regards, -- daniel On 01/02/2019 16:47, Roger Riggs wrote: > Please review the addition of diagnostic output to the test library > ProcessTools.executeProcess > to aid in diagnosing several unexplained timeouts. > > It adds a second check for process being aliev using ProcessHandle and > prints > information about the current process and its descendents and all > processes. > > Webrev: > ?? http://cr.openjdk.java.net/~rriggs/webrev-pt-alive-patch-1/ > > Thanks, Roger > From alexander.matveev at oracle.com Fri Feb 1 22:30:24 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 1 Feb 2019 14:30:24 -0800 Subject: RFR: JDK-8217751: jpackage messages and failures In-Reply-To: <4c86b9da-0b70-77d4-2c86-ccb231f5b255@oracle.com> References: <4c86b9da-0b70-77d4-2c86-ccb231f5b255@oracle.com> Message-ID: <03032725-bbc9-5ed2-8476-705a6c35eea6@oracle.com> Hi Andy, Looks good. Thanks, Alexander On 2/1/2019 6:54 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > RFR:? JDK-8217751: jpackage messages and failures > This is a fix to Error and Warning processing and Error message content. > > > [1] JDK-8217751 > > [2] http://cr.openjdk.java.net/~herrick/8217751/webrev.01/ > From alexander.matveev at oracle.com Fri Feb 1 22:38:08 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 1 Feb 2019 14:38:08 -0800 Subject: RFR: JDK-8217317 : Create jpackage native library for windows In-Reply-To: <5ba0a754-bbeb-3aca-d574-f5274fd200e2@oracle.com> References: <5ba0a754-bbeb-3aca-d574-f5274fd200e2@oracle.com> Message-ID: Hi Magnus, http://cr.openjdk.java.net/~almatvee/8217317/webrev.01/ Moved files to libjpackage and remove JPACKAGELIB_SRC. Old wmain() was in jpackage.cpp line 461. Thanks, Alexander On 2/1/2019 3:39 AM, Magnus Ihse Bursie wrote: > Hi Alexander, > > On 2019-02-01 05:22, Alexander Matveev wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> - jpackage launcher will now build same as Linux and OS X using >> SetupBuildLauncher. >> - jpackage.dll was added based on Windows jpackage.exe launcher which >> will have icon swap and version swap functionality called via JNI. >> - Some code formatting, clean up and minor improvements where done to >> icon and version swap code. No functional changes. >> - Windows registry will be read and enumerated via JNI as well. >> - isDirectoryInExclusionPath() will use native path comparison, since >> paths in registry and temp folder returned by Java code can be in >> short or long format, thus simple string comparison will not work. >> - Windows Defender workaround warning will be checked for >> --build-root as well if it is set. >> - Removed extra escaping from JPackageHelper for Windows, otherwise >> tests fails due to incorrect escaping. Our launcher used >> CreateProcess to launch java.exe by passing args from main() to >> CreateProcess. This is why I think we required extra escaping. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217317 >> >> [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ > It basically looks good from a build perspective. There is one change > I'd like to request, however, and that is that you place the source > code according to the standard layout. This means moving the source > files from src/jdk.jpackage/windows/native/jpackage to > src/jdk.jpackage/windows/native/libjpackage. Also, when you do this, > you don't need JPACKAGELIB_SRC; the location of the files will be > determined by SetupJdkLibrary based on the name "jpackage" of the > library. > > I'm also surprised to see that I can't find the removal of the old > WinMain() method? > > /Magnus > > >> >> Thanks, >> Alexander > From ivan.gerasimov at oracle.com Sat Feb 2 07:28:23 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 1 Feb 2019 23:28:23 -0800 Subject: RFR 8218227 : StringBuilder constructor throws confusing NegativeArraySizeException Message-ID: Hello! The spec of the constructors StringBuilder(String)/StringBuilder(CharSequence) states that the initial capacity of the builder will be set to the length of the argument plus 16. This causes them to throw confusing NegativeArraySizeException when the argument's length is close to Integer.MAX_VALUE. Let the arguments length be (Integer.MAX_VALUE - DELTA), like in the code below: String str = "Z".repeat(Integer.MAX_VALUE - DELTA); StringBuilder sb = new StringBuilder(str); Currently the behavior is as following: 0 <= DELTA <= 2 - unable to construct str, 2 <= DELTA <= 15 - NegativeArraySizeException is thrown, 16 <= DELTA <= 17 - OutOfMemoryError is thrown, DELTA >= 18 - works fine. With the fix, OOM will be thrown for all DELTA <= 17. Also the fix will make constructing a StringBuilder from UTF16 coded String slightly more efficient. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218227 WEBREV: http://cr.openjdk.java.net/~igerasim/8218227/00/webrev/ Would you please help review the fix? -- With kind regards, Ivan Gerasimov From jpstotz at gmx.de Sat Feb 2 17:42:24 2019 From: jpstotz at gmx.de (Jan Peter Stotz) Date: Sat, 2 Feb 2019 18:42:24 +0100 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> Message-ID: <484fbd95-de0c-d601-b51a-ada5e6206776@gmx.de> Hi Stuart. It looks like the web sites and services I use when developing and those you use are fundamentally different or may be we use just different search engines, because when I have programming problems I usually not end up on Twitter or Reddit or DZone. And the existence of this mailing list seems to be hidden to the net or it's SE ranking is so bad that I can't remember that I ever found a link to it in the last years (before knowing it's existence and explicitly searching for it). However when I search most likely the majority of links point to Stackoverflow.com. Searching Stackoverflow for something like "[Java] [performance] Hashset" you immediatly get to the question https://stackoverflow.com/questions/28671903 which has 65 upvotes and a view count of 8,085. For a 5 years old question this is IMHO pretty impressive. Also one have to keep in mind that we are talking about a performance problem that requires usually an experienced developer and large data sets before the delay becomes so apparently that you start searching for the reason. Your proposed replacement for AbstractSet.removeAll() looks nice and I agree with you regarding the arguments you pointed out on what collection used as "this" and what as argument. That should be clearly a decision of the developer. That the change makes AbstractSet.removeAll "an outlier" is in my opinion only a problem from a very high-level perspective. Only people not aware of the differences between all the Collection implementations and the reason why they exist may expect to have a removeAll() implementation that works identical for every Collection implementation. However regular programmers from my experience rarely come to a point where they use Collection. Personally for me Collection is more or less a synonym for Iterable because iterating over a Collection is one of the few properties that work without major (potential) performance issues for all implementations. Jan Am 25.01.2019 um 01:07 schrieb Stuart Marks: > I wasn't aware that hundreds of developers are hitting this bug every > year. I haven't seen any mention of it (besides in the bug database) on > Twitter, on Reddit, on DZone, at the conferences I attend, or in several > years of core-libs-dev emails. Well, it was mentioned on core-libs-dev > once in 2011 [1] although that was a suggestion for improvement, not a > complaint about performance. > > Nonetheless this is a real problem, and if it's causing difficulties we > can certainly take a look at it. > > There is, however, more to the story. The ACTUAL problem is a semantic > one; see JDK-6394757. [2] Briefly, consider x.removeAll(y). Depending on > the relative sizes of x and y, this method might end up using either x's > or y's definition of membership, which could differ from each other. > (See the bug report for an example.) Thus the semantics of this method > depend upon the relative sizes of the collections, which is arguably > flawed. > > Worse, this behavior is specified to iterate this set or the argument, > depending upon their relative sizes. [3] So, fixing this will require an > incompatible specification change. > > The obvious way to fix this is to get rid of the "optimizations" (that > turn out not to be optimizations at all in some cases) and replace it > with a simple loop: > > ??? public boolean removeAll(Collection c) { > ??????? Objects.requireNonNull(c); > ??????? boolean modified = false; > ??????? for (Object e : c) > ??????????? modified |= remove(e); > ??????? return modified; > ??? } > > I would argue that iterating the argument and calling remove() on "this" > are the right semantics, because you want set membership to be > determined by this set, not by whatever collection you pass as an > argument. However, I note that AbstractCollection.removeAll and other > removeAll implementations iterate over "this" and do a contains() check > on the argument. The revised AbstractSet.removeAll would be an outlier > here, though it makes sense to me to do it this way. > > Is it worth the incompatibility? > > s'marks > > > > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html > > [2] https://bugs.openjdk.java.net/browse/JDK-6394757 > > [3] > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/AbstractSet.html#removeAll(java.util.Collection) > > > From andy.herrick at oracle.com Sun Feb 3 13:45:49 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 3 Feb 2019 08:45:49 -0500 Subject: RFR: JDK-8217317 : Create jpackage native library for windows In-Reply-To: References: <5ba0a754-bbeb-3aca-d574-f5274fd200e2@oracle.com> Message-ID: looks good. /Andy On 2/1/2019 5:38 PM, Alexander Matveev wrote: > Hi Magnus, > > http://cr.openjdk.java.net/~almatvee/8217317/webrev.01/ > > Moved files to libjpackage and remove JPACKAGELIB_SRC. > > Old wmain() was in jpackage.cpp line 461. > > Thanks, > Alexander > > On 2/1/2019 3:39 AM, Magnus Ihse Bursie wrote: >> Hi Alexander, >> >> On 2019-02-01 05:22, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - jpackage launcher will now build same as Linux and OS X using >>> SetupBuildLauncher. >>> - jpackage.dll was added based on Windows jpackage.exe launcher >>> which will have icon swap and version swap functionality called via >>> JNI. >>> - Some code formatting, clean up and minor improvements where done >>> to icon and version swap code. No functional changes. >>> - Windows registry will be read and enumerated via JNI as well. >>> - isDirectoryInExclusionPath() will use native path comparison, >>> since paths in registry and temp folder returned by Java code can be >>> in short or long format, thus simple string comparison will not work. >>> - Windows Defender workaround warning will be checked for >>> --build-root as well if it is set. >>> - Removed extra escaping from JPackageHelper for Windows, otherwise >>> tests fails due to incorrect escaping. Our launcher used >>> CreateProcess to launch java.exe by passing args from main() to >>> CreateProcess. This is why I think we required extra escaping. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8217317 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ >> It basically looks good from a build perspective. There is one change >> I'd like to request, however, and that is that you place the source >> code according to the standard layout. This means moving the source >> files from src/jdk.jpackage/windows/native/jpackage to >> src/jdk.jpackage/windows/native/libjpackage. Also, when you do this, >> you don't need JPACKAGELIB_SRC; the location of the files will be >> determined by SetupJdkLibrary based on the name "jpackage" of the >> library. >> >> I'm also surprised to see that I can't find the removal of the old >> WinMain() method? >> >> /Magnus >> >> >>> >>> Thanks, >>> Alexander >> > From james.laskey at oracle.com Mon Feb 4 15:09:15 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 4 Feb 2019 11:09:15 -0400 Subject: RFR - 8212975 - ClassDesc should have a full name method Message-ID: Please review the webrev below. Though generally useful for debugging ClassDesc (or using Class::forName), ClassDesc::fullDisplayName allows compiler devs to use a ClassDesc directly to optimally add classes to the symbol table. Past: ClassDesc cd = ... String className = cd.packageName().isEmpty() ? cd.displayName() : cd.packageName() + "." + cd.displayName(); Symbol classSym = names.fromString(className); Future: ClassDesc cd = ... String className = cd.fullDisplayName(); Symbol classSym = names.fromString(className); JBS: https://bugs.openjdk.java.net/browse/JDK-8212975 webrev: http://cr.openjdk.java.net/~jlaskey/8212975/webrev/index.html From nishit.jain at oracle.com Mon Feb 4 15:31:56 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Mon, 4 Feb 2019 21:01:56 +0530 Subject: [13] RFR 8217969, 8218265: Base64.Decoder.decode methods ... and java/util/Base64/TestEncodingDecodingLength.java failing Message-ID: Hi, Please review the below fix for 8217969 and 8218265 Bug: https://bugs.openjdk.java.net/browse/JDK-8217969 ???? https://bugs.openjdk.java.net/browse/JDK-8218265 Webrev: http://cr.openjdk.java.net/~nishjain/8217969_8218265/webrev.00/ Issue: Fix for 8210583 changed the Base64.Decoder.decode to throw OOME when an integer value overflows, which is an intermediate value, not the final value, the final value is always less than Integer.MAX_VALUE. Also, the test case written for 8210583, fails on certain platforms and throws "OutOfMemoryError: Requested array size exceeds VM limit ", due to the array size of length Integer.MAX_VALUE - 2. Fix: Handled the integer overflow by storing the intermediate value as "long" and converting the final value as integer. Also, updating the test case input array length to Integer.MAX_VALUE - 8, since MAX_VALUE - 2 was used only to test the overflow condition in Decoder.decode() which is no longer there. Regards, Nishit Jain From huizhe.wang at oracle.com Mon Feb 4 17:34:40 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 04 Feb 2019 09:34:40 -0800 Subject: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false) In-Reply-To: <5C4B536C.4010003@oracle.com> References: <5C4B536C.4010003@oracle.com> Message-ID: <5C5877B0.8010907@oracle.com> Resend. Please review at your convenience. Thanks, Joe -------- Original Message -------- Subject: Re: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false) Date: Fri, 25 Jan 2019 10:20:28 -0800 From: Joe Wang Organization: Oracle Corporation To: core-libs-dev at openjdk.java.net Please review an updated webrev for this change. In the update, the change to XMLDocumentFragmentScannerImpl was to add the default value when calling getFeature at line 606 that allowed the previous commented tests to pass properly. The other change was to LSSerializerTest. Refer to the results (RESULT_TRUE and RESULT_FALSE at line 250 and 271), before the change, it outputted both entity references and the expanded text, after the change, it's either the EntityReference or Text, which makes better sense. JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/ Thanks, Joe On 1/18/19, 11:19 AM, Joe Wang wrote: > Please hold on reviewing the webrevs as the tests passed while the new > tests were commented out as Lance pointed out. > > Thanks, > Joe > > On 1/18/19, 10:05 AM, Joe Wang wrote: >> Please review a change to the DOM parser so that it complies with the >> specification with regard to the ExpandEntityReferences feature. This >> change corrects the behavior so that the resulting DOM tree includes >> EntityReference nodes but not the expanded Text nodes when the >> feature is off. It also means that the DOM parser will not attempt to >> read entity references if any. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/ >> >> Thanks, >> Joe From lance.andersen at oracle.com Mon Feb 4 17:40:58 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 4 Feb 2019 12:40:58 -0500 Subject: RFR 8182117 : Document Zip File System Properties Message-ID: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> Hi all Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8182117 which addresses the need to document the Zip File System properties and is also replacing the documentation that used to exist in the tech note: https://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html. The updated documentation can be seen below followed by the diff of the changes. ??????? Module jdk.zipfs <>Provides the implementation of the Zip file system provider. The Zip file system provider treats a Zip or JAR file as a file system providing the ability to manipulate the contents of the file. Accessing a Zip File System You can use the FileSystems newFileSystem static factory methods to create a new Zip file system or to obtain a reference to an existing Zip file system. URI Scheme Used to Identity the Zip File System The URI scheme that identifies the ZIP file system is jar. Zip File System Properties The following properties may be specified when creating a Zip file system: Property Name Data Type Default Value Description create java.lang.String false If the value is true, the Zip file system provider creates a new Zip or JAR file if it does not exist. encoding java.lang.String UTF-8 The value indicates the encoding scheme for the names of the entries in the Zip or JAR file. Examples: Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, it will be created: URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip"); Map env = Map.of("create", "true"); FileSystem zipfs = FileSystems.newFileSystem(uri, env); Construct a new Zip file system that is identified by specifying a path and using automatic file type detection. Iterate from the root of the JAR displaying each found entry: FileSystem zipfs = FileSystems.newFileSystem( Paths.get("tennisteam.jar"), null); Files.walk(zipfs.getPath("/")) .forEach(System.out::println); Since: 9 ?????????? Here is the actual diff: ??????? $ hg diff diff -r cd310319fead src/jdk.zipfs/share/classes/module-info.java --- a/src/jdk.zipfs/share/classes/module-info.java Sun Jan 27 14:55:57 2019 -0500 +++ b/src/jdk.zipfs/share/classes/module-info.java Mon Feb 04 12:30:50 2019 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -24,14 +24,87 @@ */ /** - * Provides the implementation of the zip file system provider. + * Provides the implementation of the Zip file system provider. + * The Zip file system provider treats a Zip or JAR file as a file system + * providing the ability to manipulate the contents of the file. + *

* - *

The zip file system provider treats a zip or JAR file as a file system - * and provides the ability to manipulate the contents of the file. - * The zip file system provider can be created by - * {@link java.nio.file.FileSystems#newFileSystem - * FileSystems.newFileSystem} if installed. + *

Accessing a Zip File System

* + * You can use the {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} + * static factory methods to create a new Zip file system or to obtain a reference to an + * existing Zip file system. + * + *

URI Scheme Used to Identity the Zip File System

+ * + * The URI {@link java.net.URI#getScheme scheme} that identifies the ZIP file system is {@code jar}. + * + *

Zip File System Properties

+ * + * The following properties may be specified when creating a Zip + * file system: + *

+ * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *
+ * Configurable properties that may be specified when creating + * a new Zip file system + *
Property NameData TypeDefault ValueDescription
createjava.lang.Stringfalse + * If the value is {@code true}, the Zip file system provider + * creates a new Zip or JAR file if it does not exist. + *
encodingjava.lang.StringUTF-8 + * The value indicates the encoding scheme for the + * names of the entries in the Zip or JAR file. + *
+ * + *

Examples:

+ * + * Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, + * it will be created: + *
+ * {@code
+ *
+ *     URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip");
+ *     Map env = Map.of("create", "true");
+ *     FileSystem zipfs = FileSystems.newFileSystem(uri, env);
+ * }
+ * 
+ * + * Construct a new Zip file system that is identified by specifying a path + * and using automatic file type detection. Iterate from the root of the JAR displaying each + * found entry: + *
+ * {@code
+ *
+ *     FileSystem zipfs = FileSystems.newFileSystem(
+ *            Paths.get("tennisteam.jar"), null);
+ *     Files.walk(zipfs.getPath("/"))
+ *            .forEach(System.out::println);
+ * }
+ * 
* @provides java.nio.file.spi.FileSystemProvider * @moduleGraph * @since 9 $ -------------------- 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 Feb 4 17:57:01 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 4 Feb 2019 09:57:01 -0800 Subject: [13]: RFR: 8218386: Correct the SE version in j.l.Character Message-ID: Hello, Please review this one line fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8218386 The proposed change is here: --- diff -r 213a2377b792 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 @@ -54,7 +54,7 @@ * from the Unicode Consortium at * http://www.unicode.org. *

- * The Java SE 12 Platform uses character information from version 11.0 + * The Java SE 13 Platform uses character information from version 11.0 * of the Unicode Standard, plus the Japanese Era code point, * {@code U+32FF}, from the first version of the Unicode Standard * after 11.0 that assigns the code point. --- The "Java SE 12" version string was forward ported automatically from this changeset that made into jdk12 repository: http://hg.openjdk.java.net/jdk/jdk12/rev/4f2af72cb65a which needs to be corrected. Naoto From lance.andersen at oracle.com Mon Feb 4 17:58:35 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 4 Feb 2019 12:58:35 -0500 Subject: [13]: RFR: 8218386: Correct the SE version in j.l.Character In-Reply-To: References: Message-ID: <9A0FC5AE-4D16-4EBB-8A00-63223C1957F9@oracle.com> +1 > On Feb 4, 2019, at 12:57 PM, Naoto Sato wrote: > > Hello, > > Please review this one line fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8218386 > > The proposed change is here: > > --- > diff -r 213a2377b792 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 > @@ -54,7 +54,7 @@ > * from the Unicode Consortium at > * http://www.unicode.org. > *

> - * The Java SE 12 Platform uses character information from version 11.0 > + * The Java SE 13 Platform uses character information from version 11.0 > * of the Unicode Standard, plus the Japanese Era code point, > * {@code U+32FF}, from the first version of the Unicode Standard > * after 11.0 that assigns the code point. > --- > > The "Java SE 12" version string was forward ported automatically from this changeset that made into jdk12 repository: > > http://hg.openjdk.java.net/jdk/jdk12/rev/4f2af72cb65a > > which needs to be corrected. > > Naoto 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 Feb 4 18:18:10 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 4 Feb 2019 13:18:10 -0500 Subject: [13] RFR 8217969, 8218265: Base64.Decoder.decode methods ... and java/util/Base64/TestEncodingDecodingLength.java failing In-Reply-To: References: Message-ID: <8019d149-a62d-a385-7ebd-16e72f0acb28@oracle.com> Hi Nishit, Looks fine. Thanks for fixing the test and improving the implementation. The test could save one 2G allocation by using ByteBuffer.wrap(inputBytes) instead of ByteBuffer.allocate(size). Thanks, Roger On 02/04/2019 10:31 AM, Nishit Jain wrote: > Hi, > > Please review the below fix for 8217969 and 8218265 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217969 > ???? https://bugs.openjdk.java.net/browse/JDK-8218265 > > Webrev: http://cr.openjdk.java.net/~nishjain/8217969_8218265/webrev.00/ > > Issue: Fix for 8210583 changed the Base64.Decoder.decode to throw OOME > when an integer value overflows, which is an intermediate value, not > the final value, the final value is always less than > Integer.MAX_VALUE. Also, the test case written for 8210583, fails on > certain platforms and throws "OutOfMemoryError: Requested array size > exceeds VM limit ", due to the array size of length Integer.MAX_VALUE > - 2. > > Fix: Handled the integer overflow by storing the intermediate value as > "long" and converting the final value as integer. Also, updating the > test case input array length to Integer.MAX_VALUE - 8, since MAX_VALUE > - 2 was used only to test the overflow condition in Decoder.decode() > which is no longer there. > > Regards, > Nishit Jain From naoto.sato at oracle.com Mon Feb 4 18:33:54 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 4 Feb 2019 10:33:54 -0800 Subject: [13] RFR 8217969, 8218265: Base64.Decoder.decode methods ... and java/util/Base64/TestEncodingDecodingLength.java failing In-Reply-To: <8019d149-a62d-a385-7ebd-16e72f0acb28@oracle.com> References: <8019d149-a62d-a385-7ebd-16e72f0acb28@oracle.com> Message-ID: +1 Naoto On 2/4/19 10:18 AM, Roger Riggs wrote: > Hi Nishit, > > Looks fine. > > Thanks for fixing the test and improving the implementation. > > The test could save one 2G allocation by using ByteBuffer.wrap(inputBytes) > instead of ByteBuffer.allocate(size). > > Thanks, Roger > > > > On 02/04/2019 10:31 AM, Nishit Jain wrote: >> Hi, >> >> Please review the below fix for 8217969 and 8218265 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217969 >> ???? https://bugs.openjdk.java.net/browse/JDK-8218265 >> >> Webrev: http://cr.openjdk.java.net/~nishjain/8217969_8218265/webrev.00/ >> >> Issue: Fix for 8210583 changed the Base64.Decoder.decode to throw OOME >> when an integer value overflows, which is an intermediate value, not >> the final value, the final value is always less than >> Integer.MAX_VALUE. Also, the test case written for 8210583, fails on >> certain platforms and throws "OutOfMemoryError: Requested array size >> exceeds VM limit ", due to the array size of length Integer.MAX_VALUE >> - 2. >> >> Fix: Handled the integer overflow by storing the intermediate value as >> "long" and converting the final value as integer. Also, updating the >> test case input array length to Integer.MAX_VALUE - 8, since MAX_VALUE >> - 2 was used only to test the overflow condition in Decoder.decode() >> which is no longer there. >> >> Regards, >> Nishit Jain > From Roger.Riggs at oracle.com Mon Feb 4 18:38:02 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 4 Feb 2019 13:38:02 -0500 Subject: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false) In-Reply-To: <5C5877B0.8010907@oracle.com> References: <5C4B536C.4010003@oracle.com> <5C5877B0.8010907@oracle.com> Message-ID: <3d6a7113-3287-5355-c604-d61e4b3c684e@oracle.com> Hi Joe, Looks good. Roger On 02/04/2019 12:34 PM, Joe Wang wrote: > Resend. Please review at your convenience. > > Thanks, > Joe > > -------- Original Message -------- > Subject:???? Re: RFR(JDK 13/java.xml) 8206132: DOM parser does not > honor DocumentBuilderFactory.setExpandEntityReferences(false) > Date:???? Fri, 25 Jan 2019 10:20:28 -0800 > From:???? Joe Wang > Organization:???? Oracle Corporation > To:???? core-libs-dev at openjdk.java.net > > > > Please review an updated webrev for this change. In the update, the > change to XMLDocumentFragmentScannerImpl was to add the default value > when calling getFeature at line 606 that allowed the previous commented > tests to pass properly. The other change was to LSSerializerTest. Refer > to the results (RESULT_TRUE and RESULT_FALSE at line 250 and 271), > before the change, it outputted both entity references and the expanded > text, after the change, it's either the EntityReference or Text, which > makes better sense. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/ > > Thanks, > Joe > > On 1/18/19, 11:19 AM, Joe Wang wrote: >> ?Please hold on reviewing the webrevs as the tests passed while the new >> ?tests were commented out as Lance pointed out. >> >> ?Thanks, >> ?Joe >> >> ?On 1/18/19, 10:05 AM, Joe Wang wrote: >>> ?Please review a change to the DOM parser so that it complies with the >>> ?specification with regard to the ExpandEntityReferences feature. This >>> ?change? corrects the behavior so that the resulting DOM tree includes >>> ?EntityReference nodes but not the expanded Text nodes when the >>> ?feature is off. It also means that the DOM parser will not attempt to >>> ?read entity references if any. >>> >>> ?JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 >>> ?webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/ >>> >>> ?Thanks, >>> ?Joe > From Roger.Riggs at oracle.com Mon Feb 4 18:50:15 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 4 Feb 2019 13:50:15 -0500 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> Message-ID: <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> Hi Lance, That looks ok; editorial suggestions below: On 02/04/2019 12:40 PM, Lance Andersen wrote: > Hi all > > Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8182117 which addresses the need to document the Zip File System properties and is also replacing the documentation that used to exist in the tech note: https://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html. > > The updated documentation can be seen below followed by the diff of the changes. > > > ??????? > Module jdk.zipfs > > <>Provides the implementation of the Zip file system provider. The Zip file system provider treats a Zip or JAR file as a file system providing the ability to manipulate the contents of the file. > > Accessing a Zip File System > > You can use the FileSystems newFileSystem static factory methods to create a new Zip file system or to obtain a reference to an existing Zip file system. > URI Scheme Used to Identity the Zip File System > > The URI scheme that identifies the ZIP file system is jar. > Zip File System Properties > > The following properties may be specified when creating a Zip file system: > > Property Name Data Type Default Value Description > create java.lang.String false If the value is true, the Zip file system provider creates a new Zip or JAR file if it does not exist. > encoding java.lang.String UTF-8 The value indicates the encoding scheme for the names of the entries in the Zip or JAR file. > Examples: > > Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, it will be created: > > > URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip"); > Map env = Map.of("create", "true"); > FileSystem zipfs = FileSystems.newFileSystem(uri, env); > > > Construct a new Zip file system that is identified by specifying a path and using automatic file type detection. Iterate from the root of the JAR displaying each found entry: > > > FileSystem zipfs = FileSystems.newFileSystem( > Paths.get("tennisteam.jar"), null); > Files.walk(zipfs.getPath("/")) > .forEach(System.out::println); > > > Since: > 9 > > ?????????? > > Here is the actual diff: > > ??????? > $ hg diff > diff -r cd310319fead src/jdk.zipfs/share/classes/module-info.java > --- a/src/jdk.zipfs/share/classes/module-info.java Sun Jan 27 14:55:57 2019 -0500 > +++ b/src/jdk.zipfs/share/classes/module-info.java Mon Feb 04 12:30:50 2019 -0500 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -24,14 +24,87 @@ > */ > > /** > - * Provides the implementation of the zip file system provider. > + * Provides the implementation of the Zip file system provider. > + * The Zip file system provider treats a Zip or JAR file as a file system > + * providing the ability to manipulate the contents of the file. Remove " of the file" so it reads: ??? "providing the ability to manipulate the contents. " > + *

> * > - *

The zip file system provider treats a zip or JAR file as a file system > - * and provides the ability to manipulate the contents of the file. > - * The zip file system provider can be created by > - * {@link java.nio.file.FileSystems#newFileSystem > - * FileSystems.newFileSystem} if installed. > + *

Accessing a Zip File System

> * > + * You can use the {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} Third person seems more appropriate: + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} > + * static factory methods ^^ to create a new Zip file system or to obtain a reference to an can be used > + * existing Zip file system. > + * > + *

URI Scheme Used to Identity the Zip File System

> + * > + * The URI {@link java.net.URI#getScheme scheme} that identifies the ZIP file system is {@code jar}. > + * > + *

Zip File System Properties

> + * > + * The following properties may be specified when creating a Zip > + * file system: > + *

> + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + *
> + * Configurable properties that may be specified when creating > + * a new Zip file system > + *
Property NameData TypeDefault ValueDescription
createjava.lang.Stringfalse > + * If the value is {@code true}, the Zip file system provider > + * creates a new Zip or JAR file if it does not exist. > + *
encodingjava.lang.StringUTF-8 > + * The value indicates the encoding scheme for the > + * names of the entries in the Zip or JAR file. > + *
> + * > + *

Examples:

> + * > + * Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, > + * it will be created: > + *
> + * {@code
> + *
> + *     URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip");
> + *     Map env = Map.of("create", "true");
> + *     FileSystem zipfs = FileSystems.newFileSystem(uri, env);
> + * }
> + * 
> + * > + * Construct a new Zip file system that is identified by specifying a path > + * and using automatic file type detection. Iterate from the root of the JAR displaying each > + * found entry: > + *
> + * {@code
> + *
> + *     FileSystem zipfs = FileSystems.newFileSystem(
> + *            Paths.get("tennisteam.jar"), null);
> + *     Files.walk(zipfs.getPath("/"))
> + *            .forEach(System.out::println);
> + * }
> + * 
> * @provides java.nio.file.spi.FileSystemProvider > * @moduleGraph > * @since 9 > $ > -------------------- > > > 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 Mon Feb 4 19:00:27 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 4 Feb 2019 14:00:27 -0500 Subject: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false) In-Reply-To: <5C5877B0.8010907@oracle.com> References: <5C4B536C.4010003@oracle.com> <5C5877B0.8010907@oracle.com> Message-ID: <019F817A-2F59-4DEC-9635-400254B4D424@oracle.com> Hi Joe +1 > On Feb 4, 2019, at 12:34 PM, Joe Wang wrote: > > Resend. Please review at your convenience. > > Thanks, > Joe > > -------- Original Message -------- > Subject: Re: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false) > Date: Fri, 25 Jan 2019 10:20:28 -0800 > From: Joe Wang > Organization: Oracle Corporation > To: core-libs-dev at openjdk.java.net > > > > Please review an updated webrev for this change. In the update, the > change to XMLDocumentFragmentScannerImpl was to add the default value > when calling getFeature at line 606 that allowed the previous commented > tests to pass properly. The other change was to LSSerializerTest. Refer > to the results (RESULT_TRUE and RESULT_FALSE at line 250 and 271), > before the change, it outputted both entity references and the expanded > text, after the change, it's either the EntityReference or Text, which > makes better sense. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/ > > Thanks, > Joe > > On 1/18/19, 11:19 AM, Joe Wang wrote: >> Please hold on reviewing the webrevs as the tests passed while the new >> tests were commented out as Lance pointed out. >> >> Thanks, >> Joe >> >> On 1/18/19, 10:05 AM, Joe Wang wrote: >>> Please review a change to the DOM parser so that it complies with the >>> specification with regard to the ExpandEntityReferences feature. This >>> change corrects the behavior so that the resulting DOM tree includes >>> EntityReference nodes but not the expanded Text nodes when the >>> feature is off. It also means that the DOM parser will not attempt to >>> read entity references if any. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/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 Roger.Riggs at oracle.com Mon Feb 4 19:32:36 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 4 Feb 2019 14:32:36 -0500 Subject: RFR 8218227 : StringBuilder constructor throws confusing NegativeArraySizeException In-Reply-To: References: Message-ID: Hi Ivan, A good boundary condition to clean up. Should tests for StringBuffer be added too? Maxing out the length at MAX_VALUE must always result in an OOM. If such an allocation were to succeed, it would violate the specified initial capacity requirement. Thanks, Roger On 02/02/2019 02:28 AM, Ivan Gerasimov wrote: > Hello! > > The spec of the constructors > StringBuilder(String)/StringBuilder(CharSequence) states that the > initial capacity of the builder will be set to the length of the > argument plus 16. > This causes them to throw confusing NegativeArraySizeException when > the argument's length is close to Integer.MAX_VALUE. > > Let the arguments length be (Integer.MAX_VALUE - DELTA), like in the > code below: > > ??????? String str = "Z".repeat(Integer.MAX_VALUE - DELTA); > ??????? StringBuilder sb = new StringBuilder(str); > > Currently the behavior is as following: > ??? 0 <= DELTA <= 2 - unable to construct str, > ??? 2 <= DELTA <= 15 - NegativeArraySizeException is thrown, > ??? 16 <= DELTA <= 17 - OutOfMemoryError is thrown, > ??? DELTA >= 18 - works fine. > > With the fix, OOM will be thrown for all DELTA <= 17. > > Also the fix will make constructing a StringBuilder from UTF16 coded > String slightly more efficient. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218227 > WEBREV: http://cr.openjdk.java.net/~igerasim/8218227/00/webrev/ > > Would you please help review the fix? > From lance.andersen at oracle.com Mon Feb 4 19:36:38 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 4 Feb 2019 14:36:38 -0500 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> Message-ID: <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> Hi Roger, I made the suggested changes, thank you for the input ????? $ hg diff diff -r 213a2377b792 src/jdk.zipfs/share/classes/module-info.java --- a/src/jdk.zipfs/share/classes/module-info.java Mon Feb 04 11:00:12 2019 +0100 +++ b/src/jdk.zipfs/share/classes/module-info.java Mon Feb 04 14:34:13 2019 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -24,14 +24,87 @@ */ /** - * Provides the implementation of the zip file system provider. + * Provides the implementation of the Zip file system provider. + * The Zip file system provider treats a Zip or JAR file as a file system + * providing the ability to manipulate its contents. + *

* - *

The zip file system provider treats a zip or JAR file as a file system - * and provides the ability to manipulate the contents of the file. - * The zip file system provider can be created by - * {@link java.nio.file.FileSystems#newFileSystem - * FileSystems.newFileSystem} if installed. + *

Accessing a Zip File System

* + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} + * static factory methods can be used to create a new Zip file system or to + * obtain a reference to an existing Zip file system. + * + *

URI Scheme Used to Identity the Zip File System

+ * + * The URI {@link java.net.URI#getScheme scheme} that identifies the ZIP file system is {@code jar}. + * + *

Zip File System Properties

+ * + * The following properties may be specified when creating a Zip + * file system: + *

+ * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *
+ * Configurable properties that may be specified when creating + * a new Zip file system + *
Property NameData TypeDefault ValueDescription
createjava.lang.Stringfalse + * If the value is {@code true}, the Zip file system provider + * creates a new Zip or JAR file if it does not exist. + *
encodingjava.lang.StringUTF-8 + * The value indicates the encoding scheme for the + * names of the entries in the Zip or JAR file. + *
+ * + *

Examples:

+ * + * Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, + * it will be created: + *
+ * {@code
+ *
+ *     URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip");
+ *     Map env = Map.of("create", "true");
+ *     FileSystem zipfs = FileSystems.newFileSystem(uri, env);
+ * }
+ * 
+ * + * Construct a new Zip file system that is identified by specifying a path + * and using automatic file type detection. Iterate from the root of the JAR displaying each + * found entry: + *
+ * {@code
+ *
+ *     FileSystem zipfs = FileSystems.newFileSystem(
+ *            Paths.get("tennisteam.jar"), null);
+ *     Files.walk(zipfs.getPath("/"))
+ *            .forEach(System.out::println);
+ * }
+ * 
* @provides java.nio.file.spi.FileSystemProvider * @moduleGraph * @since 9 $ --------------- > On Feb 4, 2019, at 1:50 PM, Roger Riggs wrote: > > Hi Lance, > > That looks ok; editorial suggestions below: > > > On 02/04/2019 12:40 PM, Lance Andersen wrote: >> Hi all >> >> Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8182117 which addresses the need to document the Zip File System properties and is also replacing the documentation that used to exist in the tech note: https://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html. >> >> The updated documentation can be seen below followed by the diff of the changes. >> >> >> ??????? >> Module jdk.zipfs >> >> <>Provides the implementation of the Zip file system provider. The Zip file system provider treats a Zip or JAR file as a file system providing the ability to manipulate the contents of the file. >> >> Accessing a Zip File System >> >> You can use the FileSystems newFileSystem static factory methods to create a new Zip file system or to obtain a reference to an existing Zip file system. >> URI Scheme Used to Identity the Zip File System >> >> The URI scheme that identifies the ZIP file system is jar. >> Zip File System Properties >> >> The following properties may be specified when creating a Zip file system: >> >> Property Name Data Type Default Value Description >> create java.lang.String false If the value is true, the Zip file system provider creates a new Zip or JAR file if it does not exist. >> encoding java.lang.String UTF-8 The value indicates the encoding scheme for the names of the entries in the Zip or JAR file. >> Examples: >> >> Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, it will be created: >> >> URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip"); >> Map env = Map.of("create", "true"); >> FileSystem zipfs = FileSystems.newFileSystem(uri, env); >> Construct a new Zip file system that is identified by specifying a path and using automatic file type detection. Iterate from the root of the JAR displaying each found entry: >> >> FileSystem zipfs = FileSystems.newFileSystem( >> Paths.get("tennisteam.jar"), null); >> Files.walk(zipfs.getPath("/")) >> .forEach(System.out::println); >> Since: >> 9 >> >> ?????????? >> >> Here is the actual diff: >> >> ??????? >> $ hg diff >> diff -r cd310319fead src/jdk.zipfs/share/classes/module-info.java >> --- a/src/jdk.zipfs/share/classes/module-info.java Sun Jan 27 14:55:57 2019 -0500 >> +++ b/src/jdk.zipfs/share/classes/module-info.java Mon Feb 04 12:30:50 2019 -0500 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -24,14 +24,87 @@ >> */ >> /** >> - * Provides the implementation of the zip file system provider. >> + * Provides the implementation of the Zip file system provider. >> + * The Zip file system provider treats a Zip or JAR file as a file system >> + * providing the ability to manipulate the contents of the file. > Remove " of the file" so it reads: > "providing the ability to manipulate the contents. " >> + *

>> * >> - *

The zip file system provider treats a zip or JAR file as a file system >> - * and provides the ability to manipulate the contents of the file. >> - * The zip file system provider can be created by >> - * {@link java.nio.file.FileSystems#newFileSystem >> - * FileSystems.newFileSystem} if installed. >> + *

Accessing a Zip File System

>> * >> + * You can use the {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} > Third person seems more appropriate: > > + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} > > >> + * static factory methods ^^ to create a new Zip file system or to obtain a reference to an > can be used >> + * existing Zip file system. >> + * >> + *

URI Scheme Used to Identity the Zip File System

>> + * >> + * The URI {@link java.net.URI#getScheme scheme} that identifies the ZIP file system is {@code jar}. >> + * >> + *

Zip File System Properties

>> + * >> + * The following properties may be specified when creating a Zip >> + * file system: >> + *

>> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + * >> + *
>> + * Configurable properties that may be specified when creating >> + * a new Zip file system >> + *
Property NameData TypeDefault ValueDescription
createjava.lang.Stringfalse >> + * If the value is {@code true}, the Zip file system provider >> + * creates a new Zip or JAR file if it does not exist. >> + *
encodingjava.lang.StringUTF-8 >> + * The value indicates the encoding scheme for the >> + * names of the entries in the Zip or JAR file. >> + *
>> + * >> + *

Examples:

>> + * >> + * Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, >> + * it will be created: >> + *
>> + * {@code
>> + *
>> + *     URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip");
>> + *     Map env = Map.of("create", "true");
>> + *     FileSystem zipfs = FileSystems.newFileSystem(uri, env);
>> + * }
>> + * 
>> + * >> + * Construct a new Zip file system that is identified by specifying a path >> + * and using automatic file type detection. Iterate from the root of the JAR displaying each >> + * found entry: >> + *
>> + * {@code
>> + *
>> + *     FileSystem zipfs = FileSystems.newFileSystem(
>> + *            Paths.get("tennisteam.jar"), null);
>> + *     Files.walk(zipfs.getPath("/"))
>> + *            .forEach(System.out::println);
>> + * }
>> + * 
>> * @provides java.nio.file.spi.FileSystemProvider >> * @moduleGraph >> * @since 9 >> $ >> -------------------- >> >> >> 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 Roger.Riggs at oracle.com Mon Feb 4 19:38:16 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 4 Feb 2019 14:38:16 -0500 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> Message-ID: <8f875cda-366b-fa58-36a0-4a6974f8ba8e@oracle.com> Looks good. Thanks, Roger On 02/04/2019 02:36 PM, Lance Andersen wrote: > Hi Roger, > > I made the suggested changes, thank you for the input > > ????? > $ hg diff > diff -r 213a2377b792 src/jdk.zipfs/share/classes/module-info.java > --- a/src/jdk.zipfs/share/classes/module-info.javaMon Feb 04 11:00:12 > 2019 +0100 > +++ b/src/jdk.zipfs/share/classes/module-info.javaMon Feb 04 14:34:13 > 2019 -0500 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -24,14 +24,87 @@ > ? */ > > > ?/** > - * Provides the implementation of the zip file system provider. > + * Provides the implementation of the Zip file system provider. > + * The Zip file system provider treats a Zip or JAR file as a file system > + * providing the ability to manipulate its contents. > + *

> ? * > - *

The zip file system provider treats a zip or JAR file as a > file system > - * and provides the ability to manipulate the contents of the file. > - * The zip file system provider can be created by > - * {@link java.nio.file.FileSystems#newFileSystem > - * FileSystems.newFileSystem} if installed. > + *

Accessing a Zip File System

> ? * > + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code > newFileSystem} > + * static factory methods can be used to create a new Zip file system > or to > + * obtain a reference to an existing Zip file system. > + * > + *

URI Scheme Used to Identity the Zip File System

> + * > + * The URI {@link java.net.URI#getScheme scheme} that identifies the > ZIP file system is {@code jar}. > + * > + *

Zip File System Properties

> + * > + * The following properties may be specified when creating a Zip > + * file system: > + *

> + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * ? > + * > + * > + * ? > + * > + * > + * ? > + * > + * > + * ? > + * > + * > + *
> + * ? ? Configurable properties that may be specified when creating > + * ? ? a new Zip file system > + *
Property NameData TypeDefault ValueDescription
createjava.lang.Stringfalse > + * ? ? ? If the value is {@code true}, the Zip file system provider > + * ? ? ? creates a new Zip or JAR file if it does not exist. > + * ?
encodingjava.lang.StringUTF-8 > + * ? ? ? The value indicates the encoding scheme for the > + * ? ? ? names of the entries in the Zip or JAR file. > + * ?
> + * > + *

Examples:

> + * > + * Construct a new Zip file system that is identified by a URI.? If > the Zip file does not exist, > + * it will be created: > + *
> + * {@code
> + *
> + * ? ? URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip");
> + * ? ? Map env = Map.of("create", "true");
> + * ? ? FileSystem zipfs = FileSystems.newFileSystem(uri, env);
> + * }
> + * 
> + * > + * Construct a new Zip file system that is identified by specifying a > path > + * and using automatic file type detection. Iterate from the root of > the JAR displaying each > + * found entry: > + *
> + * {@code
> + *
> + * ? ? FileSystem zipfs = FileSystems.newFileSystem(
> + * Paths.get("tennisteam.jar"), null);
> + * Files.walk(zipfs.getPath("/"))
> + * .forEach(System.out::println);
> + * }
> + * 
> ? * @provides java.nio.file.spi.FileSystemProvider > ? * @moduleGraph > ? * @since 9 > $ > --------------- >> On Feb 4, 2019, at 1:50 PM, Roger Riggs > > wrote: >> >> Hi Lance, >> >> That looks ok; editorial suggestions below: >> >> >> On 02/04/2019 12:40 PM, Lance Andersen wrote: >>> Hi all >>> >>> Please review the fix for >>> https://bugs.openjdk.java.net/browse/JDK-8182117 >>> which addresses >>> the need to document the Zip File System properties and is also >>> ?replacing the documentation that used to exist in the tech note: >>> https://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html. >>> >>> The updated documentation can be seen below followed by the diff of >>> the changes. >>> >>> >>> ??????? >>> Module jdk.zipfs >>> >>> ?<>Provides the implementation of the Zip file system provider. The >>> Zip file system provider treats a Zip or JAR file as a file system >>> providing the ability to manipulate the contents of the file. >>> >>> Accessing a Zip File System >>> >>> You can use the FileSystems >>> >>> newFileSystem static factory methods to create a new Zip file system >>> or to obtain a reference to an existing Zip file system. >>> URI Scheme Used to Identity the Zip File System >>> >>> The URI scheme >>> >> > >>> that identifies the ZIP file system is jar. >>> Zip File System Properties >>> >>> The following properties may be specified when creating a Zip file >>> system: >>> >>> Property NameData TypeDefault ValueDescription >>> createjava.lang.StringfalseIf the value is true, the Zip file system >>> provider creates a new Zip or JAR file if it does not exist. >>> encodingjava.lang.StringUTF-8The value indicates the encoding scheme >>> for the names of the entries in the Zip or JAR file. >>> Examples: >>> >>> Construct a new Zip file system that is identified by a URI. If the >>> Zip file does not exist, it will be created: >>> >>> ?????URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip"); >>> ?????Map env = Map.of("create", "true"); >>> ?????FileSystem zipfs = FileSystems.newFileSystem(uri, env); >>> ???Construct a new Zip file system that is identified by specifying >>> a path and using automatic file type detection. Iterate from the >>> root of the JAR displaying each found entry: >>> >>> ?????FileSystem zipfs = FileSystems.newFileSystem( >>> ????????????Paths.get("tennisteam.jar"), null); >>> ?????Files.walk(zipfs.getPath("/")) >>> ????????????.forEach(System.out::println); >>> ???Since: >>> 9 >>> >>> ?????????? >>> >>> Here is the actual diff: >>> >>> ??????? >>> $ hg diff >>> diff -r cd310319fead src/jdk.zipfs/share/classes/module-info.java >>> --- a/src/jdk.zipfs/share/classes/module-info.javaSun Jan 27 >>> 14:55:57 2019 -0500 >>> +++ b/src/jdk.zipfs/share/classes/module-info.javaMon Feb 04 >>> 12:30:50 2019 -0500 >>> @@ -1,5 +1,5 @@ >>> ?/* >>> - * Copyright (c) 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All >>> rights reserved. >>> ??* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> ??* >>> ??* This code is free software; you can redistribute it and/or modify it >>> @@ -24,14 +24,87 @@ >>> ??*/ >>> ???/** >>> - * Provides the implementation of the zip file system provider. >>> + * Provides the implementation of the Zip file system provider. >>> + * The Zip file system provider treats a Zip or JAR file as a file >>> system >>> + * providing the ability to manipulate the contents of the file. >> Remove " of the file" so it reads: >> ??? "providing the ability to manipulate the contents. " >>> + *

>>> ??* >>> - *

The zip file system provider treats a zip or JAR file as a >>> file system >>> - * and provides the ability to manipulate the contents of the file. >>> - * The zip file system provider can be created by >>> - * {@link java.nio.file.FileSystems#newFileSystem >>> - * FileSystems.newFileSystem} if installed. >>> + *

Accessing a Zip File System

>>> ??* >>> + * You can use the {@linkplain java.nio.file.FileSystems >>> FileSystems} {@code newFileSystem} >> Third person seems more appropriate: >> >> + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code >> newFileSystem} >> >> >>> + * static factory methods ^^ to create a new Zip file system or to >>> obtain a reference to an >> can be used >>> + * existing Zip file system. >>> + * >>> + *

URI Scheme Used to Identity the Zip File System

>>> + * >>> + * The URI {@link java.net.URI#getScheme scheme} that identifies >>> the ZIP file system is {@code jar}. >>> + * >>> + *

Zip File System Properties

>>> + * >>> + * The following properties may be specified when creating a Zip >>> + * file system: >>> + *

>>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * ?? >>> + * ?? >>> + * ?? >>> + * ?? >>> + * >>> + * >>> + * ?? >>> + * ?? >>> + * ?? >>> + * ?? >>> + * >>> + * >>> + *
>>> + * ????Configurable properties that may be specified when creating >>> + * ????a new Zip file system >>> + *
Property NameData TypeDefault ValueDescription
createjava.lang.Stringfalse >>> + * ??????If the value is {@code true}, the Zip file system provider >>> + * ??????creates a new Zip or JAR file if it does not exist. >>> + * ??
encodingjava.lang.StringUTF-8 >>> + * ??????The value indicates the encoding scheme for the >>> + * ??????names of the entries in the Zip or JAR file. >>> + * ??
>>> + * >>> + *

Examples:

>>> + * >>> + * Construct a new Zip file system that is identified by a URI. ?If >>> the Zip file does not exist, >>> + * it will be created: >>> + *
>>> + * {@code
>>> + *
>>> + * ????URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip");
>>> + * ????Map env = Map.of("create", "true");
>>> + * ????FileSystem zipfs = FileSystems.newFileSystem(uri, env);
>>> + * }
>>> + * 
>>> + * >>> + * Construct a new Zip file system that is identified by specifying >>> a path >>> + * and using automatic file type detection. Iterate from the root >>> of the JAR displaying each >>> + * found entry: >>> + *
>>> + * {@code
>>> + *
>>> + * ????FileSystem zipfs = FileSystems.newFileSystem(
>>> + * ???????????Paths.get("tennisteam.jar"), null);
>>> + * ????Files.walk(zipfs.getPath("/"))
>>> + * ???????????.forEach(System.out::println);
>>> + * }
>>> + * 
>>> ??* @provides java.nio.file.spi.FileSystemProvider >>> ??* @moduleGraph >>> ??* @since 9 >>> $ >>> -------------------- >>> ? >>> ? >>> >>> ?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 ivan.gerasimov at oracle.com Mon Feb 4 21:25:48 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 4 Feb 2019 13:25:48 -0800 Subject: RFR 8218227 : StringBuilder constructor throws confusing NegativeArraySizeException In-Reply-To: References: Message-ID: <70135128-54af-83f8-9290-bd86d30178d3@oracle.com> Thank you Roger for reviewing! On 2/4/19 11:32 AM, Roger Riggs wrote: > Hi Ivan, > > A good boundary condition to clean up. > > Should tests for StringBuffer be added too? > Yes, let's add them. Please find the updated webrev here: http://cr.openjdk.java.net/~igerasim/8218227/01/webrev/ With kind regards, Ivan > Maxing out the length at MAX_VALUE must always result in an OOM. > If such an allocation were to succeed, it would violate the specified > initial capacity requirement. > > Thanks, Roger > > > On 02/02/2019 02:28 AM, Ivan Gerasimov wrote: >> Hello! >> >> The spec of the constructors >> StringBuilder(String)/StringBuilder(CharSequence) states that the >> initial capacity of the builder will be set to the length of the >> argument plus 16. >> This causes them to throw confusing NegativeArraySizeException when >> the argument's length is close to Integer.MAX_VALUE. >> >> Let the arguments length be (Integer.MAX_VALUE - DELTA), like in the >> code below: >> >> String str = "Z".repeat(Integer.MAX_VALUE - DELTA); >> StringBuilder sb = new StringBuilder(str); >> >> Currently the behavior is as following: >> 0 <= DELTA <= 2 - unable to construct str, >> 2 <= DELTA <= 15 - NegativeArraySizeException is thrown, >> 16 <= DELTA <= 17 - OutOfMemoryError is thrown, >> DELTA >= 18 - works fine. >> >> With the fix, OOM will be thrown for all DELTA <= 17. >> >> Also the fix will make constructing a StringBuilder from UTF16 coded >> String slightly more efficient. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218227 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8218227/00/webrev/ >> >> Would you please help review the fix? >> > > -- With kind regards, Ivan Gerasimov From Roger.Riggs at oracle.com Mon Feb 4 21:39:05 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 4 Feb 2019 16:39:05 -0500 Subject: RFR 8218227 : StringBuilder constructor throws confusing NegativeArraySizeException In-Reply-To: <70135128-54af-83f8-9290-bd86d30178d3@oracle.com> References: <70135128-54af-83f8-9290-bd86d30178d3@oracle.com> Message-ID: <25024183-7910-d284-1f2c-d5c1a9803afb@oracle.com> Hi Ivan, Can we put the new StringBuffer tests into the existing StringBuffer.Capacity.java test? It can help keep functional test pieces to together and not create n+1 files. Looking back I would have preferred the same for the StringBuilder.Huge tests. There is a Capacity.java test there too.? But the tests have diverged. Thanks, Roger On 02/04/2019 04:25 PM, Ivan Gerasimov wrote: > Thank you Roger for reviewing! > > > On 2/4/19 11:32 AM, Roger Riggs wrote: >> Hi Ivan, >> >> A good boundary condition to clean up. >> >> Should tests for StringBuffer be added too? >> > Yes, let's add them. > > Please find the updated webrev here: > http://cr.openjdk.java.net/~igerasim/8218227/01/webrev/ > > With kind regards, > Ivan > >> Maxing out the length at MAX_VALUE must always result in an OOM. >> If such an allocation were to succeed, it would violate the specified >> initial capacity requirement. >> >> Thanks, Roger >> >> >> On 02/02/2019 02:28 AM, Ivan Gerasimov wrote: >>> Hello! >>> >>> The spec of the constructors >>> StringBuilder(String)/StringBuilder(CharSequence) states that the >>> initial capacity of the builder will be set to the length of the >>> argument plus 16. >>> This causes them to throw confusing NegativeArraySizeException when >>> the argument's length is close to Integer.MAX_VALUE. >>> >>> Let the arguments length be (Integer.MAX_VALUE - DELTA), like in the >>> code below: >>> >>> ??????? String str = "Z".repeat(Integer.MAX_VALUE - DELTA); >>> ??????? StringBuilder sb = new StringBuilder(str); >>> >>> Currently the behavior is as following: >>> ??? 0 <= DELTA <= 2 - unable to construct str, >>> ??? 2 <= DELTA <= 15 - NegativeArraySizeException is thrown, >>> ??? 16 <= DELTA <= 17 - OutOfMemoryError is thrown, >>> ??? DELTA >= 18 - works fine. >>> >>> With the fix, OOM will be thrown for all DELTA <= 17. >>> >>> Also the fix will make constructing a StringBuilder from UTF16 coded >>> String slightly more efficient. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218227 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218227/00/webrev/ >>> >>> Would you please help review the fix? >>> >> >> > From mandy.chung at oracle.com Mon Feb 4 21:44:12 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 4 Feb 2019 13:44:12 -0800 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> Message-ID: This looks good. Sherman added a comment on "encoding" which he thinks it may be downloaded as undocumented. You may want to create a JBS issue to revisit that in the future. thanks Mandy On 2/4/19 11:36 AM, Lance Andersen wrote: > Hi Roger, > > I made the suggested changes, thank you for the input > > ????? > $ hg diff > diff -r 213a2377b792 src/jdk.zipfs/share/classes/module-info.java > --- a/src/jdk.zipfs/share/classes/module-info.java Mon Feb 04 11:00:12 2019 +0100 > +++ b/src/jdk.zipfs/share/classes/module-info.java Mon Feb 04 14:34:13 2019 -0500 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -24,14 +24,87 @@ > */ > > /** > - * Provides the implementation of the zip file system provider. > + * Provides the implementation of the Zip file system provider. > + * The Zip file system provider treats a Zip or JAR file as a file system > + * providing the ability to manipulate its contents. > + *

> * > - *

The zip file system provider treats a zip or JAR file as a file system > - * and provides the ability to manipulate the contents of the file. > - * The zip file system provider can be created by > - * {@link java.nio.file.FileSystems#newFileSystem > - * FileSystems.newFileSystem} if installed. > + *

Accessing a Zip File System

> * > + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} > + * static factory methods can be used to create a new Zip file system or to > + * obtain a reference to an existing Zip file system. > + * > + *

URI Scheme Used to Identity the Zip File System

> + * > + * The URI {@link java.net.URI#getScheme scheme} that identifies the ZIP file system is {@code jar}. > + * > + *

Zip File System Properties

> + * > + * The following properties may be specified when creating a Zip > + * file system: > + *

> + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + * > + *
> + * Configurable properties that may be specified when creating > + * a new Zip file system > + *
Property NameData TypeDefault ValueDescription
createjava.lang.Stringfalse > + * If the value is {@code true}, the Zip file system provider > + * creates a new Zip or JAR file if it does not exist. > + *
encodingjava.lang.StringUTF-8 > + * The value indicates the encoding scheme for the > + * names of the entries in the Zip or JAR file. > + *
> + * > + *

Examples:

> + * > + * Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, > + * it will be created: > + *
> + * {@code
> + *
> + *     URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip");
> + *     Map env = Map.of("create", "true");
> + *     FileSystem zipfs = FileSystems.newFileSystem(uri, env);
> + * }
> + * 
> + * > + * Construct a new Zip file system that is identified by specifying a path > + * and using automatic file type detection. Iterate from the root of the JAR displaying each > + * found entry: > + *
> + * {@code
> + *
> + *     FileSystem zipfs = FileSystems.newFileSystem(
> + *            Paths.get("tennisteam.jar"), null);
> + *     Files.walk(zipfs.getPath("/"))
> + *            .forEach(System.out::println);
> + * }
> + * 
> * @provides java.nio.file.spi.FileSystemProvider > * @moduleGraph > * @since 9 > $ > --------------- >> On Feb 4, 2019, at 1:50 PM, Roger Riggs wrote: >> >> Hi Lance, >> >> That looks ok; editorial suggestions below: >> >> >> On 02/04/2019 12:40 PM, Lance Andersen wrote: >>> Hi all >>> >>> Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8182117 which addresses the need to document the Zip File System properties and is also replacing the documentation that used to exist in the tech note: https://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html. >>> >>> The updated documentation can be seen below followed by the diff of the changes. >>> >>> >>> ??????? >>> Module jdk.zipfs >>> >>> <>Provides the implementation of the Zip file system provider. The Zip file system provider treats a Zip or JAR file as a file system providing the ability to manipulate the contents of the file. >>> >>> Accessing a Zip File System >>> >>> You can use the FileSystems newFileSystem static factory methods to create a new Zip file system or to obtain a reference to an existing Zip file system. >>> URI Scheme Used to Identity the Zip File System >>> >>> The URI scheme that identifies the ZIP file system is jar. >>> Zip File System Properties >>> >>> The following properties may be specified when creating a Zip file system: >>> >>> Property Name Data Type Default Value Description >>> create java.lang.String false If the value is true, the Zip file system provider creates a new Zip or JAR file if it does not exist. >>> encoding java.lang.String UTF-8 The value indicates the encoding scheme for the names of the entries in the Zip or JAR file. >>> Examples: >>> >>> Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, it will be created: >>> >>> URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip"); >>> Map env = Map.of("create", "true"); >>> FileSystem zipfs = FileSystems.newFileSystem(uri, env); >>> Construct a new Zip file system that is identified by specifying a path and using automatic file type detection. Iterate from the root of the JAR displaying each found entry: >>> >>> FileSystem zipfs = FileSystems.newFileSystem( >>> Paths.get("tennisteam.jar"), null); >>> Files.walk(zipfs.getPath("/")) >>> .forEach(System.out::println); >>> Since: >>> 9 >>> >>> ?????????? >>> >>> Here is the actual diff: >>> >>> ??????? >>> $ hg diff >>> diff -r cd310319fead src/jdk.zipfs/share/classes/module-info.java >>> --- a/src/jdk.zipfs/share/classes/module-info.java Sun Jan 27 14:55:57 2019 -0500 >>> +++ b/src/jdk.zipfs/share/classes/module-info.java Mon Feb 04 12:30:50 2019 -0500 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -24,14 +24,87 @@ >>> */ >>> /** >>> - * Provides the implementation of the zip file system provider. >>> + * Provides the implementation of the Zip file system provider. >>> + * The Zip file system provider treats a Zip or JAR file as a file system >>> + * providing the ability to manipulate the contents of the file. >> Remove " of the file" so it reads: >> "providing the ability to manipulate the contents. " >>> + *

>>> * >>> - *

The zip file system provider treats a zip or JAR file as a file system >>> - * and provides the ability to manipulate the contents of the file. >>> - * The zip file system provider can be created by >>> - * {@link java.nio.file.FileSystems#newFileSystem >>> - * FileSystems.newFileSystem} if installed. >>> + *

Accessing a Zip File System

>>> * >>> + * You can use the {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} >> Third person seems more appropriate: >> >> + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} >> >> >>> + * static factory methods ^^ to create a new Zip file system or to obtain a reference to an >> can be used >>> + * existing Zip file system. >>> + * >>> + *

URI Scheme Used to Identity the Zip File System

>>> + * >>> + * The URI {@link java.net.URI#getScheme scheme} that identifies the ZIP file system is {@code jar}. >>> + * >>> + *

Zip File System Properties

>>> + * >>> + * The following properties may be specified when creating a Zip >>> + * file system: >>> + *

>>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + * >>> + *
>>> + * Configurable properties that may be specified when creating >>> + * a new Zip file system >>> + *
Property NameData TypeDefault ValueDescription
createjava.lang.Stringfalse >>> + * If the value is {@code true}, the Zip file system provider >>> + * creates a new Zip or JAR file if it does not exist. >>> + *
encodingjava.lang.StringUTF-8 >>> + * The value indicates the encoding scheme for the >>> + * names of the entries in the Zip or JAR file. >>> + *
>>> + * >>> + *

Examples:

>>> + * >>> + * Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, >>> + * it will be created: >>> + *
>>> + * {@code
>>> + *
>>> + *     URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip");
>>> + *     Map env = Map.of("create", "true");
>>> + *     FileSystem zipfs = FileSystems.newFileSystem(uri, env);
>>> + * }
>>> + * 
>>> + * >>> + * Construct a new Zip file system that is identified by specifying a path >>> + * and using automatic file type detection. Iterate from the root of the JAR displaying each >>> + * found entry: >>> + *
>>> + * {@code
>>> + *
>>> + *     FileSystem zipfs = FileSystems.newFileSystem(
>>> + *            Paths.get("tennisteam.jar"), null);
>>> + *     Files.walk(zipfs.getPath("/"))
>>> + *            .forEach(System.out::println);
>>> + * }
>>> + * 
>>> * @provides java.nio.file.spi.FileSystemProvider >>> * @moduleGraph >>> * @since 9 >>> $ >>> -------------------- >>> >>> >>> 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 ivan.gerasimov at oracle.com Mon Feb 4 22:12:52 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 4 Feb 2019 14:12:52 -0800 Subject: RFR 8218227 : StringBuilder constructor throws confusing NegativeArraySizeException In-Reply-To: <25024183-7910-d284-1f2c-d5c1a9803afb@oracle.com> References: <70135128-54af-83f8-9290-bd86d30178d3@oracle.com> <25024183-7910-d284-1f2c-d5c1a9803afb@oracle.com> Message-ID: The reason for keeping HugeCapacity separate was that they require extra memory to be available, and they are skipped otherwise. And we want all "regular" Capacity tests to run always on all systems. With kind regards, Ivan On 2/4/19 1:39 PM, Roger Riggs wrote: > Hi Ivan, > > Can we put the new StringBuffer tests into the existing > StringBuffer.Capacity.java test? > It can help keep functional test pieces to together and not create n+1 > files. > > Looking back I would have preferred the same for the > StringBuilder.Huge tests. > There is a Capacity.java test there too. But the tests have diverged. > > Thanks, Roger > > > On 02/04/2019 04:25 PM, Ivan Gerasimov wrote: >> Thank you Roger for reviewing! >> >> >> On 2/4/19 11:32 AM, Roger Riggs wrote: >>> Hi Ivan, >>> >>> A good boundary condition to clean up. >>> >>> Should tests for StringBuffer be added too? >>> >> Yes, let's add them. >> >> Please find the updated webrev here: >> http://cr.openjdk.java.net/~igerasim/8218227/01/webrev/ >> >> With kind regards, >> Ivan >> >>> Maxing out the length at MAX_VALUE must always result in an OOM. >>> If such an allocation were to succeed, it would violate the >>> specified initial capacity requirement. >>> >>> Thanks, Roger >>> >>> >>> On 02/02/2019 02:28 AM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> The spec of the constructors >>>> StringBuilder(String)/StringBuilder(CharSequence) states that the >>>> initial capacity of the builder will be set to the length of the >>>> argument plus 16. >>>> This causes them to throw confusing NegativeArraySizeException when >>>> the argument's length is close to Integer.MAX_VALUE. >>>> >>>> Let the arguments length be (Integer.MAX_VALUE - DELTA), like in >>>> the code below: >>>> >>>> String str = "Z".repeat(Integer.MAX_VALUE - DELTA); >>>> StringBuilder sb = new StringBuilder(str); >>>> >>>> Currently the behavior is as following: >>>> 0 <= DELTA <= 2 - unable to construct str, >>>> 2 <= DELTA <= 15 - NegativeArraySizeException is thrown, >>>> 16 <= DELTA <= 17 - OutOfMemoryError is thrown, >>>> DELTA >= 18 - works fine. >>>> >>>> With the fix, OOM will be thrown for all DELTA <= 17. >>>> >>>> Also the fix will make constructing a StringBuilder from UTF16 >>>> coded String slightly more efficient. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218227 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218227/00/webrev/ >>>> >>>> Would you please help review the fix? >>>> >>> >>> >> > -- With kind regards, Ivan Gerasimov From t.linkowski at gmail.com Tue Feb 5 05:36:31 2019 From: t.linkowski at gmail.com (Tomasz Linkowski) Date: Tue, 5 Feb 2019 06:36:31 +0100 Subject: Collectors.joining() simplified [patch] Message-ID: Hi, I found out that `Collectors.joining()` can be simplified as follows: 1) `` reduced to `<>` 2) `(r1, r2) -> { r1.append(r2); return r1; }` replaced with `StringBuilder::append` If such a small contribution is considered worthwhile, please sponsor it (patch below). Regards, Tomasz Linkowski PS. I've signed the OCA. =================================================================== --- src/java.base/share/classes/java/util/stream/Collectors.java +++ src/java.base/share/classes/java/util/stream/Collectors.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -365,9 +365,8 @@ * {@code String}, in encounter order */ public static Collector joining() { - return new CollectorImpl( - StringBuilder::new, StringBuilder::append, - (r1, r2) -> { r1.append(r2); return r1; }, + return new CollectorImpl<>( + StringBuilder::new, StringBuilder::append, StringBuilder::append, StringBuilder::toString, CH_NOID); } From Alan.Bateman at oracle.com Tue Feb 5 07:56:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Feb 2019 07:56:56 +0000 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> Message-ID: <348033c4-4e78-3811-4199-f61cc2a9b1f3@oracle.com> On 04/02/2019 21:44, Mandy Chung wrote: > This looks good. > > Sherman added a comment on "encoding" which he thinks it may > be downloaded as undocumented.? You may want to create a > JBS issue to revisit that in the future. Lance asked me a few days ago about this and given that Zip files can be cp437 or UTF-8 then documenting how to specify the coding when opening the Zip or JAR file seems okay. -Alan From magnus.ihse.bursie at oracle.com Tue Feb 5 08:05:37 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Feb 2019 09:05:37 +0100 Subject: RFR: JDK-8217317 : Create jpackage native library for windows In-Reply-To: References: <5ba0a754-bbeb-3aca-d574-f5274fd200e2@oracle.com> Message-ID: <36d29c57-34a1-5164-2d2d-4642a88000a2@oracle.com> On 2019-02-01 23:38, Alexander Matveev wrote: > Hi Magnus, > > http://cr.openjdk.java.net/~almatvee/8217317/webrev.01/ Looks great, thank you! I can't comment on the actual source code changes, so you'll need a thumbs up from someone in core libs as well. > > Moved files to libjpackage and remove JPACKAGELIB_SRC. > > Old wmain() was in jpackage.cpp line 461. Aha. :) I only knew about WinMain and main. You learn something every day. Thanks. /Magnus > > Thanks, > Alexander > > On 2/1/2019 3:39 AM, Magnus Ihse Bursie wrote: >> Hi Alexander, >> >> On 2019-02-01 05:22, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - jpackage launcher will now build same as Linux and OS X using >>> SetupBuildLauncher. >>> - jpackage.dll was added based on Windows jpackage.exe launcher >>> which will have icon swap and version swap functionality called via >>> JNI. >>> - Some code formatting, clean up and minor improvements where done >>> to icon and version swap code. No functional changes. >>> - Windows registry will be read and enumerated via JNI as well. >>> - isDirectoryInExclusionPath() will use native path comparison, >>> since paths in registry and temp folder returned by Java code can be >>> in short or long format, thus simple string comparison will not work. >>> - Windows Defender workaround warning will be checked for >>> --build-root as well if it is set. >>> - Removed extra escaping from JPackageHelper for Windows, otherwise >>> tests fails due to incorrect escaping. Our launcher used >>> CreateProcess to launch java.exe by passing args from main() to >>> CreateProcess. This is why I think we required extra escaping. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8217317 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ >> It basically looks good from a build perspective. There is one change >> I'd like to request, however, and that is that you place the source >> code according to the standard layout. This means moving the source >> files from src/jdk.jpackage/windows/native/jpackage to >> src/jdk.jpackage/windows/native/libjpackage. Also, when you do this, >> you don't need JPACKAGELIB_SRC; the location of the files will be >> determined by SetupJdkLibrary based on the name "jpackage" of the >> library. >> >> I'm also surprised to see that I can't find the removal of the old >> WinMain() method? >> >> /Magnus >> >> >>> >>> Thanks, >>> Alexander >> > From Alan.Bateman at oracle.com Tue Feb 5 08:31:21 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Feb 2019 08:31:21 +0000 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> Message-ID: A few comments On 04/02/2019 19:36, Lance Andersen wrote: > : > > > + * The Zip file system provider treats a Zip or JAR file as a file system > + * providing the ability to manipulate its contents. It might be a bit clearer to reduce this to: "The Zip file system provider treats the contents of a Zip or JAR file as a file system". > * > + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} > + * static factory methods can be used to create a new Zip file system or to > + * obtain a reference to an existing Zip file system. or "can be used to create a zip file system or open an existing file as a zip file system". > + * > + * FileSystem zipfs = FileSystems.newFileSystem( > + * Paths.get("tennisteam.jar"), null); You can change this to use Path.of, also might be nice to remove the line break so it's all on one line. > + * Files.walk(zipfs.getPath("/")) > + * .forEach(System.out::println); > For clarity it might be better to create a variable, say top, for the root directory of the zip file system. The main thing that the reader needs to understand is that the file system is the factory to create paths to files in that file system. -Alan From nishit.jain at oracle.com Tue Feb 5 09:23:23 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Tue, 5 Feb 2019 14:53:23 +0530 Subject: [13] RFR 8217969, 8218265: Base64.Decoder.decode methods ... and java/util/Base64/TestEncodingDecodingLength.java failing In-Reply-To: References: <8019d149-a62d-a385-7ebd-16e72f0acb28@oracle.com> Message-ID: <903d9dab-f9e9-78ba-cc4b-4099b5b16f81@oracle.com> Thanks Roger, Naoto for reviewingthe changes Updated the webrev - Used ByteBuffer.wrap(inputBytes) instead of ByteBuffer.allocate(size) - Added Decoder.decode(ByteBuffer)method test. (line 58) http://cr.openjdk.java.net/~nishjain/8217969_8218265/webrev.01/ Regards, Nishit Jain On 05-02-2019 00:03, Naoto Sato wrote: > +1 > > Naoto > > On 2/4/19 10:18 AM, Roger Riggs wrote: >> Hi Nishit, >> >> Looks fine. >> >> Thanks for fixing the test and improving the implementation. >> >> The test could save one 2G allocation by using >> ByteBuffer.wrap(inputBytes) >> instead of ByteBuffer.allocate(size). >> >> Thanks, Roger >> >> >> >> On 02/04/2019 10:31 AM, Nishit Jain wrote: >>> Hi, >>> >>> Please review the below fix for 8217969 and 8218265 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217969 >>> ???? https://bugs.openjdk.java.net/browse/JDK-8218265 >>> >>> Webrev: http://cr.openjdk.java.net/~nishjain/8217969_8218265/webrev.00/ >>> >>> Issue: Fix for 8210583 changed the Base64.Decoder.decode to throw >>> OOME when an integer value overflows, which is an intermediate >>> value, not the final value, the final value is always less than >>> Integer.MAX_VALUE. Also, the test case written for 8210583, fails on >>> certain platforms and throws "OutOfMemoryError: Requested array size >>> exceeds VM limit ", due to the array size of length >>> Integer.MAX_VALUE - 2. >>> >>> Fix: Handled the integer overflow by storing the intermediate value >>> as "long" and converting the final value as integer. Also, updating >>> the test case input array length to Integer.MAX_VALUE - 8, since >>> MAX_VALUE - 2 was used only to test the overflow condition in >>> Decoder.decode() which is no longer there. >>> >>> Regards, >>> Nishit Jain >> From magnus.ihse.bursie at oracle.com Tue Feb 5 09:57:06 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Feb 2019 10:57:06 +0100 Subject: RFR: JDK-8218186 Clean up CLDR generation in build In-Reply-To: References: Message-ID: On 2019-02-01 14:43, naoto.sato at oracle.com wrote: > Hi Magnus, > > I am assuming that the generated resource bundles are exactly the same > as before this fix, correct? Yes. I have verified this using the COMPARE_BUILD functionality. /Magnus > > Naoto > > On 2/1/19 2:50 AM, Magnus Ihse Bursie wrote: >> The CLDR data is, since Jigsaw, used in two different modules -- >> java.base and jdk.localedata. Unfortunately, the split between these >> two modules were not fully finished as part of the Jigsaw project. >> >> This patch aims to resolving most of this. The CLDRConverter build >> tool is now called from Gensrc-java.base and Gensrc-jdk.localedata, >> for their respective module. The calls have been updated to match >> modern build-infra standards. >> >> Also, the raw CLDR data was located mixed in with the Java source, in >> jdk.localedata. This patch also moves the data to make/data/cldr, to >> align with input data to all other build tools. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218186 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8218186-cleanup-CLDR/webrev.01 >> >> /Magnus From Roger.Riggs at oracle.com Tue Feb 5 14:23:13 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 5 Feb 2019 09:23:13 -0500 Subject: [13] RFR 8217969, 8218265: Base64.Decoder.decode methods ... and java/util/Base64/TestEncodingDecodingLength.java failing In-Reply-To: <903d9dab-f9e9-78ba-cc4b-4099b5b16f81@oracle.com> References: <8019d149-a62d-a385-7ebd-16e72f0acb28@oracle.com> <903d9dab-f9e9-78ba-cc4b-4099b5b16f81@oracle.com> Message-ID: Looks good. Thanks, Roger On 02/05/2019 04:23 AM, Nishit Jain wrote: > Thanks Roger, Naoto for reviewingthe changes > > Updated the webrev > - Used ByteBuffer.wrap(inputBytes) instead of ByteBuffer.allocate(size) > - Added Decoder.decode(ByteBuffer)method test. (line 58) > > http://cr.openjdk.java.net/~nishjain/8217969_8218265/webrev.01/ > > Regards, > Nishit Jain > On 05-02-2019 00:03, Naoto Sato wrote: >> +1 >> >> Naoto >> >> On 2/4/19 10:18 AM, Roger Riggs wrote: >>> Hi Nishit, >>> >>> Looks fine. >>> >>> Thanks for fixing the test and improving the implementation. >>> >>> The test could save one 2G allocation by using >>> ByteBuffer.wrap(inputBytes) >>> instead of ByteBuffer.allocate(size). >>> >>> Thanks, Roger >>> >>> >>> >>> On 02/04/2019 10:31 AM, Nishit Jain wrote: >>>> Hi, >>>> >>>> Please review the below fix for 8217969 and 8218265 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217969 >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8218265 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~nishjain/8217969_8218265/webrev.00/ >>>> >>>> Issue: Fix for 8210583 changed the Base64.Decoder.decode to throw >>>> OOME when an integer value overflows, which is an intermediate >>>> value, not the final value, the final value is always less than >>>> Integer.MAX_VALUE. Also, the test case written for 8210583, fails >>>> on certain platforms and throws "OutOfMemoryError: Requested array >>>> size exceeds VM limit ", due to the array size of length >>>> Integer.MAX_VALUE - 2. >>>> >>>> Fix: Handled the integer overflow by storing the intermediate value >>>> as "long" and converting the final value as integer. Also, updating >>>> the test case input array length to Integer.MAX_VALUE - 8, since >>>> MAX_VALUE - 2 was used only to test the overflow condition in >>>> Decoder.decode() which is no longer there. >>>> >>>> Regards, >>>> Nishit Jain >>> > From Roger.Riggs at oracle.com Tue Feb 5 14:29:56 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 5 Feb 2019 09:29:56 -0500 Subject: RFR 8218227 : StringBuilder constructor throws confusing NegativeArraySizeException In-Reply-To: References: <70135128-54af-83f8-9290-bd86d30178d3@oracle.com> <25024183-7910-d284-1f2c-d5c1a9803afb@oracle.com> Message-ID: <438aea0b-f670-5753-c03c-11b2f4743d68@oracle.com> Hi Ivan, ok, looks fine to me. Thanks, Roger On 02/04/2019 05:12 PM, Ivan Gerasimov wrote: > The reason for keeping HugeCapacity separate was that they require > extra memory to be available, and they are skipped otherwise. > > And we want all "regular" Capacity tests to run always on all systems. > > With kind regards, > > Ivan > > > On 2/4/19 1:39 PM, Roger Riggs wrote: >> Hi Ivan, >> >> Can we put the new StringBuffer tests into the existing >> StringBuffer.Capacity.java test? >> It can help keep functional test pieces to together and not create >> n+1 files. >> >> Looking back I would have preferred the same for the >> StringBuilder.Huge tests. >> There is a Capacity.java test there too.? But the tests have diverged. >> >> Thanks, Roger >> >> >> On 02/04/2019 04:25 PM, Ivan Gerasimov wrote: >>> Thank you Roger for reviewing! >>> >>> >>> On 2/4/19 11:32 AM, Roger Riggs wrote: >>>> Hi Ivan, >>>> >>>> A good boundary condition to clean up. >>>> >>>> Should tests for StringBuffer be added too? >>>> >>> Yes, let's add them. >>> >>> Please find the updated webrev here: >>> http://cr.openjdk.java.net/~igerasim/8218227/01/webrev/ >>> >>> With kind regards, >>> Ivan >>> >>>> Maxing out the length at MAX_VALUE must always result in an OOM. >>>> If such an allocation were to succeed, it would violate the >>>> specified initial capacity requirement. >>>> >>>> Thanks, Roger >>>> >>>> >>>> On 02/02/2019 02:28 AM, Ivan Gerasimov wrote: >>>>> Hello! >>>>> >>>>> The spec of the constructors >>>>> StringBuilder(String)/StringBuilder(CharSequence) states that the >>>>> initial capacity of the builder will be set to the length of the >>>>> argument plus 16. >>>>> This causes them to throw confusing NegativeArraySizeException >>>>> when the argument's length is close to Integer.MAX_VALUE. >>>>> >>>>> Let the arguments length be (Integer.MAX_VALUE - DELTA), like in >>>>> the code below: >>>>> >>>>> ??????? String str = "Z".repeat(Integer.MAX_VALUE - DELTA); >>>>> ??????? StringBuilder sb = new StringBuilder(str); >>>>> >>>>> Currently the behavior is as following: >>>>> ??? 0 <= DELTA <= 2 - unable to construct str, >>>>> ??? 2 <= DELTA <= 15 - NegativeArraySizeException is thrown, >>>>> ??? 16 <= DELTA <= 17 - OutOfMemoryError is thrown, >>>>> ??? DELTA >= 18 - works fine. >>>>> >>>>> With the fix, OOM will be thrown for all DELTA <= 17. >>>>> >>>>> Also the fix will make constructing a StringBuilder from UTF16 >>>>> coded String slightly more efficient. >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218227 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218227/00/webrev/ >>>>> >>>>> Would you please help review the fix? >>>>> >>>> >>>> >>> >> > From naoto.sato at oracle.com Tue Feb 5 15:32:53 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 5 Feb 2019 07:32:53 -0800 Subject: RFR: JDK-8218186 Clean up CLDR generation in build In-Reply-To: References: Message-ID: Thanks, Magnus. The change looks good to me too. Naoto On 2/5/19 1:57 AM, Magnus Ihse Bursie wrote: > On 2019-02-01 14:43, naoto.sato at oracle.com wrote: >> Hi Magnus, >> >> I am assuming that the generated resource bundles are exactly the same >> as before this fix, correct? > > Yes. I have verified this using the COMPARE_BUILD functionality. > > /Magnus >> >> Naoto >> >> On 2/1/19 2:50 AM, Magnus Ihse Bursie wrote: >>> The CLDR data is, since Jigsaw, used in two different modules -- >>> java.base and jdk.localedata. Unfortunately, the split between these >>> two modules were not fully finished as part of the Jigsaw project. >>> >>> This patch aims to resolving most of this. The CLDRConverter build >>> tool is now called from Gensrc-java.base and Gensrc-jdk.localedata, >>> for their respective module. The calls have been updated to match >>> modern build-infra standards. >>> >>> Also, the raw CLDR data was located mixed in with the Java source, in >>> jdk.localedata. This patch also moves the data to make/data/cldr, to >>> align with input data to all other build tools. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218186 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8218186-cleanup-CLDR/webrev.01 >>> >>> /Magnus > From andy.herrick at oracle.com Tue Feb 5 16:06:10 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 5 Feb 2019 11:06:10 -0500 Subject: RFR: JDK-8217894: jpackage CLI syntax changes Message-ID: <6f6c4565-a709-77e6-a5dc-6688e6617c52@oracle.com> Please review the jpackage fix for? [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). In response to internal and external feedback, the following syntax changes are being made to jpackage Command Line Interface (CLI): 1.) remove "create-jre-installer " mode, and add --runtime-installer option. 2.) remove the arg from create-image mode, and add --installer-type option. 3.) rename the --class option to --main-class 4.) remove the --limit-modules option 5.) rename the --force option to --overwrite and improve it's help text. [1] https://bugs.openjdk.java.net/browse/JDK-8217894 [2] http://cr.openjdk.java.net/~herrick/8217894/webrev.01/index.html /Andy From christoph.langer at sap.com Tue Feb 5 16:22:13 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 5 Feb 2019 16:22:13 +0000 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> Message-ID: Hi Lance, Alan, Overall looks good to me. > > A few comments > > > > > + * The Zip file system provider treats a Zip or JAR file as a file system > > + * providing the ability to manipulate its contents. > It might be a bit clearer to reduce this to: "The Zip file system > provider treats the contents of a Zip or JAR file as a file system". +1 > > * > > + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code > newFileSystem} > > + * static factory methods can be used to create a new Zip file system or to > > + * obtain a reference to an existing Zip file system. > or "can be used to create a zip file system or open an existing file as > a zip file system". Here I think Lance's point is what would happen when a FileSystem instance for a particular zip file would already exist and a call to newFileSystem would throw a FileSystemAlreadyExistsException. In that case you need to call getFileSystem. So maybe this sentence should be reworked to cover everything? > > + * > > + * FileSystem zipfs = FileSystems.newFileSystem( > > + * Paths.get("tennisteam.jar"), null); > You can change this to use Path.of, also might be nice to remove the > line break so it's all on one line. > > > + * Files.walk(zipfs.getPath("/")) > > + * .forEach(System.out::println); > > > For clarity it might be better to create a variable, say top, for the > root directory of the zip file system. The main thing that the reader > needs to understand is that the file system is the factory to create > paths to files in that file system. +1 I'm also wondering, whether we should mention how the FileSystemProvider instance can be resolved (e.g. iterating FileSystemProvider.installedProviders(), checking for scheme "jar")? Not quite sure... Best regards Christoph From huizhe.wang at oracle.com Tue Feb 5 17:59:07 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 05 Feb 2019 09:59:07 -0800 Subject: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false) In-Reply-To: <019F817A-2F59-4DEC-9635-400254B4D424@oracle.com> References: <5C4B536C.4010003@oracle.com> <5C5877B0.8010907@oracle.com> <019F817A-2F59-4DEC-9635-400254B4D424@oracle.com> Message-ID: <5C59CEEB.2010004@oracle.com> Thanks, Roger and Lance! The changeset is pushed now. Best, Joe On 2/4/19, 11:00 AM, Lance Andersen wrote: > Hi Joe > > +1 > >> On Feb 4, 2019, at 12:34 PM, Joe Wang > > wrote: >> >> Resend. Please review at your convenience. >> >> Thanks, >> Joe >> >> -------- Original Message -------- >> Subject: Re: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor >> DocumentBuilderFactory.setExpandEntityReferences(false) >> Date: Fri, 25 Jan 2019 10:20:28 -0800 >> From: Joe Wang > >> Organization: Oracle Corporation >> To: core-libs-dev at openjdk.java.net >> >> >> >> >> Please review an updated webrev for this change. In the update, the >> change to XMLDocumentFragmentScannerImpl was to add the default value >> when calling getFeature at line 606 that allowed the previous commented >> tests to pass properly. The other change was to LSSerializerTest. Refer >> to the results (RESULT_TRUE and RESULT_FALSE at line 250 and 271), >> before the change, it outputted both entity references and the expanded >> text, after the change, it's either the EntityReference or Text, which >> makes better sense. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/ >> >> Thanks, >> Joe >> >> On 1/18/19, 11:19 AM, Joe Wang wrote: >>> Please hold on reviewing the webrevs as the tests passed while the new >>> tests were commented out as Lance pointed out. >>> >>> Thanks, >>> Joe >>> >>> On 1/18/19, 10:05 AM, Joe Wang wrote: >>>> Please review a change to the DOM parser so that it complies with the >>>> specification with regard to the ExpandEntityReferences feature. This >>>> change corrects the behavior so that the resulting DOM tree includes >>>> EntityReference nodes but not the expanded Text nodes when the >>>> feature is off. It also means that the DOM parser will not attempt to >>>> read entity references if any. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/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 huizhe.wang at oracle.com Tue Feb 5 18:37:18 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 05 Feb 2019 10:37:18 -0800 Subject: RFR(JDK 13/java.xml) 8180901: Transformer.reset() resets the state only once Message-ID: <5C59D7DE.2080401@oracle.com> Please review a quick fix for preserving the initial state of the Transformer. The faulty impl passes a reference of the initial property setting to the working copy during reset, thus causes it to be altered by an user setting. Further reset would then no longer be able to return to the initial state. JBS: https://bugs.openjdk.java.net/browse/JDK-8180901 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8180901/webrev/ Thanks, Joe From Roger.Riggs at oracle.com Tue Feb 5 19:36:31 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 5 Feb 2019 14:36:31 -0500 Subject: RFR(JDK 13/java.xml) 8180901: Transformer.reset() resets the state only once In-Reply-To: <5C59D7DE.2080401@oracle.com> References: <5C59D7DE.2080401@oracle.com> Message-ID: Looks good. Thanks, Roger On 02/05/2019 01:37 PM, Joe Wang wrote: > Please review a quick fix for preserving the initial state of the > Transformer. The faulty impl passes a reference of the initial > property setting to the working copy during reset, thus causes it to > be altered by an user setting. Further reset would then no longer be > able to return to the initial state. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8180901 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8180901/webrev/ > > Thanks, > Joe From brian.burkhalter at oracle.com Tue Feb 5 19:48:08 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 5 Feb 2019 11:48:08 -0800 Subject: 8218460: Test generation scripts do not invoke stream preprocessor correctly Message-ID: <99683428-4D82-4A83-92FC-F34950F97B7F@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8218460 http://cr.openjdk.java.net/~bpb/8218460/webrev.00/ A full test run will be effected with the generated tests except those generated by test/jdk/java/lang/invoke/VarHandles/generate-vh-tests.sh Unfortunately it appears that tests in this folder were modified by manual editing as opposed to modifying the templates and generating the tests via the script. This will be the subject of a linked issue. Thanks, Brian From lance.andersen at oracle.com Tue Feb 5 19:52:55 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 5 Feb 2019 14:52:55 -0500 Subject: RFR(JDK 13/java.xml) 8180901: Transformer.reset() resets the state only once In-Reply-To: <5C59D7DE.2080401@oracle.com> References: <5C59D7DE.2080401@oracle.com> Message-ID: <4488F419-7615-43ED-9581-715C9D2BD7DB@oracle.com> Hi Joe, The change seems reasonable... > On Feb 5, 2019, at 1:37 PM, Joe Wang wrote: > > Please review a quick fix for preserving the initial state of the Transformer. The faulty impl passes a reference of the initial property setting to the working copy during reset, thus causes it to be altered by an user setting. Further reset would then no longer be able to return to the initial state. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8180901 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8180901/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 lance.andersen at oracle.com Tue Feb 5 21:45:09 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 5 Feb 2019 16:45:09 -0500 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> Message-ID: <8C6F12DD-9195-4ECC-BF20-B8868A363C86@oracle.com> Thank you for the feedback. Please see below > On Feb 5, 2019, at 3:31 AM, Alan Bateman wrote: > > A few comments > > On 04/02/2019 19:36, Lance Andersen wrote: >> : >> >> + * The Zip file system provider treats a Zip or JAR file as a file system >> + * providing the ability to manipulate its contents. > It might be a bit clearer to reduce this to: "The Zip file system provider treats the contents of a Zip or JAR file as a file system?. OK > > > >> * >> + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} >> + * static factory methods can be used to create a new Zip file system or to >> + * obtain a reference to an existing Zip file system. > or "can be used to create a zip file system or open an existing file as a zip file system?. OK > > >> + * >> + * FileSystem zipfs = FileSystems.newFileSystem( >> + * Paths.get("tennisteam.jar"), null); > You can change this to use Path.of, also might be nice to remove the line break so it's all on one line. done. I broke it onto multiple lines so it was not too long, but reversed that per your request > >> + * Files.walk(zipfs.getPath("/")) >> + * .forEach(System.out::println); >> > For clarity it might be better to create a variable, say top, for the root directory of the zip file system. The main thing that the reader needs to understand is that the file system is the factory to create paths to files in that file system. Done: ?????? Module jdk.zipfs <>Provides the implementation of the Zip file system provider. The Zip file system provider treats the contents of a Zip or JAR file as a file system. Accessing a Zip File System The FileSystems newFileSystem static factory methods can be used to: Create a Zip file system Open an existing file as a Zip file system URI Scheme Used to Identity the Zip File System The URI scheme that identifies the ZIP file system is jar. Zip File System Properties The following properties may be specified when creating a Zip file system: Property Name Data Type Default Value Description create java.lang.String false If the value is true, the Zip file system provider creates a new Zip or JAR file if it does not exist. encoding java.lang.String UTF-8 The value indicates the encoding scheme for the names of the entries in the Zip or JAR file. Examples: Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, it will be created: URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip"); Map env = Map.of("create", "true"); FileSystem zipfs = FileSystems.newFileSystem(uri, env); Construct a new Zip file system that is identified by specifying a path and using automatic file type detection. Iterate from the root of the JAR displaying each found entry: FileSystem zipfs = FileSystems.newFileSystem(Path.of("helloworld.jar"), null); Path rootDir = zipfs.getPath("/"); Files.walk(rootDir) .forEach(System.out::println); Since: 9 ???????? And the diff is: ????? $ hg diff diff -r 213a2377b792 src/jdk.zipfs/share/classes/module-info.java --- a/src/jdk.zipfs/share/classes/module-info.java Mon Feb 04 11:00:12 2019 +0100 +++ b/src/jdk.zipfs/share/classes/module-info.java Tue Feb 05 16:43:25 2019 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -24,14 +24,89 @@ */ /** - * Provides the implementation of the zip file system provider. + * Provides the implementation of the Zip file system provider. + * The Zip file system provider treats the contents of a Zip or JAR file as a file system. + *

* - *

The zip file system provider treats a zip or JAR file as a file system - * and provides the ability to manipulate the contents of the file. - * The zip file system provider can be created by - * {@link java.nio.file.FileSystems#newFileSystem - * FileSystems.newFileSystem} if installed. + *

Accessing a Zip File System

* + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem} + * static factory methods can be used to: + *
    + *
  • Create a Zip file system
  • + *
  • Open an existing file as a Zip file system
  • + *
+ * + *

URI Scheme Used to Identity the Zip File System

+ * + * The URI {@link java.net.URI#getScheme scheme} that identifies the ZIP file system is {@code jar}. + * + *

Zip File System Properties

+ * + * The following properties may be specified when creating a Zip + * file system: + *

+ * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *
+ * Configurable properties that may be specified when creating + * a new Zip file system + *
Property NameData TypeDefault ValueDescription
createjava.lang.Stringfalse + * If the value is {@code true}, the Zip file system provider + * creates a new Zip or JAR file if it does not exist. + *
encodingjava.lang.StringUTF-8 + * The value indicates the encoding scheme for the + * names of the entries in the Zip or JAR file. + *
+ * + *

Examples:

+ * + * Construct a new Zip file system that is identified by a URI. If the Zip file does not exist, + * it will be created: + *
+ * {@code
+ *
+ *     URI uri = URI.create("jar:file:/home/luckydog/tennisTeam.zip");
+ *     Map env = Map.of("create", "true");
+ *     FileSystem zipfs = FileSystems.newFileSystem(uri, env);
+ * }
+ * 
+ * + * Construct a new Zip file system that is identified by specifying a path + * and using automatic file type detection. Iterate from the root of the JAR displaying each + * found entry: + *
+ * {@code
+ *
+ *     FileSystem zipfs = FileSystems.newFileSystem(Path.of("helloworld.jar"), null);
+ *     Path rootDir = zipfs.getPath("/");
+ *     Files.walk(rootDir)
+ *            .forEach(System.out::println);
+ * }
+ * 
* @provides java.nio.file.spi.FileSystemProvider * @moduleGraph * @since 9 $ -------------- > > -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 Feb 5 21:48:08 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 5 Feb 2019 16:48:08 -0500 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> Message-ID: <4584C3AE-E32F-491E-86BC-E8C93F5252A8@oracle.com> Hi Christoph Thank you for the feedback, Please see below > On Feb 5, 2019, at 11:22 AM, Langer, Christoph wrote: > >>> * >>> + * The {@linkplain java.nio.file.FileSystems FileSystems} {@code >> newFileSystem} >>> + * static factory methods can be used to create a new Zip file system or to >>> + * obtain a reference to an existing Zip file system. >> or "can be used to create a zip file system or open an existing file as >> a zip file system". > > Here I think Lance's point is what would happen when a FileSystem instance for a particular zip file would already exist and a call to newFileSystem would throw a FileSystemAlreadyExistsException. In that case you need to call getFileSystem. So maybe this sentence should be reworked to cover everything? This only appears to be the case when using a URI not a Path, so for now I suggest we leave it as is based on the last changes > >>> > > I'm also wondering, whether we should mention how the FileSystemProvider instance can be resolved (e.g. iterating FileSystemProvider.installedProviders(), checking for scheme "jar")? Not quite sure? I had included that originally, but Alan and I discussed that off line prior to the original RFR and we decided it was not needed for the average developer so I removed it prior to the RFR. Best Lance > > Best regards > 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 alexander.matveev at oracle.com Tue Feb 5 22:52:08 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 5 Feb 2019 14:52:08 -0800 Subject: RFR: JDK-8217894: jpackage CLI syntax changes In-Reply-To: <6f6c4565-a709-77e6-a5dc-6688e6617c52@oracle.com> References: <6f6c4565-a709-77e6-a5dc-6688e6617c52@oracle.com> Message-ID: Hi Andy, http://cr.openjdk.java.net/~herrick/8217894/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/ValidOptions.java.frames.html Line 108 and 113 looks same. I think one of them can be removed. http://cr.openjdk.java.net/~herrick/8217894/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties.frames.html Line 84 - "Specifies the type of the installer created in create-image mode", I think it should be "created in create-installer mode". Otherwise looks fine. Thanks, Alexander On 2/5/2019 8:06 AM, Andy Herrick wrote: > Please review the jpackage fix for? [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > In response to internal and external feedback, the following syntax > changes are being made to jpackage Command Line Interface (CLI): > > 1.) remove "create-jre-installer " mode, and add > --runtime-installer option. > 2.) remove the arg from create-image mode, and add > --installer-type option. > 3.) rename the --class option to --main-class > 4.) remove the --limit-modules option > 5.) rename the --force option to --overwrite and improve it's help text. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217894 > > [2] http://cr.openjdk.java.net/~herrick/8217894/webrev.01/index.html > > /Andy > From huizhe.wang at oracle.com Tue Feb 5 23:07:58 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 05 Feb 2019 15:07:58 -0800 Subject: RFR(JDK 13/java.xml) 8180901: Transformer.reset() resets the state only once In-Reply-To: <4488F419-7615-43ED-9581-715C9D2BD7DB@oracle.com> References: <5C59D7DE.2080401@oracle.com> <4488F419-7615-43ED-9581-715C9D2BD7DB@oracle.com> Message-ID: <5C5A174E.60405@oracle.com> Thanks, Lance and Roger! The changeset is pushed now. Best, Joe On 2/5/19, 11:52 AM, Lance Andersen wrote: > Hi Joe, > > The change seems reasonable... >> On Feb 5, 2019, at 1:37 PM, Joe Wang > > wrote: >> >> Please review a quick fix for preserving the initial state of the >> Transformer. The faulty impl passes a reference of the initial >> property setting to the working copy during reset, thus causes it to >> be altered by an user setting. Further reset would then no longer be >> able to return to the initial state. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8180901 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8180901/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 andy.herrick at oracle.com Tue Feb 5 23:07:57 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 5 Feb 2019 18:07:57 -0500 Subject: RFR: JDK-8217894: jpackage CLI syntax changes In-Reply-To: References: <6f6c4565-a709-77e6-a5dc-6688e6617c52@oracle.com> Message-ID: On 2/5/2019 5:52 PM, Alexander Matveev wrote: > Hi Andy, > > http://cr.openjdk.java.net/~herrick/8217894/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/ValidOptions.java.frames.html > > Line 108 and 113 looks same. I think one of them can be removed. > > http://cr.openjdk.java.net/~herrick/8217894/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties.frames.html > > Line 84 - "Specifies the type of the installer created in create-image > mode", I think it should be "created in create-installer mode". > yes to both - will fix. /Andy > Otherwise looks fine. > > Thanks, > Alexander > > On 2/5/2019 8:06 AM, Andy Herrick wrote: >> Please review the jpackage fix for? [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> In response to internal and external feedback, the following syntax >> changes are being made to jpackage Command Line Interface (CLI): >> >> 1.) remove "create-jre-installer " mode, and add >> --runtime-installer option. >> 2.) remove the arg from create-image mode, and add >> --installer-type option. >> 3.) rename the --class option to --main-class >> 4.) remove the --limit-modules option >> 5.) rename the --force option to --overwrite and improve it's help text. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217894 >> >> [2] http://cr.openjdk.java.net/~herrick/8217894/webrev.01/index.html >> >> /Andy >> > From mandy.chung at oracle.com Tue Feb 5 23:10:27 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 5 Feb 2019 15:10:27 -0800 Subject: Review Request JDK-8218419: Can't get annotations that are present on packages in -Xbootclasspath/a Message-ID: <9c7da5a5-cb2a-e499-373d-b6e6ab1c3c56@oracle.com> BootClassLoader mistakenly overrides the 1-arg loadClassOrNull method instead of the 2-arg loadClassOrNull method. A class defined to the bootstrap class loader is intended to call JVM entry point to find such class rather than ClassLoader::defineClass method via the implementation-specific BootClassLoader instance. The patch is trivial; BootClassLoader overrides the two-arg loadClassOrNull instead. Webrev at: http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8218419/webrev.00 Thanks Mandy From Alan.Bateman at oracle.com Wed Feb 6 08:31:21 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Feb 2019 08:31:21 +0000 Subject: Review Request JDK-8218419: Can't get annotations that are present on packages in -Xbootclasspath/a In-Reply-To: <9c7da5a5-cb2a-e499-373d-b6e6ab1c3c56@oracle.com> References: <9c7da5a5-cb2a-e499-373d-b6e6ab1c3c56@oracle.com> Message-ID: On 05/02/2019 23:10, Mandy Chung wrote: > BootClassLoader mistakenly overrides the 1-arg loadClassOrNull method > instead of the 2-arg loadClassOrNull method.? A class defined to > the bootstrap class loader is intended to call JVM entry point > to find such class rather than ClassLoader::defineClass method > via the implementation-specific BootClassLoader instance. > The patch is trivial; BootClassLoader overrides the two-arg > loadClassOrNull instead. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8218419/webrev.00 Looks good. I assume it isn't too common to be loading the annotations of classes deployed with -Xbootclasspath/a which might explain why the issue has existed for several releases without anyone noticing. -Alan From matthias.baesken at sap.com Wed Feb 6 08:55:36 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 6 Feb 2019 08:55:36 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <1e62e919d0424829b86018ad21b2722f@sap.com> References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> <454246fd-ff02-716c-7be4-876eb39e2225@oracle.com> <2424978d6a124ff591955d4b4beff759@sap.com> <66488fb2-b612-3091-f73f-34d200506919@oracle.com> <1e62e919d0424829b86018ad21b2722f@sap.com> Message-ID: Hi Christoph+Alan, I opened https://bugs.openjdk.java.net/browse/JDK-8218547 JDK-8218547 : use CreateFile without open on Windows in jdk native code To check for the usage of CreateFile (CreateFileW) without open . Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Dienstag, 29. Januar 2019 09:59 > To: Baesken, Matthias > Cc: Chris Hegarty ; core-libs- > dev at openjdk.java.net > Subject: RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hi Matthias, > > > > New webrev : > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ > > > > This is the one. Looks good ( and clean ). > > I agree, this version would be ok for me to be pushed. It would be good > ,though, if there was a test for this (long paths on Windows). > > I also like Alan's suggestion to open a follow up bug to explore using > CreateFile on Windows right away rather than trying open. Looking at > libjava/libnet/libnio, it's all CreateFileW on Windows... > > Best regards > Christoph > From Alan.Bateman at oracle.com Wed Feb 6 08:59:41 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Feb 2019 08:59:41 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <1e62e919d0424829b86018ad21b2722f@sap.com> References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> <454246fd-ff02-716c-7be4-876eb39e2225@oracle.com> <2424978d6a124ff591955d4b4beff759@sap.com> <66488fb2-b612-3091-f73f-34d200506919@oracle.com> <1e62e919d0424829b86018ad21b2722f@sap.com> Message-ID: <14da99b3-81b4-4302-2468-f6ae05d3a84e@oracle.com> On 29/01/2019 08:58, Langer, Christoph wrote: > Hi Matthias, > >>> New webrev : >>> >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ >> This is the one. Looks good ( and clean ). > I agree, this version would be ok for me to be pushed. It would be good ,though, if there was a test for this (long paths on Windows). > > I also like Alan's suggestion to open a follow up bug to explore using CreateFile on Windows right away rather than trying open. Looking at libjava/libnet/libnio, it's all CreateFileW on Windows... I think the right fix is to convert a relative path into absolute path, apply the prefix for long paths, and then use CreateFileW consistently. It's probably okay to get there in steps but I can't tell from the current webrev if it works with relative paths or not. -Alan From christoph.langer at sap.com Wed Feb 6 09:08:21 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 6 Feb 2019 09:08:21 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <14da99b3-81b4-4302-2468-f6ae05d3a84e@oracle.com> References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> <454246fd-ff02-716c-7be4-876eb39e2225@oracle.com> <2424978d6a124ff591955d4b4beff759@sap.com> <66488fb2-b612-3091-f73f-34d200506919@oracle.com> <1e62e919d0424829b86018ad21b2722f@sap.com> <14da99b3-81b4-4302-2468-f6ae05d3a84e@oracle.com> Message-ID: <1ffa1fea0af64d56aef74e4245fbdfc1@sap.com> Hi Matthias, thanks for opening the bug. I refined its description a little... Best regards Christoph > -----Original Message----- > From: Alan Bateman > Sent: Mittwoch, 6. Februar 2019 10:00 > To: Langer, Christoph ; Baesken, Matthias > > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > > On 29/01/2019 08:58, Langer, Christoph wrote: > > Hi Matthias, > > > >>> New webrev : > >>> > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ > >> This is the one. Looks good ( and clean ). > > I agree, this version would be ok for me to be pushed. It would be good > ,though, if there was a test for this (long paths on Windows). > > > > I also like Alan's suggestion to open a follow up bug to explore using > CreateFile on Windows right away rather than trying open. Looking at > libjava/libnet/libnio, it's all CreateFileW on Windows... > I think the right fix is to convert a relative path into absolute path, > apply the prefix for long paths, and then use CreateFileW consistently. > It's probably okay to get there in steps but I can't tell from the > current webrev if it works with relative paths or not. > > -Alan From Alan.Bateman at oracle.com Wed Feb 6 09:09:19 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Feb 2019 09:09:19 +0000 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: <8C6F12DD-9195-4ECC-BF20-B8868A363C86@oracle.com> References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> <8C6F12DD-9195-4ECC-BF20-B8868A363C86@oracle.com> Message-ID: <5cf476bf-3595-e496-c385-ec163956fe6d@oracle.com> On 05/02/2019 21:45, Lance Andersen wrote: > Thank you for the feedback. ?Please see below The updated version that you attached looks okay to me. -Alan From matthias.baesken at sap.com Wed Feb 6 09:20:33 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 6 Feb 2019 09:20:33 +0000 Subject: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows In-Reply-To: <1ffa1fea0af64d56aef74e4245fbdfc1@sap.com> References: <878449a7-29a1-b2f9-5637-fd21980c2e80@oracle.com> <29afbea6-570e-3daf-2a75-8e88acc58c35@oracle.com> <64593016-855e-eb3b-86a4-2e840ef2a1ae@oracle.com> <9eb35c75-4602-ec65-2a19-5b0bcb832e2a@oracle.com> <454246fd-ff02-716c-7be4-876eb39e2225@oracle.com> <2424978d6a124ff591955d4b4beff759@sap.com> <66488fb2-b612-3091-f73f-34d200506919@oracle.com> <1e62e919d0424829b86018ad21b2722f@sap.com> <14da99b3-81b4-4302-2468-f6ae05d3a84e@oracle.com> <1ffa1fea0af64d56aef74e4245fbdfc1@sap.com> Message-ID: Thanks . Looks like there are a few open calls in windows or shared code present , for example : Zlib: gzlib.c hotspot: osSupport_windows.cpp compactHashtable.cpp but mostly it is CreateFile(W) ( not sure if it is always with extended length path support). We could also compare what is done in JDK and in Windows HS os::open int os::open(const char *path, int oflag, int mode) { from os_windows.cpp (this creates an UNC path + uses _wopen ). Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 6. Februar 2019 10:08 > To: Baesken, Matthias > Cc: core-libs-dev at openjdk.java.net; Alan Bateman > > Subject: RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hi Matthias, > > thanks for opening the bug. I refined its description a little... > > Best regards > Christoph > > > -----Original Message----- > > From: Alan Bateman > > Sent: Mittwoch, 6. Februar 2019 10:00 > > To: Langer, Christoph ; Baesken, Matthias > > > > Cc: core-libs-dev at openjdk.java.net > > Subject: Re: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > > > On 29/01/2019 08:58, Langer, Christoph wrote: > > > Hi Matthias, > > > > > >>> New webrev : > > >>> > > >>> > > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ > > >> This is the one. Looks good ( and clean ). > > > I agree, this version would be ok for me to be pushed. It would be good > > ,though, if there was a test for this (long paths on Windows). > > > > > > I also like Alan's suggestion to open a follow up bug to explore using > > CreateFile on Windows right away rather than trying open. Looking at > > libjava/libnet/libnio, it's all CreateFileW on Windows... > > I think the right fix is to convert a relative path into absolute path, > > apply the prefix for long paths, and then use CreateFileW consistently. > > It's probably okay to get there in steps but I can't tell from the > > current webrev if it works with relative paths or not. > > > > -Alan From thomas.stuefe at gmail.com Wed Feb 6 09:29:12 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 6 Feb 2019 10:29:12 +0100 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn Message-ID: Hi all Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html (@Roger: I hope you do not mind? The bug is assigned to you but since I happened to play around with posix_spawn I prepared this webrev. If you rather do this change, that is fine and I will leave it to you.) When we added the possibility to use posix_spawn as underlying implementation for Runtime.exec() on Linux with https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep VFORK as default until work on 13 starts. So now would be a good time to switch the default to posix_spawn to get a good testing window. Note that at SAP we run our VMs internally with posix_spawn as default since some months and have not seen problems. As for the fix, I added a test which tests that the default is indeed posix_spawn - not sure whether this is overdoing it though. Also, I use strace for the test, and /bin/true, and while strace is usually available and reachable by path resolution, I am afraid on some test machines it may not. What do you think, should I leave the test out? The fix ran through all java/lang/ProcessBuilder jtreg tests ok. Thanks, Thomas From christoph.langer at sap.com Wed Feb 6 09:44:13 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 6 Feb 2019 09:44:13 +0000 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: <5cf476bf-3595-e496-c385-ec163956fe6d@oracle.com> References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> <8C6F12DD-9195-4ECC-BF20-B8868A363C86@oracle.com> <5cf476bf-3595-e496-c385-ec163956fe6d@oracle.com> Message-ID: <62625ddaee2d4e72a2069780084dfdff@sap.com> +1 > -----Original Message----- > From: core-libs-dev On Behalf > Of Alan Bateman > Sent: Mittwoch, 6. Februar 2019 10:09 > To: Lance Andersen > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR 8182117 : Document Zip File System Properties > > On 05/02/2019 21:45, Lance Andersen wrote: > > Thank you for the feedback. ?Please see below > The updated version that you attached looks okay to me. > > -Alan From Roger.Riggs at oracle.com Wed Feb 6 15:15:03 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 6 Feb 2019 10:15:03 -0500 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: Hi Thomas, On 02/06/2019 04:29 AM, Thomas St?fe wrote: > Hi all > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html > > > (@Roger: I hope you do not mind? The bug is assigned to you but since > I happened to play around with posix_spawn I prepared this webrev. If > you rather do this change, that is fine and I will leave it to you.) no problem, I hadn't gotten to it.? Thanks for proposing it. > > When we added the possibility to use posix_spawn as underlying > implementation for Runtime.exec() on Linux with > https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep > VFORK as default until work on 13 starts. So now would be a good time > to switch the default to posix_spawn to get a good testing window. > Note that at SAP we run our VMs internally with posix_spawn as default > since some months and have not seen problems. > > As for the fix, I added a test which tests that the default is indeed > posix_spawn - not sure whether this is overdoing it though. Also, I > use strace for the test, and /bin/true, and while strace is usually > available and reachable by path resolution, I am afraid on some test > machines it may not. What do you think, should I leave the test out? The test is a bit quirky but should work ok. I'd leave it in until it fails and re-evaluate then. If it fails on some systems, we can either configure them out or just skip the test if the process launch of strace fails.? (Throw SkippedException). > > The fix ran through all java/lang/ProcessBuilder jtreg tests ok. I'll run the patch through the usual CI build here too. Thanks, Roger > > Thanks, Thomas > From Roger.Riggs at oracle.com Wed Feb 6 15:53:47 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 6 Feb 2019 10:53:47 -0500 Subject: RFR: JDK-8217894: jpackage CLI syntax changes In-Reply-To: References: <6f6c4565-a709-77e6-a5dc-6688e6617c52@oracle.com> Message-ID: Hi Andy, In the help text,? the mention of "JImage" isn't needed. It will just make folks ask, what's a JImage. Line 168:? Shrink it to: "separated list of modules to add" The mention of "JLink" is probably a distraction too. Instead:? "Path to look for modules when packaging the Java Runtime" Do the language specific resource really need to be duplicated? Or is that just awaiting translation. MainResources.properties(And the copies) the use of "force" in the keys should be changed to overwrite. (And in the code too). For completeness the JPackageCreateImageForceTest.java should be renamed. In the installer tests that add the --installer-type option, I'd put it on the same line with the EXT, etc. so its clear they go together as is done with the other options with arguments. [Those installer tests would benefit from being data driven and there would be fewer files to maintain.] Thanks, Roger On 02/05/2019 06:07 PM, Andy Herrick wrote: > > > On 2/5/2019 5:52 PM, Alexander Matveev wrote: >> Hi Andy, >> >> http://cr.openjdk.java.net/~herrick/8217894/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/ValidOptions.java.frames.html >> >> Line 108 and 113 looks same. I think one of them can be removed. >> >> http://cr.openjdk.java.net/~herrick/8217894/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties.frames.html >> >> Line 84 - "Specifies the type of the installer created in >> create-image mode", I think it should be "created in create-installer >> mode". >> > yes to both - will fix. > /Andy > >> Otherwise looks fine. >> >> Thanks, >> Alexander >> >> On 2/5/2019 8:06 AM, Andy Herrick wrote: >>> Please review the jpackage fix for? [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> In response to internal and external feedback, the following syntax >>> changes are being made to jpackage Command Line Interface (CLI): >>> >>> 1.) remove "create-jre-installer " mode, and add >>> --runtime-installer option. >>> 2.) remove the arg from create-image mode, and add >>> --installer-type option. >>> 3.) rename the --class option to --main-class >>> 4.) remove the --limit-modules option >>> 5.) rename the --force option to --overwrite and improve it's help >>> text. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8217894 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8217894/webrev.01/index.html >>> >>> /Andy >>> >> > From Alan.Bateman at oracle.com Wed Feb 6 16:06:59 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Feb 2019 16:06:59 +0000 Subject: RFR: JDK-8217894: jpackage CLI syntax changes In-Reply-To: References: <6f6c4565-a709-77e6-a5dc-6688e6617c52@oracle.com> Message-ID: On 06/02/2019 15:53, Roger Riggs wrote: > Hi Andy, > > In the help text,? the mention of "JImage" isn't needed. It will just > make folks ask, what's a JImage. > Line 168:? Shrink it to: "separated list of modules to add" Right, the jimage container is internal to the JDK so it shouldn't be in the usage output (only the `jimage` tool, included for troubleshooting purposes, should mention jimage files). Andy - are you planning to sync up with JEP so that it documents the latest CLI options? I realize it's a pain to keep the two in sync while you iterate but it's also confusing to have the JEP document options that no longer exist. -Alan From andy.herrick at oracle.com Wed Feb 6 17:13:42 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 6 Feb 2019 12:13:42 -0500 Subject: RFR: JDK-8217894: jpackage CLI syntax changes In-Reply-To: References: <6f6c4565-a709-77e6-a5dc-6688e6617c52@oracle.com> Message-ID: generally, these help text changes will be fixed in JDK-8217687 , where I have added line items from below. On 2/6/2019 10:53 AM, Roger Riggs wrote: > Hi Andy, > > In the help text,? the mention of "JImage" isn't needed. It will just > make folks ask, what's a JImage. > Line 168:? Shrink it to: "separated list of modules to add" ok, - added as line item 15 in JDK-8217687 . do we want to more closely follow the java help text: > ??? --add-modules [,...] > ????????????????? root modules to resolve in addition to the initial > module. > > The mention of "JLink" is probably a distraction too. > Instead:? "Path to look for modules when packaging the Java Runtime" yes - it will go away > > Do the language specific resource really need to be duplicated? Or is > that just awaiting translation. yes - until first translation we are asked to have all resources duplicated. > > MainResources.properties(And the copies) the use of "force" in the > keys should be changed to overwrite. > (And in the code too). > > For completeness the JPackageCreateImageForceTest.java should be renamed. I will make the above tow changes as part of JDK-8217687 > > In the installer tests that add the --installer-type option, I'd put > it on the same line with the EXT, etc. > so its clear they go together as is done with the other options with > arguments. also added to JDK-8217687 /Andy > > [Those installer tests would benefit from being data driven and there > would be > fewer files to maintain.] > > Thanks, Roger > > > > > On 02/05/2019 06:07 PM, Andy Herrick wrote: >> >> >> On 2/5/2019 5:52 PM, Alexander Matveev wrote: >>> Hi Andy, >>> >>> http://cr.openjdk.java.net/~herrick/8217894/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/ValidOptions.java.frames.html >>> >>> Line 108 and 113 looks same. I think one of them can be removed. >>> >>> http://cr.openjdk.java.net/~herrick/8217894/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties.frames.html >>> >>> Line 84 - "Specifies the type of the installer created in >>> create-image mode", I think it should be "created in >>> create-installer mode". >>> >> yes to both - will fix. >> /Andy >> >>> Otherwise looks fine. >>> >>> Thanks, >>> Alexander >>> >>> On 2/5/2019 8:06 AM, Andy Herrick wrote: >>>> Please review the jpackage fix for [1] at [2]. >>>> >>>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>>> repository (jpackage). >>>> >>>> In response to internal and external feedback, the following syntax >>>> changes are being made to jpackage Command Line Interface (CLI): >>>> >>>> 1.) remove "create-jre-installer " mode, and add >>>> --runtime-installer option. >>>> 2.) remove the arg from create-image mode, and add >>>> --installer-type option. >>>> 3.) rename the --class option to --main-class >>>> 4.) remove the --limit-modules option >>>> 5.) rename the --force option to --overwrite and improve it's help >>>> text. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8217894 >>>> >>>> [2] http://cr.openjdk.java.net/~herrick/8217894/webrev.01/index.html >>>> >>>> /Andy >>>> >>> >> > From andy.herrick at oracle.com Wed Feb 6 17:44:01 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 6 Feb 2019 12:44:01 -0500 Subject: RFR: JDK-8217894: jpackage CLI syntax changes In-Reply-To: References: <6f6c4565-a709-77e6-a5dc-6688e6617c52@oracle.com> Message-ID: <245a896c-4032-7c98-37a8-bd3d579de228@oracle.com> On 2/6/2019 11:06 AM, Alan Bateman wrote: > > > On 06/02/2019 15:53, Roger Riggs wrote: >> Hi Andy, >> >> In the help text,? the mention of "JImage" isn't needed. It will just >> make folks ask, what's a JImage. >> Line 168:? Shrink it to: "separated list of modules to add" > Right, the jimage container is internal to the JDK so it shouldn't be > in the usage output (only the `jimage` tool, included for > troubleshooting purposes, should mention jimage files). > > Andy - are you planning to sync up with JEP so that it documents the > latest CLI options? I realize it's a pain to keep the two in sync > while you iterate but it's also confusing to have the JEP document > options that no longer exist. > yes - we had planed to sync up the JEP while these CLI and help message output changes were being implemented. I hope to get to that this week. /Andy > -Alan From mandy.chung at oracle.com Wed Feb 6 17:53:47 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 6 Feb 2019 09:53:47 -0800 Subject: Review Request JDK-8218419: Can't get annotations that are present on packages in -Xbootclasspath/a In-Reply-To: References: <9c7da5a5-cb2a-e499-373d-b6e6ab1c3c56@oracle.com> Message-ID: <80807019-c063-2055-f732-ace95fd5af1f@oracle.com> On 2/6/19 12:31 AM, Alan Bateman wrote: > On 05/02/2019 23:10, Mandy Chung wrote: >> BootClassLoader mistakenly overrides the 1-arg loadClassOrNull method >> instead of the 2-arg loadClassOrNull method.? A class defined to >> the bootstrap class loader is intended to call JVM entry point >> to find such class rather than ClassLoader::defineClass method >> via the implementation-specific BootClassLoader instance. >> The patch is trivial; BootClassLoader overrides the two-arg >> loadClassOrNull instead. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8218419/webrev.00 > Looks good. I assume it isn't too common to be loading the annotations > of classes deployed with -Xbootclasspath/a which might explain why the > issue has existed for several releases without anyone noticing. That's what I think so too. Thanks for the review. Mandy From thomas.stuefe at gmail.com Wed Feb 6 18:16:44 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 6 Feb 2019 19:16:44 +0100 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: Hi Roger, On Wed, Feb 6, 2019 at 4:15 PM Roger Riggs wrote: > Hi Thomas, > > On 02/06/2019 04:29 AM, Thomas St?fe wrote: > > Hi all > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html > > > (@Roger: I hope you do not mind? The bug is assigned to you but since I > happened to play around with posix_spawn I prepared this webrev. If you > rather do this change, that is fine and I will leave it to you.) > > no problem, I hadn't gotten to it. Thanks for proposing it. > > > When we added the possibility to use posix_spawn as underlying > implementation for Runtime.exec() on Linux with > https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep VFORK > as default until work on 13 starts. So now would be a good time to switch > the default to posix_spawn to get a good testing window. Note that at SAP > we run our VMs internally with posix_spawn as default since some months and > have not seen problems. > > As for the fix, I added a test which tests that the default is indeed > posix_spawn - not sure whether this is overdoing it though. Also, I use > strace for the test, and /bin/true, and while strace is usually available > and reachable by path resolution, I am afraid on some test machines it may > not. What do you think, should I leave the test out? > > The test is a bit quirky but should work ok. > I'd leave it in until it fails and re-evaluate then. > > If it fails on some systems, we can either configure them out or > just skip the test if the process launch of strace fails. (Throw > SkippedException). > > > Yes, that makes sense. > The fix ran through all java/lang/ProcessBuilder jtreg tests ok. > > I'll run the patch through the usual CI build here too. > > Thanks. I'll run the test thru the submit repository too. Cheers, Thomas > Thanks, Roger > > > Thanks, Thomas > > > From martinrb at google.com Wed Feb 6 18:28:12 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 6 Feb 2019 10:28:12 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> <206a816f-85c6-5c07-8fce-d6a0497a75b5@redhat.com> Message-ID: Finally got around to doing some work on this. I'm happy with this latest revision: https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/HashMap-resize/index.html I did some more work on the microbenchmark, in part to force myself to learn about jmh. It now tests LinkedHashMap as well. I replaced use of Random with ThreadLocalRandom @Param("1000000") private int size; @Param private MapType mapType; public enum MapType { HASH_MAP, LINKED_HASH_MAP, } On Thu, Jan 3, 2019 at 12:31 PM Michal Vala wrote: > Hi Martin, > > can we please finish this review? > > On 12/19/18 6:32 PM, Michal Vala wrote: > > > > > > On 12/19/18 4:15 PM, Martin Buchholz wrote: > >> On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs > wrote: > >> > >>> Hi Martin, > >>> > >>> It is also useful and conventional to print the seed of the random > >>> so that if necessary it can be reproduced. > >>> > >> > >> For many years, we've been using ThreadLocalRandom for testing, and that > >> does not allow setting a seed. > >> > >> I remain unconvinced that saving a seed has value in the real world. > When > >> a randomized test fails, running it with sufficient iterations has > always > >> worked for me. > >> > > > > What's the reason behind using ThreadLocalRandom? > > > > In my opinion, reproducing the issue is key. One failure of randomized > test run > > might be caused by one issue, second run due to another issue. How we > reproduce > > then and how we know even how many issues we have? When we're running > random > > tests until it pass, it might even hide the issue. > > > > They sure have good value on reveal the issue, but then we have to know > how to > > reproduce and what we're searching for. > > > > If this case would not require ThreadLocalRandom and Random is enough, > I'd like > > to use that because of benefits I've mentioned. > > > > -- > Michal Vala > OpenJDK QE > Red Hat Czech > From martinrb at google.com Wed Feb 6 19:18:13 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 6 Feb 2019 11:18:13 -0800 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: Thomas, thanks for your hard work on this. We need to update my old analysis in src/java.base/unix/native/libjava/ProcessImpl_md.c You now understand the problem better than I ever did, so you are best to update it (most of the content can be taken from your analysis in JIRA). From thomas.stuefe at gmail.com Wed Feb 6 20:01:18 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 6 Feb 2019 21:01:18 +0100 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: Hi Martin, On Wed, Feb 6, 2019 at 8:18 PM Martin Buchholz wrote: > Thomas, thanks for your hard work on this. > > We need to update my old analysis in > src/java.base/unix/native/libjava/ProcessImpl_md.c > You now understand the problem better than I ever did, > I very much doubt that :-) > so you are best to update it (most of the content can be taken from your > analysis in JIRA). > Of course, that makes sense. I'll post an update tomorrow. Cheers, Thomas From mandy.chung at oracle.com Wed Feb 6 20:13:49 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 6 Feb 2019 12:13:49 -0800 Subject: Review Request JDK-8218461: test/jdk/java/lang/invoke/VarHandles should be generated rather than manually edited Message-ID: This patch fixes up X-VarHandleTest* template files that are used to generate VarHandles tests. Since VarHandle::equals and VarHandle::hashCode methods are no longer implemented [1], I rename the testEqualsAndHashCode method to testEquals and further clean up the test case. Webrev: http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8218461/webrev.00/ Thanks Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8215648 From brian.burkhalter at oracle.com Wed Feb 6 20:22:43 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Feb 2019 12:22:43 -0800 Subject: Review Request JDK-8218461: test/jdk/java/lang/invoke/VarHandles should be generated rather than manually edited In-Reply-To: References: Message-ID: <91361245-D816-44B3-A493-BD8C5B373177@oracle.com> Hi Mandy, I verified that running the script generates the same test files which are checked in to the repo, as it should be. Someone else should review the actual test template content however. Thanks, Brian > On Feb 6, 2019, at 12:13 PM, Mandy Chung wrote: > > This patch fixes up X-VarHandleTest* template files that are > used to generate VarHandles tests. Since VarHandle::equals > and VarHandle::hashCode methods are no longer implemented [1], > I rename the testEqualsAndHashCode method to testEquals > and further clean up the test case. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8218461/webrev.00/ > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8215648 From brian.burkhalter at oracle.com Wed Feb 6 20:45:03 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Feb 2019 12:45:03 -0800 Subject: Review Request JDK-8218461: test/jdk/java/lang/invoke/VarHandles should be generated rather than manually edited In-Reply-To: References: <91361245-D816-44B3-A493-BD8C5B373177@oracle.com> Message-ID: > On Feb 6, 2019, at 12:44 PM, Mandy Chung wrote: > >> I verified that running the script generates the same test files which are checked in to the repo, as it should be. > > Thanks for verifying. The tests shown in the webrev are generated > by the script, not manually edited. Right, hence the match. >> Someone else should review the actual test template content however. > > Vicente will review it too. Good. Brian From mandy.chung at oracle.com Wed Feb 6 20:44:02 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 6 Feb 2019 12:44:02 -0800 Subject: Review Request JDK-8218461: test/jdk/java/lang/invoke/VarHandles should be generated rather than manually edited In-Reply-To: <91361245-D816-44B3-A493-BD8C5B373177@oracle.com> References: <91361245-D816-44B3-A493-BD8C5B373177@oracle.com> Message-ID: On 2/6/19 12:22 PM, Brian Burkhalter wrote: > Hi Mandy, > > I verified that running the script generates the same test files which > are checked in to the repo, as it should be. Thanks for verifying. The tests shown in the webrev are generated by the script, not manually edited. > Someone else should review the actual test template content however. Vicente will review it too. thanks Mandy > Thanks, > > Brian > >> On Feb 6, 2019, at 12:13 PM, Mandy Chung > > wrote: >> >> This patch fixes up X-VarHandleTest* template files that are >> used to generate VarHandles tests. ?Since VarHandle::equals >> and VarHandle::hashCode methods are no longer implemented [1], >> I rename the testEqualsAndHashCode method to testEquals >> and further clean up the test case. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8218461/webrev.00/ >> >> Thanks >> Mandy >> [1]https://bugs.openjdk.java.net/browse/JDK-8215648 > From sergei.tsypanov at yandex.ru Wed Feb 6 21:26:38 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Wed, 06 Feb 2019 23:26:38 +0200 Subject: [PATCH] Improvements in jdk.internal.org.objectweb.asm.Type Message-ID: <2405631549488398@myt6-23299ba78d64.qloud-c.yandex.net> Hello, several days ago I?ve proposed some improvements into asm library: - https://gitlab.ow2.org/asm/asm/commit/ef945457bc19dbc09c02bd21b52f1950990f33f7 - https://gitlab.ow2.org/asm/asm/commit/9b914d524b7fe7ea694fc11ec784e67133ba383f The patches were accepted and then it turned out the code I?ve patched is similar to what we have in JDK. So I propose the same changes to be accepted into JDK 12. They improve code by using more simple constructions and replacing redundant hand-written code with JDK-provided API. As of performance, usage of String::replace instead of handwritten replacement (see Type::appendDescriptor) is much faster and memory-effective (tested with JDK 11) even on simplest class names like java.lang.String: Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ? Score? ? Error? Units CharacterReplaceBenchmark.manualReplace? ? ? ? ? ? ? ? ? ? ? ? avgt? 25? ? 57,036 ?? 1,132? ns/op CharacterReplaceBenchmark.stringReplace? ? ? ? ? ? ? ? ? ? ? ? avgt? 25? ? 17,648 ?? 0,699? ns/op CharacterReplaceBenchmark.manualReplace:?gc.alloc.rate.norm? ? avgt? 25? 112,000 ?? 0,001? ? B/op CharacterReplaceBenchmark.stringReplace:?gc.alloc.rate.norm? ? avgt? 25? ? 56,000 ?? 0,001? ? B/op Corresponding benchmark available here: https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/string/CharacterReplaceBenchmark.java https://github.com/stsypanov/benchmarks/blob/master/benchmark-source/src/main/java/com/luxoft/logeek/string/CharacterReplacer.java Usage of String::substring instead of StringBuilder.append(CharSequence, int, int) (see Type::getDescriptor) is also faster and memory-effective, results described here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057834.html Also, is there any workload to measure effect of attached patch? Regards, Sergey Tsypanov -------------- next part -------------- A non-text attachment was scrubbed... Name: type_patch.txt Type: text/x-diff Size: 1991 bytes Desc: not available URL: From vicente.romero at oracle.com Wed Feb 6 21:32:50 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 6 Feb 2019 16:32:50 -0500 Subject: Review Request JDK-8218461: test/jdk/java/lang/invoke/VarHandles should be generated rather than manually edited In-Reply-To: References: Message-ID: looks good to me, Vicente On 2/6/19 3:13 PM, Mandy Chung wrote: > This patch fixes up X-VarHandleTest* template files that are > used to generate VarHandles tests.? Since VarHandle::equals > and VarHandle::hashCode methods are no longer implemented [1], > I rename the testEqualsAndHashCode method to testEquals > and further clean up the test case. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8218461/webrev.00/ > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8215648 From alexander.matveev at oracle.com Thu Feb 7 04:18:12 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 6 Feb 2019 20:18:12 -0800 Subject: RFR: JDK-8214564 : --win-upgrade-uuid does not work as expected Message-ID: <2bf909c9-8380-7959-d16a-134e16d3c440@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Upgrade did not work, because element was missing. Fixed by adding this element if --win-upgrade-uuid was provided. - Minor code clean up. Removed JPackageCreateImageBuildRootTest.java.rej. - Added JPackageCreateInstallerWinUpgradeUUIDTest for msi and exe. Note: For exe files which are not present in newer installation will not be removed. This is default behavior of InnoSetup installations. For msi older version will be completely removed before new one is installed. We will allow downgrades, upgrades and same version re-install for both msi and exe. [1] https://bugs.openjdk.java.net/browse/JDK-8214564 [2] http://cr.openjdk.java.net/~almatvee/8214564/webrev.00/ Thanks, Alexander From Alan.Bateman at oracle.com Thu Feb 7 08:42:09 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Feb 2019 08:42:09 +0000 Subject: [PATCH] Improvements in jdk.internal.org.objectweb.asm.Type In-Reply-To: <2405631549488398@myt6-23299ba78d64.qloud-c.yandex.net> References: <2405631549488398@myt6-23299ba78d64.qloud-c.yandex.net> Message-ID: <41596a6b-cbe2-6f92-193c-487910b721fe@oracle.com> On 06/02/2019 21:26, ?????? ??????? wrote: > Hello, > > several days ago I?ve proposed some improvements into asm library: > > - https://gitlab.ow2.org/asm/asm/commit/ef945457bc19dbc09c02bd21b52f1950990f33f7 > - https://gitlab.ow2.org/asm/asm/commit/9b914d524b7fe7ea694fc11ec784e67133ba383f > > > The patches were accepted and then it turned out the code I?ve patched is similar to what we have in JDK. > > So I propose the same changes to be accepted into JDK 12. They improve code by using more simple constructions and replacing redundant hand-written code with JDK-provided API. I assume the JDK will get your performance fix at the next ASM refresh. We've tried to avoid changes to ASM where possible as it complicates upgrading. There are of course times when the JDK's copy of ASM is modified to support changes to the class file before they are finalized and in a ASM release but we usually don't apply other patches unless they are really needed. -Alan From Roger.Riggs at oracle.com Thu Feb 7 14:53:41 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 7 Feb 2019 09:53:41 -0500 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: <6cdc7212-a470-d1a0-4640-177289dd595a@oracle.com> Hi Thomas, The CI tests here ran fine. Overall looks ok. Regards, Roger On 02/06/2019 01:16 PM, Thomas St?fe wrote: > Hi Roger, > > On Wed, Feb 6, 2019 at 4:15 PM Roger Riggs > wrote: > > Hi Thomas, > > On 02/06/2019 04:29 AM, Thomas St?fe wrote: >> Hi all >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html >> >> >> (@Roger: I hope you do not mind? The bug is assigned to you but >> since I happened to play around with posix_spawn I prepared this >> webrev. If you rather do this change, that is fine and I will >> leave it to you.) > no problem, I hadn't gotten to it.? Thanks for proposing it. >> >> When we added the possibility to use posix_spawn as underlying >> implementation for Runtime.exec() on Linux with >> https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to >> keep VFORK as default until work on 13 starts. So now would be a >> good time to switch the default to posix_spawn to get a good >> testing window. Note that at SAP we run our VMs internally with >> posix_spawn as default since some months and have not seen problems. >> >> As for the fix, I added a test which tests that the default is >> indeed posix_spawn - not sure whether this is overdoing it >> though. Also, I use strace for the test, and /bin/true, and while >> strace is usually available and reachable by path resolution, I >> am afraid on some test machines it may not. What do you think, >> should I leave the test out? > The test is a bit quirky but should work ok. > I'd leave it in until it fails and re-evaluate then. > > If it fails on some systems, we can either configure them out or > just skip the test if the process launch of strace fails. (Throw > SkippedException). >> > Yes, that makes sense. > >> The fix ran through all java/lang/ProcessBuilder jtreg tests ok. > I'll run the patch through the usual CI build here too. > > > Thanks. I'll run the test thru the submit repository too. > > Cheers, Thomas > > Thanks, Roger > >> >> Thanks, Thomas >> > From goetz.lindenmaier at sap.com Thu Feb 7 16:43:24 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Feb 2019 16:43:24 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. Message-ID: <7c4b0bc27961471e91195bef9e767226@sap.com> Hi, since Java 5, our internal VM reports verbose null pointer exception messages. I would like to contribute this feature to OpenJDK. With this change, messages as "java.lang.NullPointerException: while trying to load from a null int array loaded from local variable 'ia1'" are printed. For more examples see the JBS bug or the test included. https://bugs.openjdk.java.net/browse/JDK-8218628 The messages are generated by parsing the bytecodes. For not to have any overhead when the NPE is allocated, the message is only generated when it is accessed by getMessage() or serialization. For this I added a field to NPE to indicate that the message still needs to be computed lazily. Please review: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/01/ I'm happy to incorporate your comments. Best regards, Goetz From thomas.stuefe at gmail.com Thu Feb 7 17:01:44 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 7 Feb 2019 18:01:44 +0100 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: Hi all, second version, including the updated comment in ProcessImpl.c Martin requested: http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html @Roger: thanks for feeding this into your tests. I still try to get it to run thru jdk-submit, but that seems to be stuck again.. Cheers, Thomas On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe wrote: > Hi all > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html > > (@Roger: I hope you do not mind? The bug is assigned to you but since I > happened to play around with posix_spawn I prepared this webrev. If you > rather do this change, that is fine and I will leave it to you.) > > When we added the possibility to use posix_spawn as underlying > implementation for Runtime.exec() on Linux with > https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep VFORK > as default until work on 13 starts. So now would be a good time to switch > the default to posix_spawn to get a good testing window. Note that at SAP > we run our VMs internally with posix_spawn as default since some months and > have not seen problems. > > As for the fix, I added a test which tests that the default is indeed > posix_spawn - not sure whether this is overdoing it though. Also, I use > strace for the test, and /bin/true, and while strace is usually available > and reachable by path resolution, I am afraid on some test machines it may > not. What do you think, should I leave the test out? > > The fix ran through all java/lang/ProcessBuilder jtreg tests ok. > > Thanks, Thomas > > From andy.herrick at oracle.com Thu Feb 7 17:11:09 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 7 Feb 2019 12:11:09 -0500 Subject: RFR: JDK-8217687: jpackage --help improvements Message-ID: <64b36526-bac4-463a-efe3-2983a84545f0@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). JDK-8217687: jpackage --help improvements Changes to help text, internal names, and several tests. [1] https://bugs.openjdk.java.net/browse/JDK-8217687 [2] http://cr.openjdk.java.net/~herrick/8217687/webrev.01/ From andy.herrick at oracle.com Thu Feb 7 17:12:09 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 7 Feb 2019 12:12:09 -0500 Subject: RFR: JDK-8214564 : --win-upgrade-uuid does not work as expected In-Reply-To: <2bf909c9-8380-7959-d16a-134e16d3c440@oracle.com> References: <2bf909c9-8380-7959-d16a-134e16d3c440@oracle.com> Message-ID: <44ab5f23-ed6b-c029-c5aa-41e051262bea@oracle.com> looks good to me. /ANdy On 2/6/2019 11:18 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Upgrade did not work, because element was missing. > Fixed by adding this element if --win-upgrade-uuid was provided. > - Minor code clean up. Removed JPackageCreateImageBuildRootTest.java.rej. > - Added JPackageCreateInstallerWinUpgradeUUIDTest for msi and exe. > Note: For exe files which are not present in newer installation will > not be removed. This is default behavior of InnoSetup installations. > For msi older version will be completely removed before new one is > installed. We will allow downgrades, upgrades and same version > re-install for both msi and exe. > > [1] https://bugs.openjdk.java.net/browse/JDK-8214564 > > [2] http://cr.openjdk.java.net/~almatvee/8214564/webrev.00/ > > Thanks, > Alexander From martinrb at google.com Thu Feb 7 18:09:16 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 7 Feb 2019 10:09:16 -0800 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: This is very good. Approved. But as always I have review suggestions typos: ithe Preceede => Precede Drop "the" How does the glibc implement posix_spawn? How does the muslc implement posix_spawn? parents => the parent CLONE_VFORK means parents waits until we exec, as with (2) an own => a separate we pass an own stack for the child to run on Did you mean tlrd => TL;DR ? https://en.wikipedia.org/wiki/TL;DR You can drop the pre-2004 part from the TL;DR 164 * tlrd: calling posix_spawn(3) for glibc 165 * (1) < 2.4 would expose us to memory overcommit problems. But this glibc is The test is still too brittle for my taste. I would check for the existence of /usr/bin/strace (and /bin/true !) and quietly skip the test if not found. I don't like uninformative prints System.out.print("I'm the child. Will fork /bin/true now..."); Instead I might be truly interested in whether the strace output contains fork|vfork|clone fyi I have a wrapper around strace for process-related syscalls #!/bin/bash /usr/bin/strace -f -v -s 256 -e signal=none -e trace=process "$@" On Thu, Feb 7, 2019 at 9:01 AM Thomas St?fe wrote: > Hi all, > > second version, including the updated comment in ProcessImpl.c Martin > requested: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html > > @Roger: thanks for feeding this into your tests. I still try to get it to > run thru jdk-submit, but that seems to be stuck again.. > > Cheers, Thomas > > > > > > On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe > wrote: > >> Hi all >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html >> >> (@Roger: I hope you do not mind? The bug is assigned to you but since I >> happened to play around with posix_spawn I prepared this webrev. If you >> rather do this change, that is fine and I will leave it to you.) >> >> When we added the possibility to use posix_spawn as underlying >> implementation for Runtime.exec() on Linux with >> https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep >> VFORK as default until work on 13 starts. So now would be a good time to >> switch the default to posix_spawn to get a good testing window. Note that >> at SAP we run our VMs internally with posix_spawn as default since some >> months and have not seen problems. >> >> As for the fix, I added a test which tests that the default is indeed >> posix_spawn - not sure whether this is overdoing it though. Also, I use >> strace for the test, and /bin/true, and while strace is usually available >> and reachable by path resolution, I am afraid on some test machines it may >> not. What do you think, should I leave the test out? >> >> The fix ran through all java/lang/ProcessBuilder jtreg tests ok. >> >> Thanks, Thomas >> >> From Roger.Riggs at oracle.com Thu Feb 7 20:22:08 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 7 Feb 2019 15:22:08 -0500 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: Hi, I agree with Martin's editorial comments. I've had an eye on the helperPath methods and they could be removed; the path is no longer architecture specific and javahome is available statically; So the methods can be removed and helperpath reduces to: 172 private static final byte[] helperpath = toCString(StaticProperty.javaHome() + /lib/jspawnhelper"); If you think that's in scope, please apply; otherwise I'll fix it later. Thanks, Roger On 02/07/2019 01:09 PM, Martin Buchholz wrote: > This is very good.? Approved. > But as always I have review suggestions > > typos: > ithe > Preceede => Precede > > Drop "the" > How does the glibc implement posix_spawn? > How does the muslc implement posix_spawn? > > parents => the parent > CLONE_VFORK means parents waits until we exec, as with (2) > > an own => a separate > we pass an own stack for the child to run on > Did you mean tlrd => TL;DR ? https://en.wikipedia.org/wiki/TL;DR > You can drop the pre-2004 part from the TL;DR > 164? * tlrd: calling posix_spawn(3) for glibc > ?165? * (1) < 2.4 would expose us to memory overcommit problems. But > this glibc is > The test is still too brittle for my taste. > I would check? for the existence of /usr/bin/strace (and /bin/true !) > and quietly skip the test if not found. > > I don't like uninformative prints > ? ? ? ? System.out.print("I'm the child. Will fork /bin/true now..."); > Instead I might be truly interested in whether the strace output > contains fork|vfork|clone > > fyi I have a wrapper around strace for process-related syscalls > > #!/bin/bash > /usr/bin/strace -f -v -s 256 -e signal=none -e trace=process "$@" > > > > > On Thu, Feb 7, 2019 at 9:01 AM Thomas St?fe > wrote: > > Hi all, > > second version, including the updated comment in ProcessImpl.c > Martin requested: > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html > > > @Roger: thanks for feeding this into your tests. I still try to > get it to run thru jdk-submit, but that seems to be stuck again.. > > Cheers, Thomas > > > > > > On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe > > wrote: > > Hi all > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html > > > (@Roger: I hope you do not mind? The bug is assigned to you > but since I happened to play around with posix_spawn I > prepared this webrev. If you rather do this change, that is > fine and I will leave it to you.) > > When we added the possibility to use posix_spawn as underlying > implementation for Runtime.exec() on Linux with > https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to > keep VFORK as default until work on 13 starts. So now would be > a good time to switch the default to posix_spawn to get a good > testing window. Note that at SAP we run our VMs internally > with posix_spawn as default since some months and have not > seen problems. > > As for the fix, I added a test which tests that the default is > indeed posix_spawn - not sure whether this is overdoing it > though. Also, I use strace for the test, and /bin/true, and > while strace is usually available and reachable by path > resolution, I am afraid on some test machines it may not. What > do you think, should I leave the test out? > > The fix ran through all java/lang/ProcessBuilder jtreg tests ok. > > Thanks, Thomas > From alexander.matveev at oracle.com Thu Feb 7 22:11:10 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 7 Feb 2019 14:11:10 -0800 Subject: RFR: JDK-8217687: jpackage --help improvements In-Reply-To: <64b36526-bac4-463a-efe3-2983a84545f0@oracle.com> References: <64b36526-bac4-463a-efe3-2983a84545f0@oracle.com> Message-ID: Hi Andy, http://cr.openjdk.java.net/~herrick/8217687/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties.frames.html Line 140: I think we do not need " at the end. Otherwise looks fine. Thanks, Alexander On 2/7/2019 9:11 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > JDK-8217687: jpackage --help improvements > > Changes to help text, internal names, and several tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217687 > > [2] http://cr.openjdk.java.net/~herrick/8217687/webrev.01/ > > > From david.holmes at oracle.com Fri Feb 8 00:05:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Feb 2019 10:05:30 +1000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <7c4b0bc27961471e91195bef9e767226@sap.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> Message-ID: Hi Volker, You know I'm not going to be a big fan of this :), but as long as we don't pay for it if we don't want it, then that's okay. (I'm still trying to gauge that) I have a little test for this that I ran through your patch: public class NPE { static class B { C b() { return null; } } static class C { int c(Object o, String s) { return 0; } } public static void main(String[] args) { int x = a().b().c(d(), e().toString()); } static B a() { return null; } static Object d() { return null; } static Object e() { return null; } } and the result was a bit confusing for me: java.lang.NullPointerException: while trying to invoke the method NPE$B.b(()LNPE$C;) of a null object returned from NPE.a(()LNPE$B;) The placement and format of the return type descriptors obfuscates things to me - especially the Lxxx; format. Can we make that more Java programmer friendly eg: "while trying to invoke the method 'NPE$C NPE$B.b()' ..." though I think trying to produce signatures within the message is going to be very awkward in the general case. The key part is the "method NPE.b() ... returned from NPE.a()" Also "of a null object" would read better as "on a null reference". A couple of initial comments First you will need to file a CSR request for the new product flags. Second, I don't understand why you need to call into the VM with JVM_SetDefaultMessage, to set a field in the Java object? Why isn't that done in Java? Thanks, David On 8/02/2019 2:43 am, Lindenmaier, Goetz wrote: > Hi, > > since Java 5, our internal VM reports verbose null pointer exception > messages. I would like to contribute this feature to OpenJDK. > > With this change, messages as > "java.lang.NullPointerException: while trying to load from a null int array loaded from local variable 'ia1'" > are printed. For more examples see the JBS bug or the test included. > https://bugs.openjdk.java.net/browse/JDK-8218628 > > The messages are generated by parsing the bytecodes. For not to have any overhead when the > NPE is allocated, the message is only generated when it is accessed by getMessage() or > serialization. For this I added a field to NPE to indicate that the message still needs to be > computed lazily. > > Please review: > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/01/ > I'm happy to incorporate your comments. > > Best regards, > Goetz > > From david.holmes at oracle.com Fri Feb 8 00:14:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Feb 2019 10:14:30 +1000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> Message-ID: <9ae5d5e5-a6e2-464d-7fc1-9aea64a005d9@oracle.com> In 8/02/2019 10:05 am, David Holmes wrote: > Hi Volker, Aaarggh!! Sorry Volker and Goetz. No idea where that came from. David ----- > You know I'm not going to be a big fan of this :), but as long as we > don't pay for it if we don't want it, then that's okay. (I'm still > trying to gauge that) > > I have a little test for this that I ran through your patch: > > public class NPE { > ? static class B { > ??? C b() { return null; } > ? } > ? static class C { > ??? int c(Object o, String s) {? return 0; } > ? } > > ? public static void main(String[] args) { > ??? int x? = a().b().c(d(), e().toString()); > ? } > > ? static B a() { return null; } > ? static Object d() { return null; } > ? static Object e() { return null; } > > } > > and the result was a bit confusing for me: > > java.lang.NullPointerException: while trying to invoke the method > NPE$B.b(()LNPE$C;) of a null object returned from NPE.a(()LNPE$B;) > > The placement and format of the return type descriptors obfuscates > things to me - especially the Lxxx; format. Can we make that more Java > programmer friendly eg: > > "while trying to invoke the method 'NPE$C NPE$B.b()' ..." > > though I think trying to produce signatures within the message is going > to be very awkward in the general case. The key part is the "method > NPE.b() ... returned from NPE.a()" > > Also "of a null object" would read better as "on a null reference". > > > A couple of initial comments > > First you will need to file a CSR request for the new product flags. > > Second, I don't understand why you need to call into the VM with > JVM_SetDefaultMessage, to set a field in the Java object? Why isn't that > done in Java? > > Thanks, > David > > On 8/02/2019 2:43 am, Lindenmaier, Goetz wrote: >> Hi, >> >> since Java 5, our internal VM reports verbose null pointer exception >> messages. I would like to contribute this feature to OpenJDK. >> >> With this change, messages as >> ??? "java.lang.NullPointerException: while trying to load from a null >> int array loaded from local variable 'ia1'" >> are printed.? For more examples see the JBS bug or the test included. >> https://bugs.openjdk.java.net/browse/JDK-8218628 >> >> The messages are generated by parsing the bytecodes. For not to have >> any overhead when the >> NPE is allocated, the message is only generated when it is accessed by >> getMessage() or >> serialization. For this I added a field to NPE to indicate that the >> message still needs to be >> computed lazily. >> >> Please review: >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/01/ >> I'm happy to incorporate your comments. >> >> Best regards, >> ?? Goetz >> >> From ivan.gerasimov at oracle.com Fri Feb 8 01:02:30 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 7 Feb 2019 17:02:30 -0800 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument Message-ID: Hello! The specification states: """ If the length of the specified CharSequence is less than or equal to zero, then an empty buffer of capacity 16 is returned. """ However, the current implementation throws either NegativeArraySizeException or IndexOutOfBounds instead (the actual exception type depends on the value of reported negative length). It is proposed to do two things: 1) remove the problematic sentence from the javadoc (CSR is filed). 2) unify the exception type thrown, if the argument reports negative length. NegativeArraySizeException will be consistent with, for example, StringBuffer(negativeCapacity). Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Fri Feb 8 01:16:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Feb 2019 11:16:47 +1000 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: References: Message-ID: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> Hi Ivan, On 8/02/2019 11:02 am, Ivan Gerasimov wrote: > Hello! > > The specification states: > """ > If the length of the specified CharSequence is less than or equal to > zero, then an empty buffer of capacity 16 is returned. > """ > > However, the current implementation throws either > NegativeArraySizeException or IndexOutOfBounds instead (the actual > exception type depends on the value of reported negative length). How can you have a negative length CharSequence ?? If its an empty CharSequence then it should return the empty buffer as indicated. Cheers, David > It is proposed to do two things: > 1) remove the problematic sentence from the javadoc (CSR is filed). > 2) unify the exception type thrown, if the argument reports negative > length. > NegativeArraySizeException will be consistent with, for example, > StringBuffer(negativeCapacity). > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 > WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ > CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 > From ivan.gerasimov at oracle.com Fri Feb 8 01:59:41 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 7 Feb 2019 17:59:41 -0800 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> Message-ID: <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> Hi David! On 2/7/19 5:16 PM, David Holmes wrote: > Hi Ivan, > > On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >> Hello! >> >> The specification states: >> """ >> If the length of the specified CharSequence is less than or equal to >> zero, then an empty buffer of capacity 16 is returned. >> """ >> >> However, the current implementation throws either >> NegativeArraySizeException or IndexOutOfBounds instead (the actual >> exception type depends on the value of reported negative length). > > How can you have a negative length CharSequence ?? > A custom CharSequence returning negative length() can be created. Not sure how useful/popular this may be, though. That's why I propose just removing the mentioning negative length, and not changing the behavior. The proposed code change is to only unify the behavior for any negative value of length. > If its an empty CharSequence then it should return the empty buffer as > indicated. > Empty CharSequence is processed correctly already. With kind regards, Ivan > Cheers, > David > >> It is proposed to do two things: >> 1) remove the problematic sentence from the javadoc (CSR is filed). >> 2) unify the exception type thrown, if the argument reports negative >> length. >> NegativeArraySizeException will be consistent with, for example, >> StringBuffer(negativeCapacity). >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >> > -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Fri Feb 8 02:33:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Feb 2019 12:33:04 +1000 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> Message-ID: On 8/02/2019 11:59 am, Ivan Gerasimov wrote: > Hi David! > > > On 2/7/19 5:16 PM, David Holmes wrote: >> Hi Ivan, >> >> On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >>> Hello! >>> >>> The specification states: >>> """ >>> If the length of the specified CharSequence is less than or equal to >>> zero, then an empty buffer of capacity 16 is returned. >>> """ >>> >>> However, the current implementation throws either >>> NegativeArraySizeException or IndexOutOfBounds instead (the actual >>> exception type depends on the value of reported negative length). >> >> How can you have a negative length CharSequence ?? >> > A custom CharSequence returning negative length() can be created. > Not sure how useful/popular this may be, though. Seems pretty meaningless so just treating that as an error seems fine. Though somewhat debatable whether you need to add an appropriate @throws. > That's why I propose just removing the mentioning negative length, and > not changing the behavior. > > The proposed code change is to only unify the behavior for any negative > value of length. Ok. >> If its an empty CharSequence then it should return the empty buffer as >> indicated. >> > Empty CharSequence is processed correctly already. Okay so by removing this part: - *

- * If the length of the specified {@code CharSequence} is - * less than or equal to zero, then an empty buffer of capacity - * {@code 16} is returned. you're relying on the main specification to implicitly handle the empty case. David ----- > With kind regards, > Ivan > >> Cheers, >> David >> >>> It is proposed to do two things: >>> 1) remove the problematic sentence from the javadoc (CSR is filed). >>> 2) unify the exception type thrown, if the argument reports negative >>> length. >>> NegativeArraySizeException will be consistent with, for example, >>> StringBuffer(negativeCapacity). >>> >>> Would you please help review the fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >>> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >>> >> > From ivan.gerasimov at oracle.com Fri Feb 8 03:19:37 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 7 Feb 2019 19:19:37 -0800 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> Message-ID: On 2/7/19 6:33 PM, David Holmes wrote: > On 8/02/2019 11:59 am, Ivan Gerasimov wrote: >> Hi David! >> >> >> On 2/7/19 5:16 PM, David Holmes wrote: >>> Hi Ivan, >>> >>> On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> The specification states: >>>> """ >>>> If the length of the specified CharSequence is less than or equal >>>> to zero, then an empty buffer of capacity 16 is returned. >>>> """ >>>> >>>> However, the current implementation throws either >>>> NegativeArraySizeException or IndexOutOfBounds instead (the actual >>>> exception type depends on the value of reported negative length). >>> >>> How can you have a negative length CharSequence ?? >>> >> A custom CharSequence returning negative length() can be created. >> Not sure how useful/popular this may be, though. > > Seems pretty meaningless so just treating that as an error seems fine. > Though somewhat debatable whether you need to add an appropriate @throws. > Right. There were two reasons not to add @throws here: - by removing the problematic paragraph we just make the javadoc almost the same as for StringBuilder(CharSequence), - we don't seem to have any other places (at least I couldn't find any) specifying exceptions due to negatively sized CharSequence. (To be precise, there is one candidate, but I'll file a separate bug to fix it.) >> That's why I propose just removing the mentioning negative length, >> and not changing the behavior. >> >> The proposed code change is to only unify the behavior for any >> negative value of length. > > Ok. > >>> If its an empty CharSequence then it should return the empty buffer >>> as indicated. >>> >> Empty CharSequence is processed correctly already. > > Okay so by removing this part: > > - *

> - * If the length of the specified {@code CharSequence} is > - * less than or equal to zero, then an empty buffer of capacity > - * {@code 16} is returned. > > you're relying on the main specification to implicitly handle the > empty case. > Yes. With kind regards, Ivan > David > ----- > >> With kind regards, >> Ivan >> >>> Cheers, >>> David >>> >>>> It is proposed to do two things: >>>> 1) remove the problematic sentence from the javadoc (CSR is filed). >>>> 2) unify the exception type thrown, if the argument reports >>>> negative length. >>>> NegativeArraySizeException will be consistent with, for example, >>>> StringBuffer(negativeCapacity). >>>> >>>> Would you please help review the fix? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >>>> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >>>> >>> >> > -- With kind regards, Ivan Gerasimov From thomas.stuefe at gmail.com Fri Feb 8 09:38:51 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 8 Feb 2019 10:38:51 +0100 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: Hi Roger, Martin, next version: http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.02/webrev - did massage the comment in ProcessImpl.c - made the test more resilient by scanning for the strace tool and by silently ignoring all problems stemming from strace or the payload binary not being there. The test now only fails if the forks were successully executed but it does not seem to use posix-spawn. - added output to the test by printing the "interesting" lines of the strace output. Note that this filtering is not really sophisticated and will show all thread related clone() calls as well: 614 [pid 12447] <... clone resumed> child_stack=0x7fe00c4baff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fe00c4bb9d0, tls=0x7fe00c4bb700, child_tidptr=0x7fe00c4bb9d0) = 12452 646 [pid 12447] clone(/usr/bin/strace: Process 12453 attached 649 [pid 12447] <... clone resumed> child_stack=0x7fe00c3b9ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fe00c3ba9d0, tls=0x7fe00c3ba700, child_tidptr=0x7fe00c3ba9d0) = 12453 .... I am sure this could be made more intelligent but lets keep it simple for now. - I removed the helperPath() methods Roger mentioned, they are not needed anymore. @Martin: I like the -e signal=none -e trace=process idea but I'm not sure if all versions of strace support these options. I think the strace output is small enough for this small use case, some kB only. Cheers, Thomas On Thu, Feb 7, 2019 at 6:01 PM Thomas St?fe wrote: > Hi all, > > second version, including the updated comment in ProcessImpl.c Martin > requested: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html > > @Roger: thanks for feeding this into your tests. I still try to get it to > run thru jdk-submit, but that seems to be stuck again.. > > Cheers, Thomas > > > > > > On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe > wrote: > >> Hi all >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html >> >> (@Roger: I hope you do not mind? The bug is assigned to you but since I >> happened to play around with posix_spawn I prepared this webrev. If you >> rather do this change, that is fine and I will leave it to you.) >> >> When we added the possibility to use posix_spawn as underlying >> implementation for Runtime.exec() on Linux with >> https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep >> VFORK as default until work on 13 starts. So now would be a good time to >> switch the default to posix_spawn to get a good testing window. Note that >> at SAP we run our VMs internally with posix_spawn as default since some >> months and have not seen problems. >> >> As for the fix, I added a test which tests that the default is indeed >> posix_spawn - not sure whether this is overdoing it though. Also, I use >> strace for the test, and /bin/true, and while strace is usually available >> and reachable by path resolution, I am afraid on some test machines it may >> not. What do you think, should I leave the test out? >> >> The fix ran through all java/lang/ProcessBuilder jtreg tests ok. >> >> Thanks, Thomas >> >> From christoph.langer at sap.com Fri Feb 8 10:50:42 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Feb 2019 10:50:42 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <7c4b0bc27961471e91195bef9e767226@sap.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> Message-ID: <2c3fddb906624bd9822973d689756a4d@sap.com> Hi Goetz, thanks for bringing this into OpenJDK finally. I know of people that'll be quite happy about this feature. I had a quick glance through the code. Here are a few findings: src/java.base/share/classes/java/lang/NullPointerException.java: line 56: remove a space before the comment line 62: private transient boolean lazyComputeDefaultMessage; I think the name for this variable is not well chosen. I'd prefer lazyComputeMessage, because it's not a default message, it's rather "the" message of the exception. Then, I think you should initialize the field right away in this line to true, no need to do it in the constructor. (Or can't that be done for transient fields?? ??) 122 private native void setDefaultMessage(String extendedMessage); Here, I agree with David, that you should do it in Java. Just use a shared secret, then you don't even need reflection... It also should not be "setDefaultMessage" but rather "setMessage". Best regards Christoph > -----Original Message----- > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of Lindenmaier, Goetz > Sent: Donnerstag, 7. Februar 2019 17:43 > To: hotspot-runtime-dev at openjdk.java.net; Java Core Libs dev at openjdk.java.net> > Subject: [CAUTION] RFR(L): 8218628: Add detailed message to > NullPointerException describing what is null. > > Hi, > > since Java 5, our internal VM reports verbose null pointer exception > messages. I would like to contribute this feature to OpenJDK. > > With this change, messages as > "java.lang.NullPointerException: while trying to load from a null int array > loaded from local variable 'ia1'" > are printed. For more examples see the JBS bug or the test included. > https://bugs.openjdk.java.net/browse/JDK-8218628 > > The messages are generated by parsing the bytecodes. For not to have any > overhead when the > NPE is allocated, the message is only generated when it is accessed by > getMessage() or > serialization. For this I added a field to NPE to indicate that the message still > needs to be > computed lazily. > > Please review: > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/01/ > I'm happy to incorporate your comments. > > Best regards, > Goetz > From christoph.langer at sap.com Fri Feb 8 11:05:20 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Feb 2019 11:05:20 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <2c3fddb906624bd9822973d689756a4d@sap.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <2c3fddb906624bd9822973d689756a4d@sap.com> Message-ID: <333d0c4420904515af01a31a432124ba@sap.com> > 122 private native void setDefaultMessage(String extendedMessage); > Here, I agree with David, that you should do it in Java. Just use a shared > secret, then you don't even need reflection... Addition: you should not even need to use a shared secret as Throwable and NPE are in the same package. Just add some package private setter to Throwable's detailMessage. From goetz.lindenmaier at sap.com Fri Feb 8 11:51:28 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 8 Feb 2019 11:51:28 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> Message-ID: Hi David, > Hi Volker, ... I assume Volker could have contributed this as well, but actually I must mention Ralf Schmelter as the original author of this :) > You know I'm not going to be a big fan of this :), but as long as we > don't pay for it if we don't want it, then that's okay. (I'm still > trying to gauge that) > > I have a little test for this that I ran through your patch: > > public class NPE { > static class B { > C b() { return null; } > } > static class C { > int c(Object o, String s) { return 0; } > } > > public static void main(String[] args) { > int x = a().b().c(d(), e().toString()); > } > > static B a() { return null; } > static Object d() { return null; } > static Object e() { return null; } > > } > > and the result was a bit confusing for me: > > java.lang.NullPointerException: while trying to invoke the method > NPE$B.b(()LNPE$C;) of a null object returned from NPE.a(()LNPE$B;) > > The placement and format of the return type descriptors obfuscates > things to me - especially the Lxxx; format. Can we make that more Java > programmer friendly eg: > > "while trying to invoke the method 'NPE$C NPE$B.b()' ..." > > though I think trying to produce signatures within the message is going > to be very awkward in the general case. The key part is the "method > NPE.b() ... returned from NPE.a()" Actually, I have left out code that changes the signatures to the Java source code wording. I already left that out in my former exception message contributions. For example see the messages in jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, they have the same bad format: "class test.Runner4 tried to access private method test.IllegalAccessErrorTest.iae4_m()V" I would like to fix them altogether in a follow-up, is that acceptable to you? > Also "of a null object" would read better as "on a null reference". Makes sense, fixed. But I'm not that sure about changing these: "while trying to read the field '%s' of a null object" --> "while trying to read the field '%s' from a null reference" "while trying to write the field %s of a null object" --> "while trying to write the field %s of a null reference" > First you will need to file a CSR request for the new product flags. I'm not sure whether I need the product flags altogether. I would prefer removing them. > Second, I don't understand why you need to call into the VM with > JVM_SetDefaultMessage, to set a field in the Java object? Why isn't that > done in Java? Obviously, the problem is that the field is private. As Christoph points out, there are several ways to implement this. Please give advice: * reflection * shared secret * Add package visible "void setMessage (String msg)" to Throwable. Best regards, Goetz > > Thanks, > David > > On 8/02/2019 2:43 am, Lindenmaier, Goetz wrote: > > Hi, > > > > since Java 5, our internal VM reports verbose null pointer exception > > messages. I would like to contribute this feature to OpenJDK. > > > > With this change, messages as > > "java.lang.NullPointerException: while trying to load from a null int array > loaded from local variable 'ia1'" > > are printed. For more examples see the JBS bug or the test included. > > https://bugs.openjdk.java.net/browse/JDK-8218628 > > > > The messages are generated by parsing the bytecodes. For not to have any > overhead when the > > NPE is allocated, the message is only generated when it is accessed by > getMessage() or > > serialization. For this I added a field to NPE to indicate that the message still > needs to be > > computed lazily. > > > > Please review: > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/01/ > > I'm happy to incorporate your comments. > > > > Best regards, > > Goetz > > > > From goetz.lindenmaier at sap.com Fri Feb 8 11:51:47 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 8 Feb 2019 11:51:47 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <2c3fddb906624bd9822973d689756a4d@sap.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <2c3fddb906624bd9822973d689756a4d@sap.com> Message-ID: <68c0c0ebe67040bab6f067218eb5c510@sap.com> Hi Christoph, thanks for looking at this. > src/java.base/share/classes/java/lang/NullPointerException.java: > line 56: > remove a space before the comment fixed. > line 62: private transient boolean lazyComputeDefaultMessage; > I think the name for this variable is not well chosen. I'd prefer > lazyComputeMessage, because it's not a default message, it's rather "the" > message of the exception. OK, removed 'default' > Then, I think you should initialize the field right away in this line to true, no > need to do it in the constructor. (Or can't that be done for transient fields?? ??) No, it must be initialized to false because there is a second constructor that uses a custom message (that was also the reason for the 'default' in the field name, it only applies to the constructor without custom message) > 122 private native void setDefaultMessage(String extendedMessage); > Here, I agree with David, that you should do it in Java. Just use a shared secret, > then you don't even need reflection... > It also should not be "setDefaultMessage" but rather "setMessage". Obviously, the problem is that the field is private. I see various ways to implement this. Please give advice: * reflection * shared secret * Add package visible "void setMessage (String msg)" to throwable. Best regards, Goetz. > > Best regards > Christoph > > > > -----Original Message----- > > From: hotspot-runtime-dev > bounces at openjdk.java.net> On Behalf Of Lindenmaier, Goetz > > Sent: Donnerstag, 7. Februar 2019 17:43 > > To: hotspot-runtime-dev at openjdk.java.net; Java Core Libs > dev at openjdk.java.net> > > Subject: [CAUTION] RFR(L): 8218628: Add detailed message to > > NullPointerException describing what is null. > > > > Hi, > > > > since Java 5, our internal VM reports verbose null pointer exception > > messages. I would like to contribute this feature to OpenJDK. > > > > With this change, messages as > > "java.lang.NullPointerException: while trying to load from a null int array > > loaded from local variable 'ia1'" > > are printed. For more examples see the JBS bug or the test included. > > https://bugs.openjdk.java.net/browse/JDK-8218628 > > > > The messages are generated by parsing the bytecodes. For not to have any > > overhead when the > > NPE is allocated, the message is only generated when it is accessed by > > getMessage() or > > serialization. For this I added a field to NPE to indicate that the message still > > needs to be > > computed lazily. > > > > Please review: > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/01/ > > I'm happy to incorporate your comments. > > > > Best regards, > > Goetz > > From david.holmes at oracle.com Fri Feb 8 12:30:56 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Feb 2019 22:30:56 +1000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> Message-ID: <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> Hi Goetz, Just one follow up for now: > * Add package visible "void setMessage (String msg)" to Throwable. Yes, just use package accessibility to deal with this, no need to jump through hoops (or the VM :) ). Thanks, David On 8/02/2019 9:51 pm, Lindenmaier, Goetz wrote: > Hi David, > >> Hi Volker, > ... I assume Volker could have contributed this as well, but actually > I must mention Ralf Schmelter as the original author of this :) > >> You know I'm not going to be a big fan of this :), but as long as we >> don't pay for it if we don't want it, then that's okay. (I'm still >> trying to gauge that) >> >> I have a little test for this that I ran through your patch: >> >> public class NPE { >> static class B { >> C b() { return null; } >> } >> static class C { >> int c(Object o, String s) { return 0; } >> } >> >> public static void main(String[] args) { >> int x = a().b().c(d(), e().toString()); >> } >> >> static B a() { return null; } >> static Object d() { return null; } >> static Object e() { return null; } >> >> } >> >> and the result was a bit confusing for me: >> >> java.lang.NullPointerException: while trying to invoke the method >> NPE$B.b(()LNPE$C;) of a null object returned from NPE.a(()LNPE$B;) >> >> The placement and format of the return type descriptors obfuscates >> things to me - especially the Lxxx; format. Can we make that more Java >> programmer friendly eg: >> >> "while trying to invoke the method 'NPE$C NPE$B.b()' ..." >> >> though I think trying to produce signatures within the message is going >> to be very awkward in the general case. The key part is the "method >> NPE.b() ... returned from NPE.a()" > Actually, I have left out code that changes the signatures to the > Java source code wording. I already left that out in my former > exception message contributions. For example see the messages in > jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, > they have the same bad format: > "class test.Runner4 tried to access private method test.IllegalAccessErrorTest.iae4_m()V" > > I would like to fix them altogether in a follow-up, is that acceptable to > you? > >> Also "of a null object" would read better as "on a null reference". > Makes sense, fixed. > > But I'm not that sure about changing these: > "while trying to read the field '%s' of a null object" > --> "while trying to read the field '%s' from a null reference" > "while trying to write the field %s of a null object" > --> "while trying to write the field %s of a null reference" > >> First you will need to file a CSR request for the new product flags. > I'm not sure whether I need the product flags altogether. I would > prefer removing them. > >> Second, I don't understand why you need to call into the VM with >> JVM_SetDefaultMessage, to set a field in the Java object? Why isn't that >> done in Java? > Obviously, the problem is that the field is private. > As Christoph points out, there are several ways to implement this. > Please give advice: > * reflection > * shared secret > * Add package visible "void setMessage (String msg)" to Throwable. > > Best regards, > Goetz > > >> >> Thanks, >> David >> >> On 8/02/2019 2:43 am, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> since Java 5, our internal VM reports verbose null pointer exception >>> messages. I would like to contribute this feature to OpenJDK. >>> >>> With this change, messages as >>> "java.lang.NullPointerException: while trying to load from a null int array >> loaded from local variable 'ia1'" >>> are printed. For more examples see the JBS bug or the test included. >>> https://bugs.openjdk.java.net/browse/JDK-8218628 >>> >>> The messages are generated by parsing the bytecodes. For not to have any >> overhead when the >>> NPE is allocated, the message is only generated when it is accessed by >> getMessage() or >>> serialization. For this I added a field to NPE to indicate that the message still >> needs to be >>> computed lazily. >>> >>> Please review: >>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/01/ >>> I'm happy to incorporate your comments. >>> >>> Best regards, >>> Goetz >>> >>> From amaembo at gmail.com Fri Feb 8 13:13:34 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 8 Feb 2019 20:13:34 +0700 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> Message-ID: Hello! > I would argue that iterating the argument and calling remove() on "this" are the > right semantics, because you want set membership to be determined by this set, > not by whatever collection you pass as an argument. However, I note that > AbstractCollection.removeAll and other removeAll implementations iterate over > "this" and do a contains() check on the argument. The revised > AbstractSet.removeAll would be an outlier here, though it makes sense to me to > do it this way. For complete picture it should be noted that there's a slight difference in remove and removeAll spec: remove removes at most one element while removeAll removes all elements from the specified collection. E.g. c.removeAll(Collections.singleton(foo)) would remove all instances of foo from c while c.remove(foo) would return only one foo. These should be equivalent for Set where repeating elements should not normally appear, but it's wrong for any Collection. That's why AbstractCollection.removeAll cannot be rewritten in the same way. Another interesting thing is java.util.IdentityHashMap.KeySet#removeAll implementation [1]: it reimplements the AbstractCollection#removeAll, because of the same reason: now the first branch of AbstractSet#removeAll becomes incorrect. See the comment before it: /* * Must revert from AbstractSet's impl to AbstractCollection's, as * the former contains an optimization that results in incorrect * behavior when c is a smaller "normal" (non-identity-based) Set. */ Btw this comment should be updated to remove a "smaller" condition if the proposed change for AbstractSet will be implemented. [1] http://hg.openjdk.java.net/jdk/jdk/file/e57bcfd7bf79/src/java.base/share/classes/java/util/IdentityHashMap.java#l990 With best regards, Tagir Valeev On Fri, Jan 25, 2019 at 7:11 AM Stuart Marks wrote: > > On 1/23/19 12:05 PM, Jan Peter Stotz wrote: > > like many other I ran into bug JDK-698217 which is about AbstractSet.removeAll() > > and it's "aptitude" in wasting CPU time if you accidentally hit this bug. And > > there are hundred of developers hitting this bug every year. > > > > I simply don't understand why there was no progress in 8 years, on a severe > > performance issue (a removeAll method on an efficient set that can require > > O(n^2)!) caused by code that was written to speed-up the removeAll implementation. > > > > Which makes this bug worse is that it is triggered by the relative size of the > > current set compared to the collection passed as parameter. > > Therefore for most developers this means not to use this buggy function at all > > (once they realized how worse it is). > > I wasn't aware that hundreds of developers are hitting this bug every year. I > haven't seen any mention of it (besides in the bug database) on Twitter, on > Reddit, on DZone, at the conferences I attend, or in several years of > core-libs-dev emails. Well, it was mentioned on core-libs-dev once in 2011 [1] > although that was a suggestion for improvement, not a complaint about performance. > > Nonetheless this is a real problem, and if it's causing difficulties we can > certainly take a look at it. > > There is, however, more to the story. The ACTUAL problem is a semantic one; see > JDK-6394757. [2] Briefly, consider x.removeAll(y). Depending on the relative > sizes of x and y, this method might end up using either x's or y's definition of > membership, which could differ from each other. (See the bug report for an > example.) Thus the semantics of this method depend upon the relative sizes of > the collections, which is arguably flawed. > > Worse, this behavior is specified to iterate this set or the argument, depending > upon their relative sizes. [3] So, fixing this will require an incompatible > specification change. > > The obvious way to fix this is to get rid of the "optimizations" (that turn out > not to be optimizations at all in some cases) and replace it with a simple loop: > > public boolean removeAll(Collection c) { > Objects.requireNonNull(c); > boolean modified = false; > for (Object e : c) > modified |= remove(e); > return modified; > } > > I would argue that iterating the argument and calling remove() on "this" are the > right semantics, because you want set membership to be determined by this set, > not by whatever collection you pass as an argument. However, I note that > AbstractCollection.removeAll and other removeAll implementations iterate over > "this" and do a contains() check on the argument. The revised > AbstractSet.removeAll would be an outlier here, though it makes sense to me to > do it this way. > > Is it worth the incompatibility? > > s'marks > > > > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html > > [2] https://bugs.openjdk.java.net/browse/JDK-6394757 > > [3] > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/AbstractSet.html#removeAll(java.util.Collection) > From andy.herrick at oracle.com Fri Feb 8 13:28:30 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 8 Feb 2019 08:28:30 -0500 Subject: RFR: JDK-8217687: jpackage --help improvements In-Reply-To: References: <64b36526-bac4-463a-efe3-2983a84545f0@oracle.com> Message-ID: <88c31da1-821f-ddb6-87f4-87d90bcf0f3e@oracle.com> On 2/7/2019 5:11 PM, Alexander Matveev wrote: > Hi Andy, > > http://cr.openjdk.java.net/~herrick/8217687/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties.frames.html > > Line 140: I think we do not need " at the end. yes - will remove this before push /Andy > > Otherwise looks fine. > > Thanks, > Alexander > > On 2/7/2019 9:11 AM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> JDK-8217687: jpackage --help improvements >> >> Changes to help text, internal names, and several tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217687 >> >> [2] http://cr.openjdk.java.net/~herrick/8217687/webrev.01/ >> >> >> > From goetz.lindenmaier at sap.com Fri Feb 8 13:39:18 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 8 Feb 2019 13:39:18 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> Message-ID: Hi, ok, so here a new webrev just adding a setter for the field: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 ... and incorporating the other comments. Best regards, Goetz. > -----Original Message----- > From: David Holmes > Sent: Freitag, 8. Februar 2019 13:31 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; Java Core Libs > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > Hi Goetz, > > Just one follow up for now: > > > * Add package visible "void setMessage (String msg)" to Throwable. > > Yes, just use package accessibility to deal with this, no need to jump > through hoops (or the VM :) ). > > Thanks, > David > > On 8/02/2019 9:51 pm, Lindenmaier, Goetz wrote: > > Hi David, > > > >> Hi Volker, > > ... I assume Volker could have contributed this as well, but actually > > I must mention Ralf Schmelter as the original author of this :) > > > >> You know I'm not going to be a big fan of this :), but as long as we > >> don't pay for it if we don't want it, then that's okay. (I'm still > >> trying to gauge that) > >> > >> I have a little test for this that I ran through your patch: > >> > >> public class NPE { > >> static class B { > >> C b() { return null; } > >> } > >> static class C { > >> int c(Object o, String s) { return 0; } > >> } > >> > >> public static void main(String[] args) { > >> int x = a().b().c(d(), e().toString()); > >> } > >> > >> static B a() { return null; } > >> static Object d() { return null; } > >> static Object e() { return null; } > >> > >> } > >> > >> and the result was a bit confusing for me: > >> > >> java.lang.NullPointerException: while trying to invoke the method > >> NPE$B.b(()LNPE$C;) of a null object returned from NPE.a(()LNPE$B;) > >> > >> The placement and format of the return type descriptors obfuscates > >> things to me - especially the Lxxx; format. Can we make that more Java > >> programmer friendly eg: > >> > >> "while trying to invoke the method 'NPE$C NPE$B.b()' ..." > >> > >> though I think trying to produce signatures within the message is going > >> to be very awkward in the general case. The key part is the "method > >> NPE.b() ... returned from NPE.a()" > > Actually, I have left out code that changes the signatures to the > > Java source code wording. I already left that out in my former > > exception message contributions. For example see the messages in > > jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, > > they have the same bad format: > > "class test.Runner4 tried to access private method > test.IllegalAccessErrorTest.iae4_m()V" > > > > I would like to fix them altogether in a follow-up, is that acceptable to > > you? > > > >> Also "of a null object" would read better as "on a null reference". > > Makes sense, fixed. > > > > But I'm not that sure about changing these: > > "while trying to read the field '%s' of a null object" > > --> "while trying to read the field '%s' from a null reference" > > "while trying to write the field %s of a null object" > > --> "while trying to write the field %s of a null reference" > > > >> First you will need to file a CSR request for the new product flags. > > I'm not sure whether I need the product flags altogether. I would > > prefer removing them. > > > >> Second, I don't understand why you need to call into the VM with > >> JVM_SetDefaultMessage, to set a field in the Java object? Why isn't that > >> done in Java? > > Obviously, the problem is that the field is private. > > As Christoph points out, there are several ways to implement this. > > Please give advice: > > * reflection > > * shared secret > > * Add package visible "void setMessage (String msg)" to Throwable. > > > > Best regards, > > Goetz > > > > > >> > >> Thanks, > >> David > >> > >> On 8/02/2019 2:43 am, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> since Java 5, our internal VM reports verbose null pointer exception > >>> messages. I would like to contribute this feature to OpenJDK. > >>> > >>> With this change, messages as > >>> "java.lang.NullPointerException: while trying to load from a null int > array > >> loaded from local variable 'ia1'" > >>> are printed. For more examples see the JBS bug or the test included. > >>> https://bugs.openjdk.java.net/browse/JDK-8218628 > >>> > >>> The messages are generated by parsing the bytecodes. For not to have any > >> overhead when the > >>> NPE is allocated, the message is only generated when it is accessed by > >> getMessage() or > >>> serialization. For this I added a field to NPE to indicate that the message > still > >> needs to be > >>> computed lazily. > >>> > >>> Please review: > >>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/01/ > >>> I'm happy to incorporate your comments. > >>> > >>> Best regards, > >>> Goetz > >>> > >>> From christoph.langer at sap.com Fri Feb 8 13:56:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Feb 2019 13:56:56 +0000 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: <8C6F12DD-9195-4ECC-BF20-B8868A363C86@oracle.com> References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> <8C6F12DD-9195-4ECC-BF20-B8868A363C86@oracle.com> Message-ID: Hi Lance, I found a small nit (hopefully right in time before pushing): + *

URI Scheme Used to Identity the Zip File System

should probably be: + *

URI Scheme Used to Identify the Zip File System

(Identify instead of Identity) Thanks Christoph From christoph.langer at sap.com Fri Feb 8 14:13:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Feb 2019 14:13:16 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> Message-ID: Hi Goetz, > ok, so here a new webrev just adding a setter for the field: > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 > > ... and incorporating the other comments. Looks better ?? I have a few additions to src/java.base/share/classes/java/lang/NullPointerException.java: 28 import java.lang.reflect.Field; 29 -> can be removed now. 91 synchronized (this) { -> I think this is not needed here. The transient modifier for lazyComputeMessage already implies the lock on the Object, I think. 108 return extendedMessage; -> I guess it would be more correct if you returned super.getMessage() here. Thanks Christoph From christoph.langer at sap.com Fri Feb 8 14:26:39 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Feb 2019 14:26:39 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> Message-ID: Hi Goetz, > 91 synchronized (this) { > -> I think this is not needed here. The transient modifier for > lazyComputeMessage already implies the lock on the Object, I think. please ignore this comment, I'm wrong here. I confused transient with volatile... /Christoph From peter.levart at gmail.com Fri Feb 8 15:01:52 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 8 Feb 2019 16:01:52 +0100 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> Message-ID: Hi Goetz, In NPE: 97 String extendedMessage = getExtendedNPEMessage(super.getMessage()); ...do you expect super.getMessage() to return anything else than null? Wouldn't that only occur when there was a data race between two threads observing that lazyComputeMessage is strill true in the synchronized block before that and then one thread proceeding to compute and set the message while the other reading the set message via data race? Or are you planing to replace default message in some cases with computed one? I would just pass null there or even get rid of this parameter if that is not the case. If you do that, there is an alternative to having a boolean field in NPE. You could create a private static final String constant, call it NPE_MESSAGE_PENDING for example and pass it to super constructor in NPE no-arg constructor. Then instead of testing for lazyComputeMessage, you could test for super.getMessage() == NPE_MESSAGE_PENDING... Not that this buys much space as NPEs are not numbered. Just a thought... Regards, Peter 2019-02-08 14:39 GMT+01.00, Lindenmaier, Goetz : > Hi, > > ok, so here a new webrev just adding a setter for the field: > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 > > ... and incorporating the other comments. > > Best regards, > Goetz. > > > > > >> -----Original Message----- >> From: David Holmes >> Sent: Freitag, 8. Februar 2019 13:31 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net; Java Core Libs >> Subject: Re: RFR(L): 8218628: Add detailed message to >> NullPointerException >> describing what is null. >> >> Hi Goetz, >> >> Just one follow up for now: >> >> > * Add package visible "void setMessage (String msg)" to Throwable. >> >> Yes, just use package accessibility to deal with this, no need to jump >> through hoops (or the VM :) ). >> >> Thanks, >> David >> >> On 8/02/2019 9:51 pm, Lindenmaier, Goetz wrote: >> > Hi David, >> > >> >> Hi Volker, >> > ... I assume Volker could have contributed this as well, but actually >> > I must mention Ralf Schmelter as the original author of this :) >> > >> >> You know I'm not going to be a big fan of this :), but as long as we >> >> don't pay for it if we don't want it, then that's okay. (I'm still >> >> trying to gauge that) >> >> >> >> I have a little test for this that I ran through your patch: >> >> >> >> public class NPE { >> >> static class B { >> >> C b() { return null; } >> >> } >> >> static class C { >> >> int c(Object o, String s) { return 0; } >> >> } >> >> >> >> public static void main(String[] args) { >> >> int x = a().b().c(d(), e().toString()); >> >> } >> >> >> >> static B a() { return null; } >> >> static Object d() { return null; } >> >> static Object e() { return null; } >> >> >> >> } >> >> >> >> and the result was a bit confusing for me: >> >> >> >> java.lang.NullPointerException: while trying to invoke the method >> >> NPE$B.b(()LNPE$C;) of a null object returned from NPE.a(()LNPE$B;) >> >> >> >> The placement and format of the return type descriptors obfuscates >> >> things to me - especially the Lxxx; format. Can we make that more Java >> >> programmer friendly eg: >> >> >> >> "while trying to invoke the method 'NPE$C NPE$B.b()' ..." >> >> >> >> though I think trying to produce signatures within the message is >> >> going >> >> to be very awkward in the general case. The key part is the "method >> >> NPE.b() ... returned from NPE.a()" >> > Actually, I have left out code that changes the signatures to the >> > Java source code wording. I already left that out in my former >> > exception message contributions. For example see the messages in >> > jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, >> > they have the same bad format: >> > "class test.Runner4 tried to access private method >> test.IllegalAccessErrorTest.iae4_m()V" >> > >> > I would like to fix them altogether in a follow-up, is that acceptable >> > to >> > you? >> > >> >> Also "of a null object" would read better as "on a null reference". >> > Makes sense, fixed. >> > >> > But I'm not that sure about changing these: >> > "while trying to read the field '%s' of a null object" >> > --> "while trying to read the field '%s' from a null reference" >> > "while trying to write the field %s of a null object" >> > --> "while trying to write the field %s of a null reference" >> > >> >> First you will need to file a CSR request for the new product flags. >> > I'm not sure whether I need the product flags altogether. I would >> > prefer removing them. >> > >> >> Second, I don't understand why you need to call into the VM with >> >> JVM_SetDefaultMessage, to set a field in the Java object? Why isn't >> >> that >> >> done in Java? >> > Obviously, the problem is that the field is private. >> > As Christoph points out, there are several ways to implement this. >> > Please give advice: >> > * reflection >> > * shared secret >> > * Add package visible "void setMessage (String msg)" to Throwable. >> > >> > Best regards, >> > Goetz >> > >> > >> >> >> >> Thanks, >> >> David >> >> >> >> On 8/02/2019 2:43 am, Lindenmaier, Goetz wrote: >> >>> Hi, >> >>> >> >>> since Java 5, our internal VM reports verbose null pointer exception >> >>> messages. I would like to contribute this feature to OpenJDK. >> >>> >> >>> With this change, messages as >> >>> "java.lang.NullPointerException: while trying to load from a null >> >>> int >> array >> >> loaded from local variable 'ia1'" >> >>> are printed. For more examples see the JBS bug or the test included. >> >>> https://bugs.openjdk.java.net/browse/JDK-8218628 >> >>> >> >>> The messages are generated by parsing the bytecodes. For not to have >> >>> any >> >> overhead when the >> >>> NPE is allocated, the message is only generated when it is accessed >> >>> by >> >> getMessage() or >> >>> serialization. For this I added a field to NPE to indicate that the >> >>> message >> still >> >> needs to be >> >>> computed lazily. >> >>> >> >>> Please review: >> >>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/01/ >> >>> I'm happy to incorporate your comments. >> >>> >> >>> Best regards, >> >>> Goetz >> >>> >> >>> > From peter.levart at gmail.com Fri Feb 8 15:08:04 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 8 Feb 2019 16:08:04 +0100 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> Message-ID: ...just one thing if you go that route. Make sure to initialize the NPE_MESSAGE_PENDING to a new String("something") or else you may be sharing this constant reference with somebody else via string interning... 2019-02-08 16:01 GMT+01.00, Peter Levart : > Hi Goetz, > > In NPE: > > 97 String extendedMessage = > getExtendedNPEMessage(super.getMessage()); > > ...do you expect super.getMessage() to return anything else than null? > Wouldn't that only occur when there was a data race between two > threads observing that lazyComputeMessage is strill true in the > synchronized block before that and then one thread proceeding to > compute and set the message while the other reading the set message > via data race? Or are you planing to replace default message in some > cases with computed one? > > I would just pass null there or even get rid of this parameter if that > is not the case. > > If you do that, there is an alternative to having a boolean field in > NPE. You could create a private static final String constant, call it > NPE_MESSAGE_PENDING for example and pass it to super constructor in > NPE no-arg constructor. Then instead of testing for > lazyComputeMessage, you could test for super.getMessage() == > NPE_MESSAGE_PENDING... > > Not that this buys much space as NPEs are not numbered. Just a thought... > > > Regards, Peter > > 2019-02-08 14:39 GMT+01.00, Lindenmaier, Goetz : >> Hi, >> >> ok, so here a new webrev just adding a setter for the field: >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 >> >> ... and incorporating the other comments. >> >> Best regards, >> Goetz. >> >> >> >> >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Freitag, 8. Februar 2019 13:31 >>> To: Lindenmaier, Goetz ; hotspot-runtime- >>> dev at openjdk.java.net; Java Core Libs >>> Subject: Re: RFR(L): 8218628: Add detailed message to >>> NullPointerException >>> describing what is null. >>> >>> Hi Goetz, >>> >>> Just one follow up for now: >>> >>> > * Add package visible "void setMessage (String msg)" to Throwable. >>> >>> Yes, just use package accessibility to deal with this, no need to jump >>> through hoops (or the VM :) ). >>> >>> Thanks, >>> David >>> >>> On 8/02/2019 9:51 pm, Lindenmaier, Goetz wrote: >>> > Hi David, >>> > >>> >> Hi Volker, >>> > ... I assume Volker could have contributed this as well, but actually >>> > I must mention Ralf Schmelter as the original author of this :) >>> > >>> >> You know I'm not going to be a big fan of this :), but as long as we >>> >> don't pay for it if we don't want it, then that's okay. (I'm still >>> >> trying to gauge that) >>> >> >>> >> I have a little test for this that I ran through your patch: >>> >> >>> >> public class NPE { >>> >> static class B { >>> >> C b() { return null; } >>> >> } >>> >> static class C { >>> >> int c(Object o, String s) { return 0; } >>> >> } >>> >> >>> >> public static void main(String[] args) { >>> >> int x = a().b().c(d(), e().toString()); >>> >> } >>> >> >>> >> static B a() { return null; } >>> >> static Object d() { return null; } >>> >> static Object e() { return null; } >>> >> >>> >> } >>> >> >>> >> and the result was a bit confusing for me: >>> >> >>> >> java.lang.NullPointerException: while trying to invoke the method >>> >> NPE$B.b(()LNPE$C;) of a null object returned from NPE.a(()LNPE$B;) >>> >> >>> >> The placement and format of the return type descriptors obfuscates >>> >> things to me - especially the Lxxx; format. Can we make that more >>> >> Java >>> >> programmer friendly eg: >>> >> >>> >> "while trying to invoke the method 'NPE$C NPE$B.b()' ..." >>> >> >>> >> though I think trying to produce signatures within the message is >>> >> going >>> >> to be very awkward in the general case. The key part is the "method >>> >> NPE.b() ... returned from NPE.a()" >>> > Actually, I have left out code that changes the signatures to the >>> > Java source code wording. I already left that out in my former >>> > exception message contributions. For example see the messages in >>> > jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, >>> > they have the same bad format: >>> > "class test.Runner4 tried to access private method >>> test.IllegalAccessErrorTest.iae4_m()V" >>> > >>> > I would like to fix them altogether in a follow-up, is that acceptable >>> > to >>> > you? >>> > >>> >> Also "of a null object" would read better as "on a null reference". >>> > Makes sense, fixed. >>> > >>> > But I'm not that sure about changing these: >>> > "while trying to read the field '%s' of a null object" >>> > --> "while trying to read the field '%s' from a null reference" >>> > "while trying to write the field %s of a null object" >>> > --> "while trying to write the field %s of a null reference" >>> > >>> >> First you will need to file a CSR request for the new product flags. >>> > I'm not sure whether I need the product flags altogether. I would >>> > prefer removing them. >>> > >>> >> Second, I don't understand why you need to call into the VM with >>> >> JVM_SetDefaultMessage, to set a field in the Java object? Why isn't >>> >> that >>> >> done in Java? >>> > Obviously, the problem is that the field is private. >>> > As Christoph points out, there are several ways to implement this. >>> > Please give advice: >>> > * reflection >>> > * shared secret >>> > * Add package visible "void setMessage (String msg)" to Throwable. >>> > >>> > Best regards, >>> > Goetz >>> > >>> > >>> >> >>> >> Thanks, >>> >> David >>> >> >>> >> On 8/02/2019 2:43 am, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> >>> >>> since Java 5, our internal VM reports verbose null pointer exception >>> >>> messages. I would like to contribute this feature to OpenJDK. >>> >>> >>> >>> With this change, messages as >>> >>> "java.lang.NullPointerException: while trying to load from a >>> >>> null >>> >>> int >>> array >>> >> loaded from local variable 'ia1'" >>> >>> are printed. For more examples see the JBS bug or the test >>> >>> included. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8218628 >>> >>> >>> >>> The messages are generated by parsing the bytecodes. For not to have >>> >>> any >>> >> overhead when the >>> >>> NPE is allocated, the message is only generated when it is accessed >>> >>> by >>> >> getMessage() or >>> >>> serialization. For this I added a field to NPE to indicate that the >>> >>> message >>> still >>> >> needs to be >>> >>> computed lazily. >>> >>> >>> >>> Please review: >>> >>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/01/ >>> >>> I'm happy to incorporate your comments. >>> >>> >>> >>> Best regards, >>> >>> Goetz >>> >>> >>> >>> >> > From jon.harper87 at gmail.com Thu Feb 7 19:25:29 2019 From: jon.harper87 at gmail.com (Jon Harper) Date: Thu, 7 Feb 2019 20:25:29 +0100 Subject: jpackage windows --version-swap --icon-swap weirdness Message-ID: Hi list, I'm using jpackage EA from https://jdk.java.net/jpackage/ to create a windows executable on windows 2012 R2 (jpackager create-image ...) The resulting exe file doesn't have the correct vendor and version information (it has openjdk 13 instead of my vendor name and version). It has the correct logo. Can anyone help with this, or is anyone interested ? Has anyone made the icon and vendor work with exes ? I did some troubleshooting, including writing my own program that updates the version using BeginUpdateResource, UpdateResource and EndUpdateResource, I see very differing behaviors depending on what exe I change. With an exe that I compiled myself using mingw32 (gcc 5.1), calling jpackager --icon-swap and jpackager --version-swap on it works. Using a copy of git.exe from git for windows portable, everytime I call jpackage --version-swap (or my own program) on this exe AFTER having done a jpackage --icon-swap on it, I get a crash and the exe is not updated (updating the version with my simple program has the same behavior). Calling jpackage --version-swap first and then jpackage --icon-swap results in an exe that has the correct icon and correct versioninfo (although this exe is now "poisonned", you can't change its version again..) Running jpackage --version-info again on the binary generated by jpackage doesn't do anything but doesn't crash. The behavior is the same whether I use my own icon (a 48x48 icon created with the gimp) or if replace my icon file with javalogo_white_48.ico I can run more tests if necessary. Any help is appreciated, Cheers, Jon From tornaiandrasede at gmail.com Fri Feb 8 10:58:40 2019 From: tornaiandrasede at gmail.com (=?UTF-8?Q?Tornai_Andr=C3=A1s?=) Date: Fri, 8 Feb 2019 11:58:40 +0100 Subject: RFR 8205991: Cannot start application (WinLauncher) if path contains non-ascii character Message-ID: Hi all, The issue was reported some time ago and it was closed (wont-fix) since javapackager was removed from JDK11. Hopefully jpackage will come back with JDK13 so I retested it with the latest jpackage* and it seems that the issue is still there. Are there any plans to fix this? Regards, Andr?s * https://jdk.java.net/jpackage/ jdk13/Build 8 (2019/1/8) From Roger.Riggs at oracle.com Fri Feb 8 15:51:42 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 8 Feb 2019 10:51:42 -0500 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> Message-ID: Hi Goetz, On 02/08/2019 06:51 AM, Lindenmaier, Goetz wrote: > ... >> though I think trying to produce signatures within the message is going >> to be very awkward in the general case. The key part is the "method >> NPE.b() ... returned from NPE.a()" > Actually, I have left out code that changes the signatures to the > Java source code wording. I already left that out in my former > exception message contributions. For example see the messages in > jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, > they have the same bad format: > "class test.Runner4 tried to access private method test.IllegalAccessErrorTest.iae4_m()V" > > I would like to fix them altogether in a follow-up, is that acceptable to > you? > > Please no partial solutions, it all needs to be complete. I'll take a look at it today. Thanks, Roger From andy.herrick at oracle.com Fri Feb 8 16:02:18 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 8 Feb 2019 11:02:18 -0500 Subject: RFR 8205991: Cannot start application (WinLauncher) if path contains non-ascii character In-Reply-To: References: Message-ID: I reopened this issue to fix in new jpackage. /Andy On 2/8/2019 5:58 AM, Tornai Andr?s wrote: > Hi all, > > The issue was reported some time ago and it was closed (wont-fix) since > javapackager was removed from JDK11. > Hopefully jpackage will come back with JDK13 so I retested it with the > latest jpackage* and it seems that the issue is still there. Are there any > plans to fix this? > > Regards, > Andr?s > > * https://jdk.java.net/jpackage/ jdk13/Build 8 (2019/1/8) From andy.herrick at oracle.com Fri Feb 8 16:35:27 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 8 Feb 2019 11:35:27 -0500 Subject: jpackage windows --version-swap --icon-swap weirdness In-Reply-To: References: Message-ID: We have recently moved this functionality from jpackage.exe command line to a native library, (JDK-8217317). That being said, it sounds like there was a bug in the implementation, and that bug was moved with the code. I have filed bug JDK-8218681 to track this. /Andy On 2/7/2019 2:25 PM, Jon Harper wrote: > Hi list, > I'm using jpackage EA from https://jdk.java.net/jpackage/ to create a > windows executable on windows 2012 R2 (jpackager create-image ...) > The resulting exe file doesn't have the correct vendor and version > information (it has openjdk 13 instead of my vendor name and version). > It has the correct logo. > > Can anyone help with this, or is anyone interested ? Has anyone made > the icon and vendor work with exes ? > > I did some troubleshooting, including writing my own program that > updates the version using BeginUpdateResource, UpdateResource and > EndUpdateResource, I see very differing behaviors depending on what > exe I change. > > With an exe that I compiled myself using mingw32 (gcc 5.1), calling > jpackager --icon-swap and jpackager --version-swap on it works. > > Using a copy of git.exe from git for windows portable, everytime I > call jpackage --version-swap (or my own program) on this exe AFTER > having done a jpackage --icon-swap on it, I get a crash and the exe is > not updated (updating the version with my simple program has the same > behavior). Calling jpackage --version-swap first and then jpackage > --icon-swap results in an exe that has the correct icon and correct > versioninfo (although this exe is now "poisonned", you can't change > its version again..) > > Running jpackage --version-info again on the binary generated by > jpackage doesn't do anything but doesn't crash. > > The behavior is the same whether I use my own icon (a 48x48 icon > created with the gimp) or if replace my icon file with > javalogo_white_48.ico > > I can run more tests if necessary. > Any help is appreciated, > > Cheers, > Jon From lance.andersen at oracle.com Fri Feb 8 17:27:00 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 8 Feb 2019 12:27:00 -0500 Subject: RFR 8182117 : Document Zip File System Properties In-Reply-To: References: <188E1488-B7E8-40F2-AD0C-3BD760936E2F@oracle.com> <78c728ba-1d3f-a99c-96bd-9e54cf3da133@oracle.com> <13819F92-836B-4F12-B29B-FD082B2561CA@oracle.com> <8C6F12DD-9195-4ECC-BF20-B8868A363C86@oracle.com> Message-ID: Thank you for catching that Christoph, sometimes you see what you want to see :-) I will tweak that prior to the push once the CSR is approved Thank you and have a good weekend > On Feb 8, 2019, at 8:56 AM, Langer, Christoph wrote: > > Hi Lance, > > I found a small nit (hopefully right in time before pushing): > > + *

URI Scheme Used to Identity the Zip File System

> > should probably be: > > + *

URI Scheme Used to Identify the Zip File System

> > (Identify instead of Identity) > > 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 Roger.Riggs at oracle.com Fri Feb 8 19:46:05 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 8 Feb 2019 14:46:05 -0500 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> Message-ID: <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> Hi, A few higher level issues should be considered, though the details of the webrev captured my immediate attention. Is this the right feature and is this the right level of implementation (C++/native)? From a security perspective, adding field names to exceptions exposes information to callers that they could not otherwise get and that breaks encapsulation. That needs to be evaluated. I think there are ways to make this easier to implement and be easier to maintain and perform better. NullPointerException: 28: unused import of Field 64: The lazyComputeMessage boolean should be inverted so it does not require ?? initialization, false is the default, anything else adds overhead. ?? And it may not be needed. 91: Why do you think synchonization is necessary?? It is a performance hit. ?? It is highly unlikely to be called from multiple threads and the value will ?? be the same whether it is computed once or multiple times by different threads. 99: extendedMessage will never be null (so says the javadoc of getExtendedNPEMessage) ? Bug: If it does return null, then null is returned from getMessage ? regardless of the value of super.getMessage(). 121: Simplify getExtendedNPEMessage by making it only responsible for the detail ? and not concatenation with an existing message.? Put that in getMessage(). ? Its not strictly necessary to change the updated message with setMessage(). ? Avoiding that will avoid complexity and a performance hit. ? The message will be computed each time it is needed, and that happens infrequently. ? (Even in the serialization case, it will be re-computed from the attached stack frames). ? And it avoids adding setMessage() to Throwable, that's significant change since ? the current implementation only allows the message to be initialized not updated. ? Immutable is an important characteristic to maintain. ? That makes the writeReplace() unnecessary too. Additional command line arguments are an unnecessary complexity, documentation, and maintenance overhead.? If the feature is as valuable as you suggest, it should be enabled all the time. I'm assuming there are no tests broken by the modification of the message. It is likely that somewhere an application or test looks at the message itself. Has that been verified? I can't speak for the hotspot code, but that seems to add a lot of code to support only this convenience feature.? That's a maintenance overhead and burden. The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a question about how useful the information is,? developers should not need to know about "slot 1". The test output of NullPointerExceptionTest shows "java.lang.Object.hashCode(()I)". Why is the argument type for Integer shown as "()I";? that's not the conventional representation of a primitive int. Generally, the explanations are too verbose. Method names and field names would be easier to recognize if they were quoted, as is done with 'this'.? Argument numbers should be digits, not English words (first, second, etc) to make them easier to pick out. And has it limits that do not read easily, e.g. "nr. 9". I would not describe 'this' as a local variable. Tests, especially new tests should compile without warnings. NullPointerExceptionTest.java:125 newInstance has been deprecated. The messages can be easier to understand, e.g. 'field a1 is null, trying to invoke a1.hashCode...' instead of: "while trying to invoke the method java.lang.Object.hashCode(()I) on a null reference loaded from local variable 'a1'" It will easier to understand if it looks more like the code. BTW, what does this look like for fully optimized code? Does it bear any resemblance to the source code at all? Or does it have to be deoptimized to come up with a sensible source reference. How much of this can be done in Java code with StackWalker and other java APIs? It would be a shame to add this much native code if there was a more robust way to implement it using APIs with more leverage. Regards, Roger On 02/08/2019 09:13 AM, Langer, Christoph wrote: > Hi Goetz, > >> ok, so here a new webrev just adding a setter for the field: >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 >> >> ... and incorporating the other comments. > Looks better ?? > > I have a few additions to src/java.base/share/classes/java/lang/NullPointerException.java: > > 28 import java.lang.reflect.Field; > 29 > -> can be removed now. > > 91 synchronized (this) { > -> I think this is not needed here. The transient modifier for lazyComputeMessage already implies the lock on the Object, I think. > > 108 return extendedMessage; > -> I guess it would be more correct if you returned super.getMessage() here. > > Thanks > Christoph From ivan.gerasimov at oracle.com Fri Feb 8 20:52:21 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 8 Feb 2019 12:52:21 -0800 Subject: RFR 8216407 : java.util.UUID.fromString accepts input that does not match expected format In-Reply-To: References: <2e3d1145-d8c7-c55d-a629-0e23ddc5b205@oracle.com> <9824a63d-dfd0-cb89-b67c-190df8c047ff@oracle.com> <06dd30e3-be81-d097-2c6e-6c28aacc0431@oracle.com> Message-ID: Gentle ping. So, do you think it is an appropriate fix? To emphasize: It is proposed to start rejecting only obviously incorrect UUIDs, which may help the applications, as they would fail earlier on invalid input. With kind regards, Ivan On 1/10/19 8:50 AM, Ivan Gerasimov wrote: > Hi Roger! > > > On 1/10/19 8:04 AM, Roger Riggs wrote: >> Hi, >> >> If we're going to break some apps that use non-conforming strings, >> perhaps we should go fully strict and make sure they are all fixed at >> the same time. >> (Unless we have some stats on the distribution of non-conforming apps >> that mitigates that). >> > That's my point: While going fully strict may break some applications > out there, rejecting only obviously incorrect input will likely affect > only those applications with a bug. > > It can be thought as a first step toward full conformance to the RFC. > For now, reject only the most incorrect inputs, and leave the final > step, if desired, to JDK-8165199 > . > > With kind regards, > Ivan > >> Roger >> >> >> On 01/10/2019 02:27 AM, Ivan Gerasimov wrote: >>> Hi Joe! >>> >>> From what I see, the discussion was about possibility to only accept >>> input strings with precisely sized parts, i.e. that matches >>> "\p{XDigit}{8}- \p{XDigit}{4}- \p{XDigit}{4}- \p{XDigit}{4}- >>> \p{XDigit}{12}". >>> >>> And I'm proposing to only reject input with too large individual >>> parts, i.e. accept any input that matches >>> " \p{XDigit}{1,8}- \p{XDigit}{1,4}- \p{XDigit}{1,4}- >>> \p{XDigit}{1,4}- \p{XDigit}{1,12}". >>> >>> Currently, if one part is too large, we already "clip" it, using >>> only lower bits, so behavior looks buggy. >>> >>> Instead, it seems better to report the issue throwing an exception. >>> >>> With kind regards, >>> Ivan >>> >>> On 1/9/19 11:08 PM, Joe Darcy wrote: >>>> Hi Ivan, >>>> >>>> How does this bug relate to the recent discussion of "JDK-8165199: >>>> UUID.fromString(str) compliance checking?": >>>> >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html >>>> >>>> >>>> Cheers, >>>> >>>> -Joe >>>> >>>> On 1/9/2019 3:23 PM, Ivan Gerasimov wrote: >>>>> Hello! >>>>> >>>>> String representation of UUID should conform to RFC4122 >>>>> , i.e. each its part has to >>>>> be of the fixed size. >>>>> >>>>> Unfortunately, the UUID.fromString() method does not keep up to >>>>> this requirement: >>>>> - First, it permits the leading zeroes of any part to be omitted; >>>>> - Second, it permits some of the UUID parts to be larger then >>>>> allowed. In such a case, the value is effectively clipped with & >>>>> 0x..FFFF. >>>>> While some existing application may depend on the former case -- >>>>> i.e. be able to parse UUID with stripped leading zeroes, the later >>>>> case is likely to be an error. >>>>> >>>>> In the past, the check on the input has already been strengthened >>>>> with JDK-8006627 . >>>>> >>>>> I propose we go further and make UUID.fromString() to reject such >>>>> string representations that contain too large individual parts. >>>>> >>>>> If people agree on the proposal, I'll file CSR to fix the change >>>>> of behavior. >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216407 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8216407/00/webrev/ >>>>> >>>>> Thanks in advance! >>>>> >>>> >>> >> >> > -- With kind regards, Ivan Gerasimov From Roger.Riggs at oracle.com Fri Feb 8 21:00:07 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 8 Feb 2019 16:00:07 -0500 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: <86c2f03f-b1b6-c82f-6244-81c0e0137244@oracle.com> Hi Thomas, The new OutputAnalyzer methods are new: 496: now that we have Immutable Lists, can the filterByKeyword argument be a List? List interesting = List.of( "fork", "clone", "vfork", "exec", "/bin/true", "jspawnhelper" ); 497: Instead of passing an int, pass the String itself 480, 485: that is returned from getStdout() or getStderr(). The body of the method could probably be nicely written using the Stream API. (except for the line numbers).? I'm not sure the line numbers are useful in this case based since the strace output is not shown anywhere or seen in the full. ?? .lines().filter()... Add the javadoc to the methods so its clear how to use them since this is a public test framework. Regards, Roger On 02/08/2019 04:38 AM, Thomas St?fe wrote: > Hi Roger, Martin, > > next version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.02/webrev > > > - did massage the comment in ProcessImpl.c > - made the test more resilient by scanning for the strace tool and by > silently ignoring all problems stemming from strace or the payload > binary not being there. The test now only fails if the forks were > successully executed but it does not seem to use posix-spawn. > - added output to the test by printing the "interesting" lines of the > strace output. Note that this filtering is not really sophisticated > and will show all thread related clone() calls as well: > > 614 ? [pid 12447] <... clone resumed> child_stack=0x7fe00c4baff0, > flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, > parent_tidptr=0x7fe00c4bb9d0, tls=0x7fe00c4bb700, > child_tidptr=0x7fe00c4bb9d0) = 12452 > 646 ? [pid 12447] clone(/usr/bin/strace: Process 12453 attached > 649 ? [pid 12447] <... clone resumed> child_stack=0x7fe00c3b9ff0, > flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, > parent_tidptr=0x7fe00c3ba9d0, tls=0x7fe00c3ba700, > child_tidptr=0x7fe00c3ba9d0) = 12453 > .... > > I am sure this could be made more intelligent but lets keep it simple > for now. > > - I removed the helperPath() methods Roger mentioned, they are not > needed anymore. > > @Martin: I like the -e signal=none -e trace=process idea but I'm not > sure if all versions of strace support these options. I think the > strace output is small enough for this small use case, some kB only. > > Cheers, Thomas > > > > > > On Thu, Feb 7, 2019 at 6:01 PM Thomas St?fe > wrote: > > Hi all, > > second version, including the updated comment in ProcessImpl.c > Martin requested: > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html > > > @Roger: thanks for feeding this into your tests. I still try to > get it to run thru jdk-submit, but that seems to be stuck again.. > > Cheers, Thomas > > > > > > On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe > > wrote: > > Hi all > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html > > > (@Roger: I hope you do not mind? The bug is assigned to you > but since I happened to play around with posix_spawn I > prepared this webrev. If you rather do this change, that is > fine and I will leave it to you.) > > When we added the possibility to use posix_spawn as underlying > implementation for Runtime.exec() on Linux with > https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to > keep VFORK as default until work on 13 starts. So now would be > a good time to switch the default to posix_spawn to get a good > testing window. Note that at SAP we run our VMs internally > with posix_spawn as default since some months and have not > seen problems. > > As for the fix, I added a test which tests that the default is > indeed posix_spawn - not sure whether this is overdoing it > though. Also, I use strace for the test, and /bin/true, and > while strace is usually available and reachable by path > resolution, I am afraid on some test machines it may not. What > do you think, should I leave the test out? > > The fix ran through all java/lang/ProcessBuilder jtreg tests ok. > > Thanks, Thomas > From martinrb at google.com Fri Feb 8 21:48:47 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 8 Feb 2019 13:48:47 -0800 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> <206a816f-85c6-5c07-8fce-d6a0497a75b5@redhat.com> Message-ID: and ... finally committed (sorry as always for the sloth pace) On Wed, Feb 6, 2019 at 10:28 AM Martin Buchholz wrote: > Finally got around to doing some work on this. > I'm happy with this latest revision: > > > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/HashMap-resize/index.html > > I did some more work on the microbenchmark, in part to force myself to > learn about jmh. > It now tests LinkedHashMap as well. > I replaced use of Random with ThreadLocalRandom > > @Param("1000000") > private int size; > > @Param > private MapType mapType; > > public enum MapType { > HASH_MAP, > LINKED_HASH_MAP, > } > > > > On Thu, Jan 3, 2019 at 12:31 PM Michal Vala wrote: > >> Hi Martin, >> >> can we please finish this review? >> >> On 12/19/18 6:32 PM, Michal Vala wrote: >> > >> > >> > On 12/19/18 4:15 PM, Martin Buchholz wrote: >> >> On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs >> wrote: >> >> >> >>> Hi Martin, >> >>> >> >>> It is also useful and conventional to print the seed of the random >> >>> so that if necessary it can be reproduced. >> >>> >> >> >> >> For many years, we've been using ThreadLocalRandom for testing, and >> that >> >> does not allow setting a seed. >> >> >> >> I remain unconvinced that saving a seed has value in the real world. >> When >> >> a randomized test fails, running it with sufficient iterations has >> always >> >> worked for me. >> >> >> > >> > What's the reason behind using ThreadLocalRandom? >> > >> > In my opinion, reproducing the issue is key. One failure of randomized >> test run >> > might be caused by one issue, second run due to another issue. How we >> reproduce >> > then and how we know even how many issues we have? When we're running >> random >> > tests until it pass, it might even hide the issue. >> > >> > They sure have good value on reveal the issue, but then we have to know >> how to >> > reproduce and what we're searching for. >> > >> > If this case would not require ThreadLocalRandom and Random is enough, >> I'd like >> > to use that because of benefits I've mentioned. >> > >> >> -- >> Michal Vala >> OpenJDK QE >> Red Hat Czech >> > From Roger.Riggs at oracle.com Fri Feb 8 21:49:53 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 8 Feb 2019 16:49:53 -0500 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> Message-ID: <07bbc6e7-0656-0efa-0f24-987aeb43e9cc@oracle.com> Hi Ivan, In the direction of not changing the behavior; the webrev does change the behavior. In the case of CharSeqence with length -1..-16, the new behavior throws NegativeArrayIndexException instead of java.lang.IndexOutOfBoundsException. AbstractStringBuilder:101-102 throw an exception for length < 0. However, the current behavior is to create a StringBuffer with length + 16 and then append the contents.? For -1..-16, it will succeed in creating a StringBuffer but fail with IndexOutOfBoundsException during the append of the contents. The new Test should pass both before and after the change to the code. Roger On 02/07/2019 10:19 PM, Ivan Gerasimov wrote: > > > On 2/7/19 6:33 PM, David Holmes wrote: >> On 8/02/2019 11:59 am, Ivan Gerasimov wrote: >>> Hi David! >>> >>> >>> On 2/7/19 5:16 PM, David Holmes wrote: >>>> Hi Ivan, >>>> >>>> On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >>>>> Hello! >>>>> >>>>> The specification states: >>>>> """ >>>>> If the length of the specified CharSequence is less than or equal >>>>> to zero, then an empty buffer of capacity 16 is returned. >>>>> """ >>>>> >>>>> However, the current implementation throws either >>>>> NegativeArraySizeException or IndexOutOfBounds instead (the actual >>>>> exception type depends on the value of reported negative length). >>>> >>>> How can you have a negative length CharSequence ?? >>>> >>> A custom CharSequence returning negative length() can be created. >>> Not sure how useful/popular this may be, though. >> >> Seems pretty meaningless so just treating that as an error seems >> fine. Though somewhat debatable whether you need to add an >> appropriate @throws. >> > Right.? There were two reasons not to add @throws here: > - by removing the problematic paragraph we just make the javadoc > almost the same as for StringBuilder(CharSequence), > - we don't seem to have any other places (at least I couldn't find > any) specifying exceptions due to negatively sized CharSequence. > > (To be precise, there is one candidate, but I'll file a separate bug > to fix it.) > >>> That's why I propose just removing the mentioning negative length, >>> and not changing the behavior. >>> >>> The proposed code change is to only unify the behavior for any >>> negative value of length. >> >> Ok. >> >>>> If its an empty CharSequence then it should return the empty buffer >>>> as indicated. >>>> >>> Empty CharSequence is processed correctly already. >> >> Okay so by removing this part: >> >> -????? *

>> -????? * If the length of the specified {@code CharSequence} is >> -????? * less than or equal to zero, then an empty buffer of capacity >> -????? * {@code 16} is returned. >> >> you're relying on the main specification to implicitly handle the >> empty case. >> > Yes. > > With kind regards, > Ivan > > >> David >> ----- >> >>> With kind regards, >>> Ivan >>> >>>> Cheers, >>>> David >>>> >>>>> It is proposed to do two things: >>>>> 1) remove the problematic sentence from the javadoc (CSR is filed). >>>>> 2) unify the exception type thrown, if the argument reports >>>>> negative length. >>>>> NegativeArraySizeException will be consistent with, for example, >>>>> StringBuffer(negativeCapacity). >>>>> >>>>> Would you please help review the fix? >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >>>>> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >>>>> >>>> >>> >> > From ivan.gerasimov at oracle.com Fri Feb 8 22:12:11 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 8 Feb 2019 14:12:11 -0800 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: <07bbc6e7-0656-0efa-0f24-987aeb43e9cc@oracle.com> References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> <07bbc6e7-0656-0efa-0f24-987aeb43e9cc@oracle.com> Message-ID: <445d726b-5a45-b43f-3aea-452fbfc10124@oracle.com> Hi Roger! That's because two tiny changes are combined in the patch: 1) remove a problematic statement from the javadoc, as it doesn't hold anyway. This part does not change the behavior. 2) unify type of the exception thrown for all negative values of CharSequence.length(). The regression test is to verify this, second change, so it fails prior the fix for length \in [-16, -1]. I can separate them into different bugs, if you think it will make it clearer. Though I thought they can be fixed together. With kind regards, Ivan On 2/8/19 1:49 PM, Roger Riggs wrote: > Hi Ivan, > > In the direction of not changing the behavior; the webrev does change > the behavior. > > In the case of CharSeqence with length -1..-16, the new behavior > throws NegativeArrayIndexException > instead of java.lang.IndexOutOfBoundsException. > > > AbstractStringBuilder:101-102 throw an exception for length < 0. > However, the current behavior is to create a StringBuffer with length > + 16 and > then append the contents. For -1..-16, it will succeed in creating a > StringBuffer > but fail with IndexOutOfBoundsException during the append of the > contents. > > The new Test should pass both before and after the change to the code. > > Roger > > > On 02/07/2019 10:19 PM, Ivan Gerasimov wrote: >> >> >> On 2/7/19 6:33 PM, David Holmes wrote: >>> On 8/02/2019 11:59 am, Ivan Gerasimov wrote: >>>> Hi David! >>>> >>>> >>>> On 2/7/19 5:16 PM, David Holmes wrote: >>>>> Hi Ivan, >>>>> >>>>> On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >>>>>> Hello! >>>>>> >>>>>> The specification states: >>>>>> """ >>>>>> If the length of the specified CharSequence is less than or equal >>>>>> to zero, then an empty buffer of capacity 16 is returned. >>>>>> """ >>>>>> >>>>>> However, the current implementation throws either >>>>>> NegativeArraySizeException or IndexOutOfBounds instead (the >>>>>> actual exception type depends on the value of reported negative >>>>>> length). >>>>> >>>>> How can you have a negative length CharSequence ?? >>>>> >>>> A custom CharSequence returning negative length() can be created. >>>> Not sure how useful/popular this may be, though. >>> >>> Seems pretty meaningless so just treating that as an error seems >>> fine. Though somewhat debatable whether you need to add an >>> appropriate @throws. >>> >> Right. There were two reasons not to add @throws here: >> - by removing the problematic paragraph we just make the javadoc >> almost the same as for StringBuilder(CharSequence), >> - we don't seem to have any other places (at least I couldn't find >> any) specifying exceptions due to negatively sized CharSequence. >> >> (To be precise, there is one candidate, but I'll file a separate bug >> to fix it.) >> >>>> That's why I propose just removing the mentioning negative length, >>>> and not changing the behavior. >>>> >>>> The proposed code change is to only unify the behavior for any >>>> negative value of length. >>> >>> Ok. >>> >>>>> If its an empty CharSequence then it should return the empty >>>>> buffer as indicated. >>>>> >>>> Empty CharSequence is processed correctly already. >>> >>> Okay so by removing this part: >>> >>> - *

>>> - * If the length of the specified {@code CharSequence} is >>> - * less than or equal to zero, then an empty buffer of capacity >>> - * {@code 16} is returned. >>> >>> you're relying on the main specification to implicitly handle the >>> empty case. >>> >> Yes. >> >> With kind regards, >> Ivan >> >> >>> David >>> ----- >>> >>>> With kind regards, >>>> Ivan >>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> It is proposed to do two things: >>>>>> 1) remove the problematic sentence from the javadoc (CSR is filed). >>>>>> 2) unify the exception type thrown, if the argument reports >>>>>> negative length. >>>>>> NegativeArraySizeException will be consistent with, for example, >>>>>> StringBuffer(negativeCapacity). >>>>>> >>>>>> Would you please help review the fix? >>>>>> >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >>>>>> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >>>>>> >>>>> >>>> >>> >> > > -- With kind regards, Ivan Gerasimov From martinrb at google.com Fri Feb 8 23:42:43 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 8 Feb 2019 15:42:43 -0800 Subject: RFR: jsr166 integration 2019-02 Message-ID: https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8195057: java/util/concurrent/CountDownLatch/Basic.java failed w/ Xcomp https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CountDownLatch-Basic/index.html https://bugs.openjdk.java.net/browse/JDK-8195057 8215359: InnocuousForkJoinWorkerThread.setContextClassLoader needlessly throws https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/InnocuousForkJoinWorkerThread/index.html https://bugs.openjdk.java.net/browse/JDK-8215359 8215363: needless signals in ForkJoinPool https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/forkjoin-signals/index.html https://bugs.openjdk.java.net/browse/JDK-8215363 Still in limbo: 8203662: remove increment of modCount from ArrayList and Vector replaceAll() https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html https://bugs.openjdk.java.net/browse/JDK-8203662 8215249: Miscellaneous changes imported from jsr166 CVS 2019-02 https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html https://bugs.openjdk.java.net/browse/JDK-8215249 From chris.hegarty at oracle.com Sat Feb 9 14:33:38 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 9 Feb 2019 14:33:38 +0000 Subject: RFR: jsr166 integration 2019-02 In-Reply-To: References: Message-ID: <60392B95-5C77-4FC7-8F44-C618A2122A39@oracle.com> > On 8 Feb 2019, at 23:42, Martin Buchholz wrote: > > ... > 8195057: java/util/concurrent/CountDownLatch/Basic.java failed w/ Xcomp > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CountDownLatch-Basic/index.html Looks fine. I initially thought that a @build tag would be needed, but I ran the test and jtreg builds the required library dependencies implicitly. > 8215359: InnocuousForkJoinWorkerThread.setContextClassLoader needlessly > throws > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/InnocuousForkJoinWorkerThread/index.html Looks good. A positive test for setContextClassLoader(null) could be added. -Chris. From thomas.stuefe at gmail.com Sat Feb 9 15:24:44 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 9 Feb 2019 16:24:44 +0100 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: <86c2f03f-b1b6-c82f-6244-81c0e0137244@oracle.com> References: <86c2f03f-b1b6-c82f-6244-81c0e0137244@oracle.com> Message-ID: Hi Roger, I start getting doubts about the whole test, honestly. Do you think it is worth the maintenance effort to test that we indeed call posix_spawn as we intended to? I wonder whether I should just scratch it. ..Thomas On Fri, Feb 8, 2019 at 10:00 PM Roger Riggs wrote: > Hi Thomas, > > The new OutputAnalyzer methods are new: > > 496: now that we have Immutable Lists, can the filterByKeyword argument be > a List? > > List interesting = List.of( "fork", "clone", "vfork", "exec", > "/bin/true", "jspawnhelper" ); > > 497: Instead of passing an int, pass the String itself > 480, 485: that is returned from getStdout() or getStderr(). > > The body of the method could probably be nicely written using the Stream > API. > (except for the line numbers). I'm not sure the line numbers are useful > in this case > based since the strace output is not shown anywhere or seen in the full. > > .lines().filter()... > > Add the javadoc to the methods so its clear how to use them since this is > a public test framework. > > Regards, Roger > > > On 02/08/2019 04:38 AM, Thomas St?fe wrote: > > Hi Roger, Martin, > > next version: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.02/webrev > > - did massage the comment in ProcessImpl.c > - made the test more resilient by scanning for the strace tool and by > silently ignoring all problems stemming from strace or the payload binary > not being there. The test now only fails if the forks were successully > executed but it does not seem to use posix-spawn. > - added output to the test by printing the "interesting" lines of the > strace output. Note that this filtering is not really sophisticated and > will show all thread related clone() calls as well: > > 614 [pid 12447] <... clone resumed> child_stack=0x7fe00c4baff0, > flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, > parent_tidptr=0x7fe00c4bb9d0, tls=0x7fe00c4bb700, > child_tidptr=0x7fe00c4bb9d0) = 12452 > 646 [pid 12447] clone(/usr/bin/strace: Process 12453 attached > 649 [pid 12447] <... clone resumed> child_stack=0x7fe00c3b9ff0, > flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, > parent_tidptr=0x7fe00c3ba9d0, tls=0x7fe00c3ba700, > child_tidptr=0x7fe00c3ba9d0) = 12453 > .... > > I am sure this could be made more intelligent but lets keep it simple for > now. > > - I removed the helperPath() methods Roger mentioned, they are not needed > anymore. > > @Martin: I like the -e signal=none -e trace=process idea but I'm not sure > if all versions of strace support these options. I think the strace output > is small enough for this small use case, some kB only. > > Cheers, Thomas > > > > > > On Thu, Feb 7, 2019 at 6:01 PM Thomas St?fe > wrote: > >> Hi all, >> >> second version, including the updated comment in ProcessImpl.c Martin >> requested: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html >> >> @Roger: thanks for feeding this into your tests. I still try to get it to >> run thru jdk-submit, but that seems to be stuck again.. >> >> Cheers, Thomas >> >> >> >> >> >> On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe >> wrote: >> >>> Hi all >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 >>> webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html >>> >>> (@Roger: I hope you do not mind? The bug is assigned to you but since I >>> happened to play around with posix_spawn I prepared this webrev. If you >>> rather do this change, that is fine and I will leave it to you.) >>> >>> When we added the possibility to use posix_spawn as underlying >>> implementation for Runtime.exec() on Linux with >>> https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep >>> VFORK as default until work on 13 starts. So now would be a good time to >>> switch the default to posix_spawn to get a good testing window. Note that >>> at SAP we run our VMs internally with posix_spawn as default since some >>> months and have not seen problems. >>> >>> As for the fix, I added a test which tests that the default is indeed >>> posix_spawn - not sure whether this is overdoing it though. Also, I use >>> strace for the test, and /bin/true, and while strace is usually available >>> and reachable by path resolution, I am afraid on some test machines it may >>> not. What do you think, should I leave the test out? >>> >>> The fix ran through all java/lang/ProcessBuilder jtreg tests ok. >>> >>> Thanks, Thomas >>> >>> > From martinrb at google.com Sat Feb 9 19:25:29 2019 From: martinrb at google.com (Martin Buchholz) Date: Sat, 9 Feb 2019 11:25:29 -0800 Subject: RFR: jsr166 integration 2019-02 In-Reply-To: <60392B95-5C77-4FC7-8F44-C618A2122A39@oracle.com> References: <60392B95-5C77-4FC7-8F44-C618A2122A39@oracle.com> Message-ID: Thanks, Chris. On Sat, Feb 9, 2019 at 6:34 AM Chris Hegarty wrote: > 8215359: InnocuousForkJoinWorkerThread.setContextClassLoader needlessly > throws > > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/InnocuousForkJoinWorkerThread/index.html > > > Looks good. A positive test for setContextClassLoader(null) could be > added. > good point - let's improve the test: --- ForkJoinPool9Test.java 14 Dec 2018 02:48:21 -0000 1.6 +++ ForkJoinPool9Test.java 9 Feb 2019 19:18:10 -0000 @@ -11,6 +11,8 @@ import java.util.concurrent.ForkJoinPool; import java.util.concurrent.ForkJoinTask; import java.util.concurrent.Future; +import java.util.concurrent.ThreadLocalRandom; +import java.util.stream.Stream; import junit.framework.Test; import junit.framework.TestSuite; @@ -40,25 +42,32 @@ .findVarHandle(Thread.class, "contextClassLoader", ClassLoader.class); ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader(); boolean haveSecurityManager = (System.getSecurityManager() != null); - CountDownLatch taskStarted = new CountDownLatch(1); + CountDownLatch runInCommonPoolStarted = new CountDownLatch(1); ClassLoader classLoaderDistinctFromSystemClassLoader = ClassLoader.getPlatformClassLoader(); assertNotSame(classLoaderDistinctFromSystemClassLoader, systemClassLoader); Runnable runInCommonPool = () -> { - taskStarted.countDown(); + runInCommonPoolStarted.countDown(); assertTrue(ForkJoinTask.inForkJoinPool()); - assertSame(ForkJoinPool.commonPool(), - ForkJoinTask.getPool()); - assertSame(systemClassLoader, - Thread.currentThread().getContextClassLoader()); - assertSame(systemClassLoader, - CCL.get(Thread.currentThread())); + assertSame(ForkJoinPool.commonPool(), ForkJoinTask.getPool()); + Thread currentThread = Thread.currentThread(); + + Stream.of(systemClassLoader, null).forEach(cl -> { + if (ThreadLocalRandom.current().nextBoolean()) + // should always be permitted, without effect + currentThread.setContextClassLoader(cl); + }); + + Stream.of(currentThread.getContextClassLoader(), + (ClassLoader) CCL.get(currentThread)) + .forEach(cl -> assertTrue(cl == systemClassLoader || cl == null)); + if (haveSecurityManager) assertThrows( SecurityException.class, () -> System.getProperty("foo"), - () -> Thread.currentThread().setContextClassLoader( + () -> currentThread.setContextClassLoader( classLoaderDistinctFromSystemClassLoader)); // TODO ? // if (haveSecurityManager @@ -69,7 +78,7 @@ Future f = ForkJoinPool.commonPool().submit(runInCommonPool); // Ensure runInCommonPool is truly running in the common pool, // by giving this thread no opportunity to "help" on get(). - await(taskStarted); + await(runInCommonPoolStarted); assertNull(f.get()); } From david.holmes at oracle.com Mon Feb 11 03:41:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Feb 2019 13:41:14 +1000 Subject: RFR: jsr166 integration 2019-02 In-Reply-To: References: Message-ID: <056e1b45-0440-448b-aa6b-3e2225cdbc27@oracle.com> Hi Martin, On 9/02/2019 9:42 am, Martin Buchholz wrote: > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html > > 8195057: java/util/concurrent/CountDownLatch/Basic.java failed w/ Xcomp > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CountDownLatch-Basic/index.html > https://bugs.openjdk.java.net/browse/JDK-8195057 Looks fine. > 8215359: InnocuousForkJoinWorkerThread.setContextClassLoader needlessly > throws > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/InnocuousForkJoinWorkerThread/index.html > https://bugs.openjdk.java.net/browse/JDK-8215359 Looks fine. > 8215363: needless signals in ForkJoinPool > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/forkjoin-signals/index.html > https://bugs.openjdk.java.net/browse/JDK-8215363 Can't comment - the code is unfathomable. > Still in limbo: > 8203662: remove increment of modCount from ArrayList and Vector replaceAll() > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html > https://bugs.openjdk.java.net/browse/JDK-8203662 If still in limbo why is this here? > 8215249: Miscellaneous changes imported from jsr166 CVS 2019-02 > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html > https://bugs.openjdk.java.net/browse/JDK-8215249 - CyclicBarrier.java I'm surprised you can just rethrow a Throwable, when the method is not declared to throw Throwable. We always used to have a rethrow(Throwable t) helper method Is this some (fairly) new exception type inference based on what it is in the try block? - test/jdk/java/util/concurrent/tck/CyclicBarrierTest.java Okay. - test/jdk/java/util/Collection/IteratorMicroBenchmark.java Can't comment. Please update copyright year to: Copyright (c) 2007, 2019, Oracle ... - test/jdk/java/util/Collection/RemoveMicroBenchmark.java Okay. Please update copyright year to: Copyright (c) 2007, 2019, Oracle ... Thanks, David From martinrb at google.com Mon Feb 11 04:20:29 2019 From: martinrb at google.com (Martin Buchholz) Date: Sun, 10 Feb 2019 20:20:29 -0800 Subject: RFR: jsr166 integration 2019-02 In-Reply-To: <056e1b45-0440-448b-aa6b-3e2225cdbc27@oracle.com> References: <056e1b45-0440-448b-aa6b-3e2225cdbc27@oracle.com> Message-ID: On Sun, Feb 10, 2019 at 7:41 PM David Holmes wrote: > > > Still in limbo: > > 8203662: remove increment of modCount from ArrayList and Vector > replaceAll() > > > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html > > https://bugs.openjdk.java.net/browse/JDK-8203662 > > If still in limbo why is this here? > It remains in jsr166 CVS. > > 8215249: Miscellaneous changes imported from jsr166 CVS 2019-02 > > > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html > > https://bugs.openjdk.java.net/browse/JDK-8215249 > > - CyclicBarrier.java > > I'm surprised you can just rethrow a Throwable, when the method is not > declared to throw Throwable. We always used to have a rethrow(Throwable > t) helper method Is this some (fairly) new exception type inference > based on what it is in the try block? > I think this is Multi-catch and more precise rethrow From david.holmes at oracle.com Mon Feb 11 04:24:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Feb 2019 14:24:24 +1000 Subject: RFR: jsr166 integration 2019-02 In-Reply-To: References: <056e1b45-0440-448b-aa6b-3e2225cdbc27@oracle.com> Message-ID: <03a50a16-e99f-fd70-c32d-6465af198487@oracle.com> On 11/02/2019 2:20 pm, Martin Buchholz wrote: > On Sun, Feb 10, 2019 at 7:41 PM David Holmes > wrote: > > > > Still in limbo: > > 8203662: remove increment of modCount from ArrayList and Vector > replaceAll() > > > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html > > https://bugs.openjdk.java.net/browse/JDK-8203662 > > If still in limbo why is this here? > > > It remains in jsr166 CVS. Okay but what does that mean for this integration request? I assume you are not actually going to push this change? > > 8215249: Miscellaneous changes imported from jsr166 CVS 2019-02 > > > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html > > https://bugs.openjdk.java.net/browse/JDK-8215249 > > - CyclicBarrier.java > > I'm surprised you can just rethrow a Throwable, when the method is not > declared to throw Throwable. We always used to have a rethrow(Throwable > t) helper method Is this some (fairly) new exception type inference > based on what it is in the try block? > > > I think this is Multi-catch and more precise rethrow > Ah! Right. I recall the multi-catch part but not the more precise rethrow. Thanks, David From martinrb at google.com Mon Feb 11 04:27:55 2019 From: martinrb at google.com (Martin Buchholz) Date: Sun, 10 Feb 2019 20:27:55 -0800 Subject: RFR: jsr166 integration 2019-02 In-Reply-To: <03a50a16-e99f-fd70-c32d-6465af198487@oracle.com> References: <056e1b45-0440-448b-aa6b-3e2225cdbc27@oracle.com> <03a50a16-e99f-fd70-c32d-6465af198487@oracle.com> Message-ID: On Sun, Feb 10, 2019 at 8:24 PM David Holmes wrote: > On 11/02/2019 2:20 pm, Martin Buchholz wrote: > > On Sun, Feb 10, 2019 at 7:41 PM David Holmes > > wrote: > > > > > > > Still in limbo: > > > 8203662: remove increment of modCount from ArrayList and Vector > > replaceAll() > > > > > > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html > > > https://bugs.openjdk.java.net/browse/JDK-8203662 > > > > If still in limbo why is this here? > > > > > > It remains in jsr166 CVS. > > Okay but what does that mean for this integration request? I assume you > are not actually going to push this change? > > It's a vague reminder that someday we need to resolve it one way or the other. From mvala at redhat.com Mon Feb 11 06:52:24 2019 From: mvala at redhat.com (Michal Vala) Date: Mon, 11 Feb 2019 07:52:24 +0100 Subject: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll() In-Reply-To: References: <04961270-1bfe-351b-4402-9fb529a1d630@redhat.com> <121091c7-d5ef-dbfe-c9a7-9583cafda1f5@redhat.com> <8ea87102-1332-53bb-a857-3c1819985a8f@cs.oswego.edu> <7ecd8b5f-5482-0641-6ed5-aca64eb3099f@redhat.com> <0042b18f-3660-d8c0-d749-d38c8f665e90@redhat.com> <20499eb4-891c-fb8c-d39b-a60ce035de56@oracle.com> <206a816f-85c6-5c07-8fce-d6a0497a75b5@redhat.com> Message-ID: <178755cb-f0c1-4754-e029-b62178936bbe@redhat.com> Hi Martin, thank you for reviewing and sponsoring this! On 2/8/19 10:48 PM, Martin Buchholz wrote: > and ... finally committed > (sorry as always for the sloth pace) > > On Wed, Feb 6, 2019 at 10:28 AM Martin Buchholz wrote: > >> Finally got around to doing some work on this. >> I'm happy with this latest revision: >> >> >> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/HashMap-resize/index.html >> >> I did some more work on the microbenchmark, in part to force myself to >> learn about jmh. >> It now tests LinkedHashMap as well. >> I replaced use of Random with ThreadLocalRandom >> >> @Param("1000000") >> private int size; >> >> @Param >> private MapType mapType; >> >> public enum MapType { >> HASH_MAP, >> LINKED_HASH_MAP, >> } >> >> >> >> On Thu, Jan 3, 2019 at 12:31 PM Michal Vala wrote: >> >>> Hi Martin, >>> >>> can we please finish this review? >>> >>> On 12/19/18 6:32 PM, Michal Vala wrote: >>>> >>>> >>>> On 12/19/18 4:15 PM, Martin Buchholz wrote: >>>>> On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs >>> wrote: >>>>> >>>>>> Hi Martin, >>>>>> >>>>>> It is also useful and conventional to print the seed of the random >>>>>> so that if necessary it can be reproduced. >>>>>> >>>>> >>>>> For many years, we've been using ThreadLocalRandom for testing, and >>> that >>>>> does not allow setting a seed. >>>>> >>>>> I remain unconvinced that saving a seed has value in the real world. >>> When >>>>> a randomized test fails, running it with sufficient iterations has >>> always >>>>> worked for me. >>>>> >>>> >>>> What's the reason behind using ThreadLocalRandom? >>>> >>>> In my opinion, reproducing the issue is key. One failure of randomized >>> test run >>>> might be caused by one issue, second run due to another issue. How we >>> reproduce >>>> then and how we know even how many issues we have? When we're running >>> random >>>> tests until it pass, it might even hide the issue. >>>> >>>> They sure have good value on reveal the issue, but then we have to know >>> how to >>>> reproduce and what we're searching for. >>>> >>>> If this case would not require ThreadLocalRandom and Random is enough, >>> I'd like >>>> to use that because of benefits I've mentioned. >>>> >>> >>> -- >>> Michal Vala >>> OpenJDK QE >>> Red Hat Czech >>> >> > -- Michal Vala OpenJDK QE Red Hat Czech From chris.hegarty at oracle.com Mon Feb 11 09:03:04 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 11 Feb 2019 09:03:04 +0000 Subject: RFR: jsr166 integration 2019-02 In-Reply-To: References: <60392B95-5C77-4FC7-8F44-C618A2122A39@oracle.com> Message-ID: <3CA208A8-352E-4276-8FDF-8260EBC5DF61@oracle.com> > On 9 Feb 2019, at 19:25, Martin Buchholz wrote: > > Thanks, Chris. > > On Sat, Feb 9, 2019 at 6:34 AM Chris Hegarty > wrote: >> 8215359: InnocuousForkJoinWorkerThread.setContextClassLoader needlessly >> throws >> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/InnocuousForkJoinWorkerThread/index.html > > Looks good. A positive test for setContextClassLoader(null) could be > added. > > good point - let's improve the test: > The updated test looks good. -Chris. From Roger.Riggs at oracle.com Mon Feb 11 14:08:55 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 11 Feb 2019 09:08:55 -0500 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: <86c2f03f-b1b6-c82f-6244-81c0e0137244@oracle.com> Message-ID: Hi Thomas, I'd be fine with leaving it out.? It only provides confirmation of the library call, nothing algorithmic or complex and there is no bug to verify. So yes, drop it and save the test time and maintenance. Thanks, Roger On 02/09/2019 10:24 AM, Thomas St?fe wrote: > Hi Roger, > > I start getting doubts about the whole test, honestly. Do you think it > is worth the maintenance effort to test that we indeed call > posix_spawn as we intended to? I wonder whether I should just scratch it. > > ..Thomas > > > > On Fri, Feb 8, 2019 at 10:00 PM Roger Riggs > wrote: > > Hi Thomas, > > The new OutputAnalyzer methods are new: > > 496: now that we have Immutable Lists, can the filterByKeyword > argument be a List? > > List interesting = List.of( "fork", "clone", "vfork", > "exec", "/bin/true", "jspawnhelper" ); > > 497: Instead of passing an int, pass the String itself > 480, 485: that is returned from getStdout() or getStderr(). > > The body of the method could probably be nicely written using the > Stream API. > (except for the line numbers).? I'm not sure the line numbers are > useful in this case > based since the strace output is not shown anywhere or seen in the > full. > > ?? .lines().filter()... > > Add the javadoc to the methods so its clear how to use them since > this is a public test framework. > > Regards, Roger > > > On 02/08/2019 04:38 AM, Thomas St?fe wrote: >> Hi Roger, Martin, >> >> next version: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.02/webrev >> >> >> - did massage the comment in ProcessImpl.c >> - made the test more resilient by scanning for the strace tool >> and by silently ignoring all problems stemming from strace or the >> payload binary not being there. The test now only fails if the >> forks were successully executed but it does not seem to use >> posix-spawn. >> - added output to the test by printing the "interesting" lines of >> the strace output. Note that this filtering is not really >> sophisticated and will show all thread related clone() calls as well: >> >> 614 ? [pid 12447] <... clone resumed> child_stack=0x7fe00c4baff0, >> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, >> parent_tidptr=0x7fe00c4bb9d0, tls=0x7fe00c4bb700, >> child_tidptr=0x7fe00c4bb9d0) = 12452 >> 646 ? [pid 12447] clone(/usr/bin/strace: Process 12453 attached >> 649 ? [pid 12447] <... clone resumed> child_stack=0x7fe00c3b9ff0, >> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, >> parent_tidptr=0x7fe00c3ba9d0, tls=0x7fe00c3ba700, >> child_tidptr=0x7fe00c3ba9d0) = 12453 >> .... >> >> I am sure this could be made more intelligent but lets keep it >> simple for now. >> >> - I removed the helperPath() methods Roger mentioned, they are >> not needed anymore. >> >> @Martin: I like the -e signal=none -e trace=process idea but I'm >> not sure if all versions of strace support these options. I think >> the strace output is small enough for this small use case, some >> kB only. >> >> Cheers, Thomas >> >> >> >> >> >> On Thu, Feb 7, 2019 at 6:01 PM Thomas St?fe >> > wrote: >> >> Hi all, >> >> second version, including the updated comment in >> ProcessImpl.c Martin requested: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html >> >> >> @Roger: thanks for feeding this into your tests. I still try >> to get it to run thru jdk-submit, but that seems to be stuck >> again.. >> >> Cheers, Thomas >> >> >> >> >> >> On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe >> > wrote: >> >> Hi all >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html >> >> >> (@Roger: I hope you do not mind? The bug is assigned to >> you but since I happened to play around with posix_spawn >> I prepared this webrev. If you rather do this change, >> that is fine and I will leave it to you.) >> >> When we added the possibility to use posix_spawn as >> underlying implementation for Runtime.exec() on Linux >> with https://bugs.openjdk.java.net/browse/JDK-8212828, we >> agreed to keep VFORK as default until work on 13 starts. >> So now would be a good time to switch the default to >> posix_spawn to get a good testing window. Note that at >> SAP we run our VMs internally with posix_spawn as default >> since some months and have not seen problems. >> >> As for the fix, I added a test which tests that the >> default is indeed posix_spawn - not sure whether this is >> overdoing it though. Also, I use strace for the test, and >> /bin/true, and while strace is usually available and >> reachable by path resolution, I am afraid on some test >> machines it may not. What do you think, should I leave >> the test out? >> >> The fix ran through all java/lang/ProcessBuilder jtreg >> tests ok. >> >> Thanks, Thomas >> > From Roger.Riggs at oracle.com Mon Feb 11 15:30:57 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 11 Feb 2019 10:30:57 -0500 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: <445d726b-5a45-b43f-3aea-452fbfc10124@oracle.com> References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> <07bbc6e7-0656-0efa-0f24-987aeb43e9cc@oracle.com> <445d726b-5a45-b43f-3aea-452fbfc10124@oracle.com> Message-ID: <141ec0dc-beba-6ae3-1dc2-21f7f77bcb9b@oracle.com> Hi Ivan, I called it out because the CSR does not mention that the behavior of some of the cases (-1..-16) is changing and some of the emails asserted there was no change in behavior. I'm fine with one changeset as long as both changes are explicit. The bug and the CSR should both be updated. Thanks, Roger On 02/08/2019 05:12 PM, Ivan Gerasimov wrote: > Hi Roger! > > That's because two tiny changes are combined in the patch: > > 1) remove a problematic statement from the javadoc, as it doesn't hold > anyway.? This part does not change the behavior. > > 2) unify type of the exception thrown for all negative values of > CharSequence.length().? The regression test is to verify this, second > change, so it fails prior the fix for length in [-16, -1]. > > I can separate them into different bugs, if you think it will make it > clearer.? Though I thought they can be fixed together. > > With kind regards, > > Ivan > > > On 2/8/19 1:49 PM, Roger Riggs wrote: >> Hi Ivan, >> >> In the direction of not changing the behavior; the webrev does change >> the behavior. >> >> In the case of CharSeqence with length -1..-16, the new behavior >> throws NegativeArrayIndexException >> instead of java.lang.IndexOutOfBoundsException. >> >> >> AbstractStringBuilder:101-102 throw an exception for length < 0. >> However, the current behavior is to create a StringBuffer with length >> + 16 and >> then append the contents.? For -1..-16, it will succeed in creating a >> StringBuffer >> but fail with IndexOutOfBoundsException during the append of the >> contents. >> >> The new Test should pass both before and after the change to the code. >> >> Roger >> >> >> On 02/07/2019 10:19 PM, Ivan Gerasimov wrote: >>> >>> >>> On 2/7/19 6:33 PM, David Holmes wrote: >>>> On 8/02/2019 11:59 am, Ivan Gerasimov wrote: >>>>> Hi David! >>>>> >>>>> >>>>> On 2/7/19 5:16 PM, David Holmes wrote: >>>>>> Hi Ivan, >>>>>> >>>>>> On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >>>>>>> Hello! >>>>>>> >>>>>>> The specification states: >>>>>>> """ >>>>>>> If the length of the specified CharSequence is less than or >>>>>>> equal to zero, then an empty buffer of capacity 16 is returned. >>>>>>> """ >>>>>>> >>>>>>> However, the current implementation throws either >>>>>>> NegativeArraySizeException or IndexOutOfBounds instead (the >>>>>>> actual exception type depends on the value of reported negative >>>>>>> length). >>>>>> >>>>>> How can you have a negative length CharSequence ?? >>>>>> >>>>> A custom CharSequence returning negative length() can be created. >>>>> Not sure how useful/popular this may be, though. >>>> >>>> Seems pretty meaningless so just treating that as an error seems >>>> fine. Though somewhat debatable whether you need to add an >>>> appropriate @throws. >>>> >>> Right.? There were two reasons not to add @throws here: >>> - by removing the problematic paragraph we just make the javadoc >>> almost the same as for StringBuilder(CharSequence), >>> - we don't seem to have any other places (at least I couldn't find >>> any) specifying exceptions due to negatively sized CharSequence. >>> >>> (To be precise, there is one candidate, but I'll file a separate bug >>> to fix it.) >>> >>>>> That's why I propose just removing the mentioning negative length, >>>>> and not changing the behavior. >>>>> >>>>> The proposed code change is to only unify the behavior for any >>>>> negative value of length. >>>> >>>> Ok. >>>> >>>>>> If its an empty CharSequence then it should return the empty >>>>>> buffer as indicated. >>>>>> >>>>> Empty CharSequence is processed correctly already. >>>> >>>> Okay so by removing this part: >>>> >>>> -????? *

>>>> -????? * If the length of the specified {@code CharSequence} is >>>> -????? * less than or equal to zero, then an empty buffer of capacity >>>> -????? * {@code 16} is returned. >>>> >>>> you're relying on the main specification to implicitly handle the >>>> empty case. >>>> >>> Yes. >>> >>> With kind regards, >>> Ivan >>> >>> >>>> David >>>> ----- >>>> >>>>> With kind regards, >>>>> Ivan >>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> It is proposed to do two things: >>>>>>> 1) remove the problematic sentence from the javadoc (CSR is filed). >>>>>>> 2) unify the exception type thrown, if the argument reports >>>>>>> negative length. >>>>>>> NegativeArraySizeException will be consistent with, for example, >>>>>>> StringBuffer(negativeCapacity). >>>>>>> >>>>>>> Would you please help review the fix? >>>>>>> >>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >>>>>>> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > From thomas.stuefe at gmail.com Mon Feb 11 18:50:47 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Feb 2019 19:50:47 +0100 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: Hi Roger, Martin, hopefully final version: http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.03/webrev/ I removed the test and the changes in the test library made for the test. Test is just too brittle with too little nourishing value. Everything else is unchanged from webrev.02. Thank you, Thomas On Fri, Feb 8, 2019 at 10:38 AM Thomas St?fe wrote: > Hi Roger, Martin, > > next version: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.02/webrev > > - did massage the comment in ProcessImpl.c > - made the test more resilient by scanning for the strace tool and by > silently ignoring all problems stemming from strace or the payload binary > not being there. The test now only fails if the forks were successully > executed but it does not seem to use posix-spawn. > - added output to the test by printing the "interesting" lines of the > strace output. Note that this filtering is not really sophisticated and > will show all thread related clone() calls as well: > > 614 [pid 12447] <... clone resumed> child_stack=0x7fe00c4baff0, > flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, > parent_tidptr=0x7fe00c4bb9d0, tls=0x7fe00c4bb700, > child_tidptr=0x7fe00c4bb9d0) = 12452 > 646 [pid 12447] clone(/usr/bin/strace: Process 12453 attached > 649 [pid 12447] <... clone resumed> child_stack=0x7fe00c3b9ff0, > flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, > parent_tidptr=0x7fe00c3ba9d0, tls=0x7fe00c3ba700, > child_tidptr=0x7fe00c3ba9d0) = 12453 > .... > > I am sure this could be made more intelligent but lets keep it simple for > now. > > - I removed the helperPath() methods Roger mentioned, they are not needed > anymore. > > @Martin: I like the -e signal=none -e trace=process idea but I'm not sure > if all versions of strace support these options. I think the strace output > is small enough for this small use case, some kB only. > > Cheers, Thomas > > > > > > On Thu, Feb 7, 2019 at 6:01 PM Thomas St?fe > wrote: > >> Hi all, >> >> second version, including the updated comment in ProcessImpl.c Martin >> requested: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html >> >> @Roger: thanks for feeding this into your tests. I still try to get it to >> run thru jdk-submit, but that seems to be stuck again.. >> >> Cheers, Thomas >> >> >> >> >> >> On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe >> wrote: >> >>> Hi all >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 >>> webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html >>> >>> (@Roger: I hope you do not mind? The bug is assigned to you but since I >>> happened to play around with posix_spawn I prepared this webrev. If you >>> rather do this change, that is fine and I will leave it to you.) >>> >>> When we added the possibility to use posix_spawn as underlying >>> implementation for Runtime.exec() on Linux with >>> https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep >>> VFORK as default until work on 13 starts. So now would be a good time to >>> switch the default to posix_spawn to get a good testing window. Note that >>> at SAP we run our VMs internally with posix_spawn as default since some >>> months and have not seen problems. >>> >>> As for the fix, I added a test which tests that the default is indeed >>> posix_spawn - not sure whether this is overdoing it though. Also, I use >>> strace for the test, and /bin/true, and while strace is usually available >>> and reachable by path resolution, I am afraid on some test machines it may >>> not. What do you think, should I leave the test out? >>> >>> The fix ran through all java/lang/ProcessBuilder jtreg tests ok. >>> >>> Thanks, Thomas >>> >>> From Roger.Riggs at oracle.com Mon Feb 11 18:54:11 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 11 Feb 2019 13:54:11 -0500 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: <8cec1beb-7e17-ba0d-0120-50832fe14909@oracle.com> Great!? Looks fine. Thanks, Roger On 02/11/2019 01:50 PM, Thomas St?fe wrote: > Hi Roger, Martin, > > hopefully final version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.03/webrev/ > > > I removed the test and the changes in the test library made for the > test. Test is just too brittle with too little nourishing value. > Everything else is unchanged from webrev.02. > > Thank you, Thomas > > > > On Fri, Feb 8, 2019 at 10:38 AM Thomas St?fe > wrote: > > Hi Roger, Martin, > > next version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.02/webrev > > > - did massage the comment in ProcessImpl.c > - made the test more resilient by scanning for the strace tool and > by silently ignoring all problems stemming from strace or the > payload binary not being there. The test now only fails if the > forks were successully executed but it does not seem to use > posix-spawn. > - added output to the test by printing the "interesting" lines of > the strace output. Note that this filtering is not really > sophisticated and will show all thread related clone() calls as well: > > 614 ? [pid 12447] <... clone resumed> child_stack=0x7fe00c4baff0, > flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, > parent_tidptr=0x7fe00c4bb9d0, tls=0x7fe00c4bb700, > child_tidptr=0x7fe00c4bb9d0) = 12452 > 646 ? [pid 12447] clone(/usr/bin/strace: Process 12453 attached > 649 ? [pid 12447] <... clone resumed> child_stack=0x7fe00c3b9ff0, > flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, > parent_tidptr=0x7fe00c3ba9d0, tls=0x7fe00c3ba700, > child_tidptr=0x7fe00c3ba9d0) = 12453 > .... > > I am sure this could be made more intelligent but lets keep it > simple for now. > > - I removed the helperPath() methods Roger mentioned, they are not > needed anymore. > > @Martin: I like the -e signal=none -e trace=process idea but I'm > not sure if all versions of strace support these options. I think > the strace output is small enough for this small use case, some kB > only. > > Cheers, Thomas > > > > > > On Thu, Feb 7, 2019 at 6:01 PM Thomas St?fe > > wrote: > > Hi all, > > second version, including the updated comment in ProcessImpl.c > Martin requested: > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html > > > @Roger: thanks for feeding this into your tests. I still try > to get it to run thru jdk-submit, but that seems to be stuck > again.. > > Cheers, Thomas > > > > > > On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe > > wrote: > > Hi all > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html > > > (@Roger: I hope you do not mind? The bug is assigned to > you but since I happened to play around with posix_spawn I > prepared this webrev. If you rather do this change, that > is fine and I will leave it to you.) > > When we added the possibility to use posix_spawn as > underlying implementation for Runtime.exec() on Linux with > https://bugs.openjdk.java.net/browse/JDK-8212828, we > agreed to keep VFORK as default until work on 13 starts. > So now would be a good time to switch the default to > posix_spawn to get a good testing window. Note that at SAP > we run our VMs internally with posix_spawn as default > since some months and have not seen problems. > > As for the fix, I added a test which tests that the > default is indeed posix_spawn - not sure whether this is > overdoing it though. Also, I use strace for the test, and > /bin/true, and while strace is usually available and > reachable by path resolution, I am afraid on some test > machines it may not. What do you think, should I leave the > test out? > > The fix ran through all java/lang/ProcessBuilder jtreg > tests ok. > > Thanks, Thomas > From thomas.stuefe at gmail.com Mon Feb 11 19:15:52 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Feb 2019 20:15:52 +0100 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: <8cec1beb-7e17-ba0d-0120-50832fe14909@oracle.com> References: <8cec1beb-7e17-ba0d-0120-50832fe14909@oracle.com> Message-ID: Thank you Roger! On Mon, Feb 11, 2019 at 7:55 PM Roger Riggs wrote: > Great! Looks fine. > > Thanks, Roger > > On 02/11/2019 01:50 PM, Thomas St?fe wrote: > > Hi Roger, Martin, > > hopefully final version: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.03/webrev/ > > I removed the test and the changes in the test library made for the test. > Test is just too brittle with too little nourishing value. Everything else > is unchanged from webrev.02. > > Thank you, Thomas > > > > On Fri, Feb 8, 2019 at 10:38 AM Thomas St?fe > wrote: > >> Hi Roger, Martin, >> >> next version: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.02/webrev >> >> - did massage the comment in ProcessImpl.c >> - made the test more resilient by scanning for the strace tool and by >> silently ignoring all problems stemming from strace or the payload binary >> not being there. The test now only fails if the forks were successully >> executed but it does not seem to use posix-spawn. >> - added output to the test by printing the "interesting" lines of the >> strace output. Note that this filtering is not really sophisticated and >> will show all thread related clone() calls as well: >> >> 614 [pid 12447] <... clone resumed> child_stack=0x7fe00c4baff0, >> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, >> parent_tidptr=0x7fe00c4bb9d0, tls=0x7fe00c4bb700, >> child_tidptr=0x7fe00c4bb9d0) = 12452 >> 646 [pid 12447] clone(/usr/bin/strace: Process 12453 attached >> 649 [pid 12447] <... clone resumed> child_stack=0x7fe00c3b9ff0, >> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, >> parent_tidptr=0x7fe00c3ba9d0, tls=0x7fe00c3ba700, >> child_tidptr=0x7fe00c3ba9d0) = 12453 >> .... >> >> I am sure this could be made more intelligent but lets keep it simple for >> now. >> >> - I removed the helperPath() methods Roger mentioned, they are not needed >> anymore. >> >> @Martin: I like the -e signal=none -e trace=process idea but I'm not sure >> if all versions of strace support these options. I think the strace output >> is small enough for this small use case, some kB only. >> >> Cheers, Thomas >> >> >> >> >> >> On Thu, Feb 7, 2019 at 6:01 PM Thomas St?fe >> wrote: >> >>> Hi all, >>> >>> second version, including the updated comment in ProcessImpl.c Martin >>> requested: >>> >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html >>> >>> @Roger: thanks for feeding this into your tests. I still try to get it >>> to run thru jdk-submit, but that seems to be stuck again.. >>> >>> Cheers, Thomas >>> >>> >>> >>> >>> >>> On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe >>> wrote: >>> >>>> Hi all >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 >>>> webrev: >>>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html >>>> >>>> (@Roger: I hope you do not mind? The bug is assigned to you but since I >>>> happened to play around with posix_spawn I prepared this webrev. If you >>>> rather do this change, that is fine and I will leave it to you.) >>>> >>>> When we added the possibility to use posix_spawn as underlying >>>> implementation for Runtime.exec() on Linux with >>>> https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep >>>> VFORK as default until work on 13 starts. So now would be a good time to >>>> switch the default to posix_spawn to get a good testing window. Note that >>>> at SAP we run our VMs internally with posix_spawn as default since some >>>> months and have not seen problems. >>>> >>>> As for the fix, I added a test which tests that the default is indeed >>>> posix_spawn - not sure whether this is overdoing it though. Also, I use >>>> strace for the test, and /bin/true, and while strace is usually available >>>> and reachable by path resolution, I am afraid on some test machines it may >>>> not. What do you think, should I leave the test out? >>>> >>>> The fix ran through all java/lang/ProcessBuilder jtreg tests ok. >>>> >>>> Thanks, Thomas >>>> >>>> > From martinrb at google.com Mon Feb 11 20:18:40 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 11 Feb 2019 12:18:40 -0800 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: Looks good to me. It's true that these tests depending on external tools are very brittle. In particular, strace is in the middle of a flag re-org -e trace=%process -e trace=process (deprecated) Nevertheless, we have such tests - are they worth the maintenance burden? My own Zombies.java test is a good example. On Mon, Feb 11, 2019 at 10:50 AM Thomas St?fe wrote: > Hi Roger, Martin, > > hopefully final version: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.03/webrev/ > > I removed the test and the changes in the test library made for the test. > Test is just too brittle with too little nourishing value. Everything else > is unchanged from webrev.02. > > Thank you, Thomas > > > > On Fri, Feb 8, 2019 at 10:38 AM Thomas St?fe > wrote: > >> Hi Roger, Martin, >> >> next version: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.02/webrev >> >> - did massage the comment in ProcessImpl.c >> - made the test more resilient by scanning for the strace tool and by >> silently ignoring all problems stemming from strace or the payload binary >> not being there. The test now only fails if the forks were successully >> executed but it does not seem to use posix-spawn. >> - added output to the test by printing the "interesting" lines of the >> strace output. Note that this filtering is not really sophisticated and >> will show all thread related clone() calls as well: >> >> 614 [pid 12447] <... clone resumed> child_stack=0x7fe00c4baff0, >> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, >> parent_tidptr=0x7fe00c4bb9d0, tls=0x7fe00c4bb700, >> child_tidptr=0x7fe00c4bb9d0) = 12452 >> 646 [pid 12447] clone(/usr/bin/strace: Process 12453 attached >> 649 [pid 12447] <... clone resumed> child_stack=0x7fe00c3b9ff0, >> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, >> parent_tidptr=0x7fe00c3ba9d0, tls=0x7fe00c3ba700, >> child_tidptr=0x7fe00c3ba9d0) = 12453 >> .... >> >> I am sure this could be made more intelligent but lets keep it simple for >> now. >> >> - I removed the helperPath() methods Roger mentioned, they are not needed >> anymore. >> >> @Martin: I like the -e signal=none -e trace=process idea but I'm not sure >> if all versions of strace support these options. I think the strace output >> is small enough for this small use case, some kB only. >> >> Cheers, Thomas >> >> >> >> >> >> On Thu, Feb 7, 2019 at 6:01 PM Thomas St?fe >> wrote: >> >>> Hi all, >>> >>> second version, including the updated comment in ProcessImpl.c Martin >>> requested: >>> >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html >>> >>> @Roger: thanks for feeding this into your tests. I still try to get it >>> to run thru jdk-submit, but that seems to be stuck again.. >>> >>> Cheers, Thomas >>> >>> >>> >>> >>> >>> On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe >>> wrote: >>> >>>> Hi all >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 >>>> webrev: >>>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html >>>> >>>> (@Roger: I hope you do not mind? The bug is assigned to you but since I >>>> happened to play around with posix_spawn I prepared this webrev. If you >>>> rather do this change, that is fine and I will leave it to you.) >>>> >>>> When we added the possibility to use posix_spawn as underlying >>>> implementation for Runtime.exec() on Linux with >>>> https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep >>>> VFORK as default until work on 13 starts. So now would be a good time to >>>> switch the default to posix_spawn to get a good testing window. Note that >>>> at SAP we run our VMs internally with posix_spawn as default since some >>>> months and have not seen problems. >>>> >>>> As for the fix, I added a test which tests that the default is indeed >>>> posix_spawn - not sure whether this is overdoing it though. Also, I use >>>> strace for the test, and /bin/true, and while strace is usually available >>>> and reachable by path resolution, I am afraid on some test machines it may >>>> not. What do you think, should I leave the test out? >>>> >>>> The fix ran through all java/lang/ProcessBuilder jtreg tests ok. >>>> >>>> Thanks, Thomas >>>> >>>> From andimullaraj at gmail.com Mon Feb 11 20:29:51 2019 From: andimullaraj at gmail.com (Andi Mullaraj) Date: Mon, 11 Feb 2019 12:29:51 -0800 Subject: Java SSLSocketChannel/SSLSelector? Message-ID: Hi java-core community, I have been directed to this channel to discuss matters related to Java performant ssl communications. Maybe this is a topic that has been discussed in the past, in which case I would appreciate if someone pointed me to that particular topic. Back in 2002 I personally applauded the java.nio.channels (jdk1.4) package, realizing that there was no way to port this to the secure communications, due to lack of a comparable implementation for SSL. But I thought it was going to just be matter of time. A couple of years ago I had to go back search for it, and was kind of surprised to find the following in http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG : --- begin quote --- Newcomers to the API may wonder "Why not just have an SSLSocketChannel which extends java.nio.channels.SocketChannel?" There are two main reasons: 1. There were a lot of very difficult questions about what a SSLSocketChannel should be, including its class hierarchy and how it should interoperate with Selectors and other types of SocketChannels. Each proposal brought up more questions than answers. It was noted that any new API abstraction extended to work with SSL/TLS would require the same significant analysis and could result in large and complex APIs. 2. Any JSSE implementation of a new API would be free to choose the "best" I/O & compute strategy, but hiding any of these details is inappropriate for those applications needing full control. Any specific implementation would be inappropriate for some application segment. --- end quote --- It has been a while since this was stated, and I would really like to revisit it. I personally believe that the question #1 has a quite natural answer, while #2 should not really be a concern if we adhere to the spi model where users can bring their own implementation if needed. I know because I have also implemented it (but would like to discuss that in a later stage, if it comes to it). The benefit of such implementation would be immense. Imagine many Java services written with nio and which struggle to move to SSL due to the great complexity of using SSLEngine (zookeeper service to name one), while all they would need to do (if SSLSocketChannels were available) is to instantiate an instance of SSLSocketChannel/SSLSelector when the security is required and the rest would stay the same (as in case of plain communication using SocketChannel/Selector). Another important use case is the advent of IOT, where millions of devices, with relatively low throughput would want to protect their communication via SSL. The ways I have seen the community deal with this are mainly: 1. Go through the pain of learning SSLEngine (and hope to get it right) 2. Build their services around tested libraries (like Jetty, which handle the SSL offload but don't resurface it in SocketChannel/Selector paradigm, that also come with their huge set of dependencies, bringing in unavoidable version collisions) 3. Use proxies (nginx, ha) to deal with the high number of SSL connections and divide the load by scaling horizontally in the back end (making for a harder deployment model) We can make this a lot easier! Any feedback is greatly appreciated, Best, Andi Mullaraj From Michael.Rasmussen at roguewave.com Mon Feb 11 22:23:15 2019 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Mon, 11 Feb 2019 22:23:15 +0000 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com>, Message-ID: The current implementation seems very counter-intuitive with anything that doesn't have the same comparison semantics, for instance a TreeSet/Map with a Comparator, Identity-based Set/Map etc. The output of the following snippet would probably surprise most: /* --- snip --- */ import java.util.*; class Test { public static void main(String[] args) { TreeMap> lengthMap = new TreeMap<>(Comparator.comparingInt(String::length)); List strings = new ArrayList<>(Arrays.asList("The quick brown fox jumps over the lazy dog".split(" "))); for (String s : strings) { lengthMap.computeIfAbsent(s, k -> new ArrayList<>()).add(s); } Set toRemove = lengthMap.keySet(); System.out.println("List before: " + strings); System.out.println("Set to remove: " + toRemove); strings.removeAll(toRemove); System.out.println("List after:" + strings); } } /* --- snip --- */ List before: [The, quick, brown, fox, jumps, over, the, lazy, dog] Set to remove: [The, over, quick] List after:[] /Michael From: core-libs-dev on behalf of Tagir Valeev Sent: 08 February 2019 15:13 To: Stuart Marks Cc: core-libs-dev; Jan Peter Stotz Subject: Re: JDK-6982173: Small problem causing thousands of wasted CPU hours ? Hello! > I would argue that iterating the argument and calling remove() on "this" are the > right semantics, because you want set membership to be determined by this set, > not by whatever collection you pass as an argument. However, I note that > AbstractCollection.removeAll and other removeAll implementations iterate over > "this" and do a contains() check on the argument. The revised > AbstractSet.removeAll would be an outlier here, though it makes sense to me to > do it this way. For complete picture it should be noted that there's a slight difference in remove and removeAll spec: remove removes at most one element while removeAll removes all elements from the specified collection. E.g. c.removeAll(Collections.singleton(foo)) would remove all instances of foo from c while c.remove(foo) would return only one foo. These should be equivalent for Set where repeating elements should not normally appear, but it's wrong for any Collection. That's why AbstractCollection.removeAll cannot be rewritten in the same way. Another interesting thing is java.util.IdentityHashMap.KeySet#removeAll implementation [1]: it reimplements the AbstractCollection#removeAll, because of the same reason: now the first branch of AbstractSet#removeAll becomes incorrect. See the comment before it: ??????? /* ???????? * Must revert from AbstractSet's impl to AbstractCollection's, as ???????? * the former contains an optimization that results in incorrect ???????? * behavior when c is a smaller "normal" (non-identity-based) Set. ???????? */ Btw this comment should be updated to remove a "smaller" condition if the proposed change for AbstractSet will be implemented. [1] http://hg.openjdk.java.net/jdk/jdk/file/e57bcfd7bf79/src/java.base/share/classes/java/util/IdentityHashMap.java#l990 With best regards, Tagir Valeev On Fri, Jan 25, 2019 at 7:11 AM Stuart Marks wrote: > > On 1/23/19 12:05 PM, Jan Peter Stotz wrote: > > like many other I ran into bug JDK-698217 which is about AbstractSet.removeAll() > > and it's "aptitude" in wasting CPU time if you accidentally hit this bug. And > > there are hundred of developers hitting this bug every year. > > > > I simply don't understand why there was no progress in 8 years, on a severe > > performance issue (a removeAll method on an efficient set that can require > > O(n^2)!) caused by code that was written to speed-up the removeAll implementation. > > > > Which makes this bug worse is that it is triggered by the relative size of the > > current set compared to the collection passed as parameter. > > Therefore for most developers this means not to use this buggy function at all > > (once they realized how worse it is). > > I wasn't aware that hundreds of developers are hitting this bug every year. I > haven't seen any mention of it (besides in the bug database) on Twitter, on > Reddit, on DZone, at the conferences I attend, or in several years of > core-libs-dev emails. Well, it was mentioned on core-libs-dev once in 2011 [1] > although that was a suggestion for improvement, not a complaint about performance. > > Nonetheless this is a real problem, and if it's causing difficulties we can > certainly take a look at it. > > There is, however, more to the story. The ACTUAL problem is a semantic one; see > JDK-6394757. [2] Briefly, consider x.removeAll(y). Depending on the relative > sizes of x and y, this method might end up using either x's or y's definition of > membership, which could differ from each other. (See the bug report for an > example.) Thus the semantics of this method depend upon the relative sizes of > the collections, which is arguably flawed. > > Worse, this behavior is specified to iterate this set or the argument, depending > upon their relative sizes. [3] So, fixing this will require an incompatible > specification change. > > The obvious way to fix this is to get rid of the "optimizations" (that turn out > not to be optimizations at all in some cases) and replace it with a simple loop: > >????? public boolean removeAll(Collection c) { >????????? Objects.requireNonNull(c); >????????? boolean modified = false; >????????? for (Object e : c) >????????????? modified |= remove(e); >????????? return modified; >????? } > > I would argue that iterating the argument and calling remove() on "this" are the > right semantics, because you want set membership to be determined by this set, > not by whatever collection you pass as an argument. However, I note that > AbstractCollection.removeAll and other removeAll implementations iterate over > "this" and do a contains() check on the argument. The revised > AbstractSet.removeAll would be an outlier here, though it makes sense to me to > do it this way. > > Is it worth the incompatibility? > > s'marks > > > > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html > > [2] https://bugs.openjdk.java.net/browse/JDK-6394757 > > [3] > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/AbstractSet.html#removeAll(java.util.Collection) > From ivan.gerasimov at oracle.com Mon Feb 11 23:12:15 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 11 Feb 2019 15:12:15 -0800 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: <141ec0dc-beba-6ae3-1dc2-21f7f77bcb9b@oracle.com> References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> <07bbc6e7-0656-0efa-0f24-987aeb43e9cc@oracle.com> <445d726b-5a45-b43f-3aea-452fbfc10124@oracle.com> <141ec0dc-beba-6ae3-1dc2-21f7f77bcb9b@oracle.com> Message-ID: <28ea7fd8-4320-8ac9-b671-134f8fc78ae7@oracle.com> Hi Roger! On 2/11/19 7:30 AM, Roger Riggs wrote: > Hi Ivan, > > I called it out because the CSR does not mention that the behavior > of some of the cases (-1..-16) is changing and some of the emails asserted > there was no change in behavior. > > I'm fine with one changeset as long as both changes are explicit. > The bug and the CSR should both be updated. > Yes, this makes sense. I've updated CSR accordingly, and added a comment to the bug to make the intention of the fix clear. Could you please review the updated CSR? With kind regards, Ivan > Thanks, Roger > > > On 02/08/2019 05:12 PM, Ivan Gerasimov wrote: >> Hi Roger! >> >> That's because two tiny changes are combined in the patch: >> >> 1) remove a problematic statement from the javadoc, as it doesn't >> hold anyway. This part does not change the behavior. >> >> 2) unify type of the exception thrown for all negative values of >> CharSequence.length(). The regression test is to verify this, second >> change, so it fails prior the fix for length in [-16, -1]. >> >> I can separate them into different bugs, if you think it will make it >> clearer. Though I thought they can be fixed together. >> >> With kind regards, >> >> Ivan >> >> >> On 2/8/19 1:49 PM, Roger Riggs wrote: >>> Hi Ivan, >>> >>> In the direction of not changing the behavior; the webrev does >>> change the behavior. >>> >>> In the case of CharSeqence with length -1..-16, the new behavior >>> throws NegativeArrayIndexException >>> instead of java.lang.IndexOutOfBoundsException. >>> >>> >>> AbstractStringBuilder:101-102 throw an exception for length < 0. >>> However, the current behavior is to create a StringBuffer with >>> length + 16 and >>> then append the contents. For -1..-16, it will succeed in creating >>> a StringBuffer >>> but fail with IndexOutOfBoundsException during the append of the >>> contents. >>> >>> The new Test should pass both before and after the change to the code. >>> >>> Roger >>> >>> >>> On 02/07/2019 10:19 PM, Ivan Gerasimov wrote: >>>> >>>> >>>> On 2/7/19 6:33 PM, David Holmes wrote: >>>>> On 8/02/2019 11:59 am, Ivan Gerasimov wrote: >>>>>> Hi David! >>>>>> >>>>>> >>>>>> On 2/7/19 5:16 PM, David Holmes wrote: >>>>>>> Hi Ivan, >>>>>>> >>>>>>> On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >>>>>>>> Hello! >>>>>>>> >>>>>>>> The specification states: >>>>>>>> """ >>>>>>>> If the length of the specified CharSequence is less than or >>>>>>>> equal to zero, then an empty buffer of capacity 16 is returned. >>>>>>>> """ >>>>>>>> >>>>>>>> However, the current implementation throws either >>>>>>>> NegativeArraySizeException or IndexOutOfBounds instead (the >>>>>>>> actual exception type depends on the value of reported negative >>>>>>>> length). >>>>>>> >>>>>>> How can you have a negative length CharSequence ?? >>>>>>> >>>>>> A custom CharSequence returning negative length() can be created. >>>>>> Not sure how useful/popular this may be, though. >>>>> >>>>> Seems pretty meaningless so just treating that as an error seems >>>>> fine. Though somewhat debatable whether you need to add an >>>>> appropriate @throws. >>>>> >>>> Right. There were two reasons not to add @throws here: >>>> - by removing the problematic paragraph we just make the javadoc >>>> almost the same as for StringBuilder(CharSequence), >>>> - we don't seem to have any other places (at least I couldn't find >>>> any) specifying exceptions due to negatively sized CharSequence. >>>> >>>> (To be precise, there is one candidate, but I'll file a separate >>>> bug to fix it.) >>>> >>>>>> That's why I propose just removing the mentioning negative >>>>>> length, and not changing the behavior. >>>>>> >>>>>> The proposed code change is to only unify the behavior for any >>>>>> negative value of length. >>>>> >>>>> Ok. >>>>> >>>>>>> If its an empty CharSequence then it should return the empty >>>>>>> buffer as indicated. >>>>>>> >>>>>> Empty CharSequence is processed correctly already. >>>>> >>>>> Okay so by removing this part: >>>>> >>>>> - *

>>>>> - * If the length of the specified {@code CharSequence} is >>>>> - * less than or equal to zero, then an empty buffer of capacity >>>>> - * {@code 16} is returned. >>>>> >>>>> you're relying on the main specification to implicitly handle the >>>>> empty case. >>>>> >>>> Yes. >>>> >>>> With kind regards, >>>> Ivan >>>> >>>> >>>>> David >>>>> ----- >>>>> >>>>>> With kind regards, >>>>>> Ivan >>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> It is proposed to do two things: >>>>>>>> 1) remove the problematic sentence from the javadoc (CSR is >>>>>>>> filed). >>>>>>>> 2) unify the exception type thrown, if the argument reports >>>>>>>> negative length. >>>>>>>> NegativeArraySizeException will be consistent with, for >>>>>>>> example, StringBuffer(negativeCapacity). >>>>>>>> >>>>>>>> Would you please help review the fix? >>>>>>>> >>>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >>>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >>>>>>>> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > -- With kind regards, Ivan Gerasimov From thomas.stuefe at gmail.com Tue Feb 12 06:41:40 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 12 Feb 2019 07:41:40 +0100 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: On Mon, Feb 11, 2019 at 9:18 PM Martin Buchholz wrote: > Looks good to me. > > Thank you, I just pushed. > It's true that these tests depending on external tools are very brittle. > In particular, strace is in the middle of a flag re-org > > -e trace=%process > -e trace=process (deprecated) > > Nevertheless, we have such tests - are they worth the maintenance burden? > My own Zombies.java test is a good example. > It is more useful than my proposed test was. I wince a bit at the perl requirement though. Especially since the test silently quits if no perl is installed. (As a side note, I wonder whether we could have a mechanism to signal requirements not met, eg. with a TestRequirementsNotMetException, and then let the test executor decide what to do: warn, ignore, error...) I guess part of this could be redone nowadays with Rogers ProcessHandle API (the child seeking), but we still would need to find out if the child is a zombie. I like the test name btw. Very succinct :) ..Thomas > > On Mon, Feb 11, 2019 at 10:50 AM Thomas St?fe > wrote: > >> Hi Roger, Martin, >> >> hopefully final version: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.03/webrev/ >> >> I removed the test and the changes in the test library made for the test. >> Test is just too brittle with too little nourishing value. Everything else >> is unchanged from webrev.02. >> >> Thank you, Thomas >> >> >> >> On Fri, Feb 8, 2019 at 10:38 AM Thomas St?fe >> wrote: >> >>> Hi Roger, Martin, >>> >>> next version: >>> >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.02/webrev >>> >>> - did massage the comment in ProcessImpl.c >>> - made the test more resilient by scanning for the strace tool and by >>> silently ignoring all problems stemming from strace or the payload binary >>> not being there. The test now only fails if the forks were successully >>> executed but it does not seem to use posix-spawn. >>> - added output to the test by printing the "interesting" lines of the >>> strace output. Note that this filtering is not really sophisticated and >>> will show all thread related clone() calls as well: >>> >>> 614 [pid 12447] <... clone resumed> child_stack=0x7fe00c4baff0, >>> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, >>> parent_tidptr=0x7fe00c4bb9d0, tls=0x7fe00c4bb700, >>> child_tidptr=0x7fe00c4bb9d0) = 12452 >>> 646 [pid 12447] clone(/usr/bin/strace: Process 12453 attached >>> 649 [pid 12447] <... clone resumed> child_stack=0x7fe00c3b9ff0, >>> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, >>> parent_tidptr=0x7fe00c3ba9d0, tls=0x7fe00c3ba700, >>> child_tidptr=0x7fe00c3ba9d0) = 12453 >>> .... >>> >>> I am sure this could be made more intelligent but lets keep it simple >>> for now. >>> >>> - I removed the helperPath() methods Roger mentioned, they are not >>> needed anymore. >>> >>> @Martin: I like the -e signal=none -e trace=process idea but I'm not >>> sure if all versions of strace support these options. I think the strace >>> output is small enough for this small use case, some kB only. >>> >>> Cheers, Thomas >>> >>> >>> >>> >>> >>> On Thu, Feb 7, 2019 at 6:01 PM Thomas St?fe >>> wrote: >>> >>>> Hi all, >>>> >>>> second version, including the updated comment in ProcessImpl.c Martin >>>> requested: >>>> >>>> >>>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html >>>> >>>> @Roger: thanks for feeding this into your tests. I still try to get it >>>> to run thru jdk-submit, but that seems to be stuck again.. >>>> >>>> Cheers, Thomas >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe >>>> wrote: >>>> >>>>> Hi all >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html >>>>> >>>>> (@Roger: I hope you do not mind? The bug is assigned to you but since >>>>> I happened to play around with posix_spawn I prepared this webrev. If you >>>>> rather do this change, that is fine and I will leave it to you.) >>>>> >>>>> When we added the possibility to use posix_spawn as underlying >>>>> implementation for Runtime.exec() on Linux with >>>>> https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep >>>>> VFORK as default until work on 13 starts. So now would be a good time to >>>>> switch the default to posix_spawn to get a good testing window. Note that >>>>> at SAP we run our VMs internally with posix_spawn as default since some >>>>> months and have not seen problems. >>>>> >>>>> As for the fix, I added a test which tests that the default is indeed >>>>> posix_spawn - not sure whether this is overdoing it though. Also, I use >>>>> strace for the test, and /bin/true, and while strace is usually available >>>>> and reachable by path resolution, I am afraid on some test machines it may >>>>> not. What do you think, should I leave the test out? >>>>> >>>>> The fix ran through all java/lang/ProcessBuilder jtreg tests ok. >>>>> >>>>> Thanks, Thomas >>>>> >>>>> From goetz.lindenmaier at sap.com Tue Feb 12 13:14:40 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Feb 2019 13:14:40 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> Message-ID: Hi Roger, thanks for looking at my change! > A few higher level issues should be considered, though the details of > the webrev captured my immediate attention. > > Is this the right feature Yes!! > and is this the right level of implementation (C++/native)? See below. > From a security perspective, adding field names to exceptions exposes > information to callers that they could not otherwise get and that breaks > encapsulation. > That needs to be evaluated. I can not comment on that. How can I trigger an evaluation of this? Who needs to evaluate this? > I think there are ways to make this easier to implement and be easier to > maintain and perform better. > > NullPointerException: > 28: unused import of Field Removed > 64: The lazyComputeMessage boolean should be inverted so it does not > require > ?? initialization, false is the default, anything else adds overhead. > ?? And it may not be needed. Peter Levart proposed to initialize the message with a sentinel instead. I'll implement this as a proposal. > 91: Why do you think synchonization is necessary?? It is a performance hit. > ?? It is highly unlikely to be called from multiple threads and the > value will > ?? be the same whether it is computed once or multiple times by > different threads. I guess we can go without. It would be possible to construct a case where two threads do getMessage() on the same NPE Object but the string is not the same. > 99: extendedMessage will never be null (so says the javadoc of > getExtendedNPEMessage) > ? Bug: If it does return null, then null is returned from getMessage > ? regardless of the value of super.getMessage(). Fixed. > 121: Simplify getExtendedNPEMessage by making it only responsible for > the detail > ? and not concatenation with an existing message.? Put that in > getMessage(). Fixed. You are right, I only call this when the message is NULL. > ? Its not strictly necessary to change the updated message with > setMessage(). > ? Avoiding that will avoid complexity and a performance hit. > ? The message will be computed each time it is needed, and that happens > infrequently. > ? (Even in the serialization case, it will be re-computed from the > attached stack frames). No, you can not recompute it from the stacktrace because that does not contain the BCI. Also, after deserialization, the bytecode might look different or not available at all. It depends on the actual bytecode that has been running when the exception was thrown. > ? And it avoids adding setMessage() to Throwable, that's significant > change since > ? the current implementation only allows the message to be initialized > not updated. > ? Immutable is an important characteristic to maintain. Yes, I don't like I have to set this. But it follows the same pattern as with the stack trace which is only computed on demand. Thus, Throwable is not immutable anyways. Before, I implemented this by a JNI call hiding this in the Java code. I proposed implementing setting the field by reflection, Christoph proposed a shared secret. David favored the package private setter. Please advice what is best. > That makes the writeReplace() unnecessary too. No. I need this, see above. > Additional command line arguments are an unnecessary complexity, > documentation, and maintenance overhead.? If the feature is as valuable as > you suggest, it should be enabled all the time. Removed. > I'm assuming there are no tests broken by the modification of the message. > It is likely that somewhere an application or test looks at the message > itself. > Has that been verified? Our nightly testing runs the headless jdk and hostspot jtreg tests, jck tests and some other applications. They are all unaffected by this change after adapting the message in jtreg/vmTestbase/jit/t/t104/t104.gold. (win-x86_64, linux: ppc64, ppc64le, s390, x86_64, aarch, aix, solaris-sparc, mac) Also, I modified quite some messages before which didn't cause any follow-up breakages to my knowledge. > I can't speak for the hotspot code, but that seems to add a lot of code > to support > only this convenience feature.? That's a maintenance overhead and burden. We uses this code since 2006, it needed only few changes. I would like to contribute a follow up for hidden frames of lambdas. > The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a > question > about how useful the information is,? developers should not need to know > about "slot 1". Developers should work with class files with debug information and then they would get the name printed. If exceptions are thrown in production code, any information is helpful. Should I just write "a local"? > The test output of NullPointerExceptionTest shows > "java.lang.Object.hashCode(()I)". > Why is the argument type for Integer shown as "()I";? that's not the > conventional > representation of a primitive int. I already discussed this with David Holmes: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058464.html Other exceptions use the same format. I don't know of an utility in hotspot to translate the format to Java source code syntax. We implemented such an utility in our internal VM, though, and I would like to contribute this, too, adapting all the exceptions. I would do this in a follow-up. > Generally, the explanations are too verbose. > Method names and field names would be easier to recognize if they were > quoted, as is done with 'this'.? Fixed, although this is not common in exception messages. See the messages in http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, line 57ff. Only the String of the name field is quoted, not any entities declared in the code. Similar http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runtime/LoaderConstraints/vtableAME/Test.java line 60, also showing the internal signature, see above. > Argument numbers should be digits, > not English words (first, second, etc) to make them easier to pick out. Fixed. > And has it limits that do not read easily, e.g. "nr. 9". Sorry, I don't understand > I would not describe 'this' as a local variable. Fixed. > Tests, especially new tests should compile without warnings. > NullPointerExceptionTest.java:125 newInstance has been deprecated. Fixed. > The messages can be easier to understand, e.g. > 'field a1 is null, trying to invoke a1.hashCode...' instead of: > "while trying to invoke the method java.lang.Object.hashCode(()I) on a > null reference loaded from local variable 'a1'" The message is built along the structure of the bytecode. I'll try to change this and then will come up with a new webrev . > It will easier to understand if it looks more like the code. > BTW, what does this look like for fully optimized code? You mean whether the bytecode is jitted? It's independent of how the code is executed, interpreted or compiled. > Does it bear any resemblance to the source code at all? > Or does it have to be deoptimized to come up with a sensible source > reference. No, jitted methods must not be deoptimized. > How much of this can be done in Java code with StackWalker and other > java APIs? > It would be a shame to add this much native code if there was a more robust > way to implement it using APIs with more leverage. StackWalker operates on the Java stack tracke, which does not contain the BCI to my knowledge. Also, I need to read the bytecodes. Are there APIs to access the bytecode as it resides in the metaspace, rewritten, constants resolved etc? The code relies on this. Best regards, Goetz. > Regards, Roger > > > On 02/08/2019 09:13 AM, Langer, Christoph wrote: > > Hi Goetz, > > > >> ok, so here a new webrev just adding a setter for the field: > >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 > >> > >> ... and incorporating the other comments. > > Looks better ?? > > > > I have a few additions to > src/java.base/share/classes/java/lang/NullPointerException.java: > > > > 28 import java.lang.reflect.Field; > > 29 > > -> can be removed now. > > > > 91 synchronized (this) { > > -> I think this is not needed here. The transient modifier for > lazyComputeMessage already implies the lock on the Object, I think. > > > > 108 return extendedMessage; > > -> I guess it would be more correct if you returned super.getMessage() here. > > > > Thanks > > Christoph From daniel.fuchs at oracle.com Tue Feb 12 13:54:54 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 12 Feb 2019 14:54:54 +0100 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> Message-ID: Hi Goetz, On 12/02/2019 14:14, Lindenmaier, Goetz wrote: > StackWalker operates on the Java stack tracke, which does not contain the BCI > to my knowledge. For what it's worth, StackWalker::StackFrame has the BCI: returned by public int getByteCodeIndex(); [1] But I am not sure how you would use that in this case. I mean - IIUC the stack would have to be walked when the exception is raised - not when getMessage() is called. It's possible that the BCI is encoded in the backtrace data though. I have not checked. best regards, -- daniel [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/StackWalker.StackFrame.html#getByteCodeIndex() From goetz.lindenmaier at sap.com Tue Feb 12 14:51:26 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Feb 2019 14:51:26 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> Message-ID: Hi Daniel, > public int getByteCodeIndex(); [1] thanks for this info. I missed that. > But I am not sure how you would use that in this case. > I mean - IIUC the stack would have to be walked when the exception > is raised - not when getMessage() is called. It's possible that Well, I will have to call StackWalker in the constructor and remember the data I need. > It's possible that > the BCI is encoded in the backtrace data though. I have not > checked. Yes it is. That is what I'm using currently, in the C++ implementation. See get_method_and_bci in javaClasses.cpp. Best regards, Goetz. > -----Original Message----- > From: Daniel Fuchs > Sent: Dienstag, 12. Februar 2019 14:55 > To: Lindenmaier, Goetz ; Roger Riggs > ; Java Core Libs > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > Hi Goetz, > > On 12/02/2019 14:14, Lindenmaier, Goetz wrote: > > StackWalker operates on the Java stack tracke, which does not contain the > BCI > > to my knowledge. > > For what it's worth, StackWalker::StackFrame has the BCI: returned by > > public int getByteCodeIndex(); [1] > > But I am not sure how you would use that in this case. > I mean - IIUC the stack would have to be walked when the exception > is raised - not when getMessage() is called. It's possible that > the BCI is encoded in the backtrace data though. I have not > checked. > > best regards, > > -- daniel > > [1] > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Stac > kWalker.StackFrame.html#getByteCodeIndex() From Roger.Riggs at oracle.com Tue Feb 12 14:52:16 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 12 Feb 2019 09:52:16 -0500 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: Hi Thomas, For tests that are not applicable but should be noted, a recent addition is throwing jtreg.SkippedException. [1] Adding @library /test/lib to the test header and import jtreg.SkippedException. Throw it when appropriate. See What if a test does not apply in a given situation? http://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation Testng is generally preferred for new test over main tests and it has its own Skipped test mechanism. Regards, Roger On 02/12/2019 01:41 AM, Thomas St?fe wrote: > > (As a side note, I wonder whether we could have a mechanism to signal > requirements not met, eg. with a TestRequirementsNotMetException, and > then let the test executor decide what to do: warn, ignore, error...) > > From thomas.stuefe at gmail.com Tue Feb 12 15:16:05 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 12 Feb 2019 16:16:05 +0100 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: I think there are two kinds of skipping: - Skipping where it just does not make sense to execute the test, e.g. on the wrong OS. That is unexciting. - Skipping where prerequisites are not met and I skip to reduce the test analysis load but actually I would like to execute the test. Those tests one may want to force-execute from time to time. Martins Zombies is a good example - you may never run it without ever realizing if you have not perl installed. But maybe this is all sloppy thinking - one could say the test is either important enough to be executed always, or it is not. In the former case all prerequisites should be installed and skipping is not the right thing to do. Thank you for the TestNG hint. I will check it out. Cheers, Thomas On Tue, Feb 12, 2019 at 3:53 PM Roger Riggs wrote: > Hi Thomas, > > For tests that are not applicable but should be noted, > a recent addition is throwing jtreg.SkippedException. [1] > > Adding @library /test/lib to the test header > and import jtreg.SkippedException. > Throw it when appropriate. > > See What if a test does not apply in a given situation? > > > http://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation > > Testng is generally preferred for new test over main tests and it has its > own Skipped test mechanism. > > Regards, Roger > > On 02/12/2019 01:41 AM, Thomas St?fe wrote: > > > (As a side note, I wonder whether we could have a mechanism to signal > requirements not met, eg. with a TestRequirementsNotMetException, and then > let the test executor decide what to do: warn, ignore, error...) > > > > From Roger.Riggs at oracle.com Tue Feb 12 15:33:49 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 12 Feb 2019 10:33:49 -0500 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: <28ea7fd8-4320-8ac9-b671-134f8fc78ae7@oracle.com> References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> <07bbc6e7-0656-0efa-0f24-987aeb43e9cc@oracle.com> <445d726b-5a45-b43f-3aea-452fbfc10124@oracle.com> <141ec0dc-beba-6ae3-1dc2-21f7f77bcb9b@oracle.com> <28ea7fd8-4320-8ac9-b671-134f8fc78ae7@oracle.com> Message-ID: <1e291796-7751-0008-6eb3-96a1e680acd3@oracle.com> Hi Ivan, The change to consistently throw NegativeSizeArrayException applies to StringBuilder also. Please mention that with the solution. Thanks, Roger On 02/11/2019 06:12 PM, Ivan Gerasimov wrote: > Hi Roger! > > > On 2/11/19 7:30 AM, Roger Riggs wrote: >> Hi Ivan, >> >> I called it out because the CSR does not mention that the behavior >> of some of the cases (-1..-16) is changing and some of the emails >> asserted >> there was no change in behavior. >> >> I'm fine with one changeset as long as both changes are explicit. >> The bug and the CSR should both be updated. >> > Yes, this makes sense. > I've updated CSR accordingly, and added a comment to the bug to make > the intention of the fix clear. > > Could you please review the updated CSR? > > With kind regards, > Ivan > > > >> Thanks, Roger >> >> >> On 02/08/2019 05:12 PM, Ivan Gerasimov wrote: >>> Hi Roger! >>> >>> That's because two tiny changes are combined in the patch: >>> >>> 1) remove a problematic statement from the javadoc, as it doesn't >>> hold anyway.? This part does not change the behavior. >>> >>> 2) unify type of the exception thrown for all negative values of >>> CharSequence.length().? The regression test is to verify this, >>> second change, so it fails prior the fix for length in [-16, -1]. >>> >>> I can separate them into different bugs, if you think it will make >>> it clearer.? Though I thought they can be fixed together. >>> >>> With kind regards, >>> >>> Ivan >>> >>> >>> On 2/8/19 1:49 PM, Roger Riggs wrote: >>>> Hi Ivan, >>>> >>>> In the direction of not changing the behavior; the webrev does >>>> change the behavior. >>>> >>>> In the case of CharSeqence with length -1..-16, the new behavior >>>> throws NegativeArrayIndexException >>>> instead of java.lang.IndexOutOfBoundsException. >>>> >>>> >>>> AbstractStringBuilder:101-102 throw an exception for length < 0. >>>> However, the current behavior is to create a StringBuffer with >>>> length + 16 and >>>> then append the contents.? For -1..-16, it will succeed in creating >>>> a StringBuffer >>>> but fail with IndexOutOfBoundsException during the append of the >>>> contents. >>>> >>>> The new Test should pass both before and after the change to the code. >>>> >>>> Roger >>>> >>>> >>>> On 02/07/2019 10:19 PM, Ivan Gerasimov wrote: >>>>> >>>>> >>>>> On 2/7/19 6:33 PM, David Holmes wrote: >>>>>> On 8/02/2019 11:59 am, Ivan Gerasimov wrote: >>>>>>> Hi David! >>>>>>> >>>>>>> >>>>>>> On 2/7/19 5:16 PM, David Holmes wrote: >>>>>>>> Hi Ivan, >>>>>>>> >>>>>>>> On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >>>>>>>>> Hello! >>>>>>>>> >>>>>>>>> The specification states: >>>>>>>>> """ >>>>>>>>> If the length of the specified CharSequence is less than or >>>>>>>>> equal to zero, then an empty buffer of capacity 16 is returned. >>>>>>>>> """ >>>>>>>>> >>>>>>>>> However, the current implementation throws either >>>>>>>>> NegativeArraySizeException or IndexOutOfBounds instead (the >>>>>>>>> actual exception type depends on the value of reported >>>>>>>>> negative length). >>>>>>>> >>>>>>>> How can you have a negative length CharSequence ?? >>>>>>>> >>>>>>> A custom CharSequence returning negative length() can be created. >>>>>>> Not sure how useful/popular this may be, though. >>>>>> >>>>>> Seems pretty meaningless so just treating that as an error seems >>>>>> fine. Though somewhat debatable whether you need to add an >>>>>> appropriate @throws. >>>>>> >>>>> Right.? There were two reasons not to add @throws here: >>>>> - by removing the problematic paragraph we just make the javadoc >>>>> almost the same as for StringBuilder(CharSequence), >>>>> - we don't seem to have any other places (at least I couldn't find >>>>> any) specifying exceptions due to negatively sized CharSequence. >>>>> >>>>> (To be precise, there is one candidate, but I'll file a separate >>>>> bug to fix it.) >>>>> >>>>>>> That's why I propose just removing the mentioning negative >>>>>>> length, and not changing the behavior. >>>>>>> >>>>>>> The proposed code change is to only unify the behavior for any >>>>>>> negative value of length. >>>>>> >>>>>> Ok. >>>>>> >>>>>>>> If its an empty CharSequence then it should return the empty >>>>>>>> buffer as indicated. >>>>>>>> >>>>>>> Empty CharSequence is processed correctly already. >>>>>> >>>>>> Okay so by removing this part: >>>>>> >>>>>> -????? *

>>>>>> -????? * If the length of the specified {@code CharSequence} is >>>>>> -????? * less than or equal to zero, then an empty buffer of >>>>>> capacity >>>>>> -????? * {@code 16} is returned. >>>>>> >>>>>> you're relying on the main specification to implicitly handle the >>>>>> empty case. >>>>>> >>>>> Yes. >>>>> >>>>> With kind regards, >>>>> Ivan >>>>> >>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> With kind regards, >>>>>>> Ivan >>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>>> It is proposed to do two things: >>>>>>>>> 1) remove the problematic sentence from the javadoc (CSR is >>>>>>>>> filed). >>>>>>>>> 2) unify the exception type thrown, if the argument reports >>>>>>>>> negative length. >>>>>>>>> NegativeArraySizeException will be consistent with, for >>>>>>>>> example, StringBuffer(negativeCapacity). >>>>>>>>> >>>>>>>>> Would you please help review the fix? >>>>>>>>> >>>>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >>>>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >>>>>>>>> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From Roger.Riggs at oracle.com Tue Feb 12 16:03:19 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 12 Feb 2019 11:03:19 -0500 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> Message-ID: <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> Hi, On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote: > Hi Roger, > > thanks for looking at my change! > >> A few higher level issues should be considered, though the details of >> the webrev captured my immediate attention. >> >> Is this the right feature > Yes!! Maybe, that's what debuggers are for. > >> and is this the right level of implementation (C++/native)? > See below. Maybe 10 years ago, when native was the only solution. Now there are tools to analyze bytecode in java. > >> From a security perspective, adding field names to exceptions exposes >> information to callers that they could not otherwise get and that breaks >> encapsulation. >> That needs to be evaluated. > I can not comment on that. How can I trigger an evaluation of this? > Who needs to evaluate this? > >> I think there are ways to make this easier to implement and be easier to >> maintain and perform better. >> >> NullPointerException: >> 28: unused import of Field > Removed > >> 64: The lazyComputeMessage boolean should be inverted so it does not >> require >> ?? initialization, false is the default, anything else adds overhead. >> ?? And it may not be needed. > Peter Levart proposed to initialize the message with a sentinel instead. > I'll implement this as a proposal. That's an extra overhead too, any assignment is. > >> 91: Why do you think synchonization is necessary?? It is a performance hit. >> ?? It is highly unlikely to be called from multiple threads and the >> value will >> ?? be the same whether it is computed once or multiple times by >> different threads. > I guess we can go without. > It would be possible to construct a case where two threads > do getMessage() on the same NPE Object but the string is not > the same. Really!, if the bci is the same, the bytecode is the same, what could be different that would change the data used to create the exception? > >> 99: extendedMessage will never be null (so says the javadoc of >> getExtendedNPEMessage) >> ? Bug: If it does return null, then null is returned from getMessage >> ? regardless of the value of super.getMessage(). > Fixed. > >> 121: Simplify getExtendedNPEMessage by making it only responsible for >> the detail >> ? and not concatenation with an existing message.? Put that in >> getMessage(). > Fixed. You are right, I only call this when the message is NULL. > >> ? Its not strictly necessary to change the updated message with >> setMessage(). >> ? Avoiding that will avoid complexity and a performance hit. >> ? The message will be computed each time it is needed, and that happens >> infrequently. >> ? (Even in the serialization case, it will be re-computed from the >> attached stack frames). > No, you can not recompute it from the stacktrace because that > does not contain the BCI. Also, after deserialization, the bytecode > might look different or not available at all. It depends on the actual > bytecode that has been running when the exception was thrown. Right, I realized this too when thinking about it over the weekend. If a suitable low impact mechanism can't be found, then just go back to not exposing the extended message and use only the original. Its a bad idea to twist and contort the local design and accessibility just for serialization. What remote or delayed client needs to know this? > >> ? And it avoids adding setMessage() to Throwable, that's significant >> change since >> ? the current implementation only allows the message to be initialized >> not updated. >> ? Immutable is an important characteristic to maintain. > Yes, I don't like I have to set this. But it follows the same pattern > as with the stack trace which is only computed on demand. Thus, > Throwable is not immutable anyways. Before, I implemented this by a > JNI call hiding this in the Java code. > I proposed implementing setting the field by reflection, Christoph > proposed a shared secret. David favored the package private setter. > Please advice what is best. All of them are bad. Private needs to mean private. And making it mutable, also means that synchronization or volatile is needed to ensure a consistent value for getMessage(). That turns into a performance issue for all throwables. None of the above. > >> That makes the writeReplace() unnecessary too. > No. I need this, see above. See above, but is not essential to the core feature. > >> Additional command line arguments are an unnecessary complexity, >> documentation, and maintenance overhead.? If the feature is as valuable as >> you suggest, it should be enabled all the time. > Removed. > >> I'm assuming there are no tests broken by the modification of the message. >> It is likely that somewhere an application or test looks at the message >> itself. >> Has that been verified? > Our nightly testing runs the headless jdk and hostspot jtreg tests, jck tests and some > other applications. They are all unaffected by this change after adapting the > message in jtreg/vmTestbase/jit/t/t104/t104.gold. > (win-x86_64, linux: ppc64, ppc64le, s390, x86_64, aarch, aix, solaris-sparc, mac) > Also, I modified quite some messages before which didn't cause any follow-up > breakages to my knowledge. It does seem unlikely. > >> I can't speak for the hotspot code, but that seems to add a lot of code >> to support >> only this convenience feature.? That's a maintenance overhead and burden. > We uses this code since 2006, it needed only few changes. I would like to > contribute a follow up for hidden frames of lambdas. Valhalla and evolution of the byte code needs to be considered. Just because its worked for years does not mean its the best approach today.? Dropping it in now means maintaining it in its current form or needing to re-write it later. > >> The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a >> question >> about how useful the information is,? developers should not need to know >> about "slot 1". > Developers should work with class files with debug information and then > they would get the name printed. If exceptions are thrown in production > code, any information is helpful. Should I just write "a local"? Go back to who you think is going to benefit from it, it seems targeted at a fairly novice developer, so exposing low level details may be more confusing that just giving a line number and NPE. > >> The test output of NullPointerExceptionTest shows >> "java.lang.Object.hashCode(()I)". >> Why is the argument type for Integer shown as "()I";? that's not the >> conventional >> representation of a primitive int. > I already discussed this with David Holmes: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058464.html > Other exceptions use the same format. I don't know of an utility in > hotspot to translate the format to Java source code syntax. We > implemented such an utility in our internal VM, though, and I would > like to contribute this, too, adapting all the exceptions. I would do this > in a follow-up. There may be better tools for formatting if it was done in java at a more appropriate level of abstraction. > >> Generally, the explanations are too verbose. >> Method names and field names would be easier to recognize if they were >> quoted, as is done with 'this'. > Fixed, although this is not common in exception messages. See the > messages in http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, > line 57ff. Only the String of the name field is quoted, not any entities > declared in the code. > Similar http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runtime/LoaderConstraints/vtableAME/Test.java > line 60, also showing the internal signature, see above. > >> Argument numbers should be digits, >> not English words (first, second, etc) to make them easier to pick out. > Fixed. >> And has it limits that do not read easily, e.g. "nr. 9". > Sorry, I don't understand src/hotspot/share/classfile/bytecodeUtils.cpp:566 test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerExceptionTest.java:612 >> I would not describe 'this' as a local variable. > Fixed. > >> Tests, especially new tests should compile without warnings. >> NullPointerExceptionTest.java:125 newInstance has been deprecated. > Fixed. > >> The messages can be easier to understand, e.g. >> 'field a1 is null, trying to invoke a1.hashCode...' instead of: >> "while trying to invoke the method java.lang.Object.hashCode(()I) on a >> null reference loaded from local variable 'a1'" > The message is built along the structure of the bytecode. > I'll try to change this and then will come up with a new webrev . > >> It will easier to understand if it looks more like the code. >> BTW, what does this look like for fully optimized code? > You mean whether the bytecode is jitted? It's independent > of how the code is executed, interpreted or compiled. > >> Does it bear any resemblance to the source code at all? >> Or does it have to be deoptimized to come up with a sensible source >> reference. > No, jitted methods must not be deoptimized. > >> How much of this can be done in Java code with StackWalker and other >> java APIs? >> It would be a shame to add this much native code if there was a more robust >> way to implement it using APIs with more leverage. > StackWalker operates on the Java stack tracke, which does not contain the BCI > to my knowledge. Also, I need to read the bytecodes. Are there APIs to access > the bytecode as it resides in the metaspace, rewritten, constants resolved etc? > The code relies on this. From the other thread, beware adding overhead to the constructor. The lazy computation is essential. There are a *lot* of NPEs whose messages will never be needed. Regards, Roger > > Best regards, > Goetz. > > > >> Regards, Roger >> >> >> On 02/08/2019 09:13 AM, Langer, Christoph wrote: >>> Hi Goetz, >>> >>>> ok, so here a new webrev just adding a setter for the field: >>>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 >>>> >>>> ... and incorporating the other comments. >>> Looks better ?? >>> >>> I have a few additions to >> src/java.base/share/classes/java/lang/NullPointerException.java: >>> 28 import java.lang.reflect.Field; >>> 29 >>> -> can be removed now. >>> >>> 91 synchronized (this) { >>> -> I think this is not needed here. The transient modifier for >> lazyComputeMessage already implies the lock on the Object, I think. >>> 108 return extendedMessage; >>> -> I guess it would be more correct if you returned super.getMessage() here. >>> >>> Thanks >>> Christoph From ivan.gerasimov at oracle.com Tue Feb 12 16:39:06 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 12 Feb 2019 08:39:06 -0800 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: <1e291796-7751-0008-6eb3-96a1e680acd3@oracle.com> References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> <07bbc6e7-0656-0efa-0f24-987aeb43e9cc@oracle.com> <445d726b-5a45-b43f-3aea-452fbfc10124@oracle.com> <141ec0dc-beba-6ae3-1dc2-21f7f77bcb9b@oracle.com> <28ea7fd8-4320-8ac9-b671-134f8fc78ae7@oracle.com> <1e291796-7751-0008-6eb3-96a1e680acd3@oracle.com> Message-ID: <650db381-af59-096d-15f8-908f29229c69@oracle.com> On 2/12/19 7:33 AM, Roger Riggs wrote: > Hi Ivan, > > The change to consistently throw NegativeSizeArrayException applies to > StringBuilder also. > Please mention that with the solution. > Right, thanks. I updated CSR accordingly. With kind regards, Ivan > Thanks, Roger > > > On 02/11/2019 06:12 PM, Ivan Gerasimov wrote: >> Hi Roger! >> >> >> On 2/11/19 7:30 AM, Roger Riggs wrote: >>> Hi Ivan, >>> >>> I called it out because the CSR does not mention that the behavior >>> of some of the cases (-1..-16) is changing and some of the emails >>> asserted >>> there was no change in behavior. >>> >>> I'm fine with one changeset as long as both changes are explicit. >>> The bug and the CSR should both be updated. >>> >> Yes, this makes sense. >> I've updated CSR accordingly, and added a comment to the bug to make >> the intention of the fix clear. >> >> Could you please review the updated CSR? >> >> With kind regards, >> Ivan >> >> >> >>> Thanks, Roger >>> >>> >>> On 02/08/2019 05:12 PM, Ivan Gerasimov wrote: >>>> Hi Roger! >>>> >>>> That's because two tiny changes are combined in the patch: >>>> >>>> 1) remove a problematic statement from the javadoc, as it doesn't >>>> hold anyway. This part does not change the behavior. >>>> >>>> 2) unify type of the exception thrown for all negative values of >>>> CharSequence.length(). The regression test is to verify this, >>>> second change, so it fails prior the fix for length in [-16, -1]. >>>> >>>> I can separate them into different bugs, if you think it will make >>>> it clearer. Though I thought they can be fixed together. >>>> >>>> With kind regards, >>>> >>>> Ivan >>>> >>>> >>>> On 2/8/19 1:49 PM, Roger Riggs wrote: >>>>> Hi Ivan, >>>>> >>>>> In the direction of not changing the behavior; the webrev does >>>>> change the behavior. >>>>> >>>>> In the case of CharSeqence with length -1..-16, the new behavior >>>>> throws NegativeArrayIndexException >>>>> instead of java.lang.IndexOutOfBoundsException. >>>>> >>>>> >>>>> AbstractStringBuilder:101-102 throw an exception for length < 0. >>>>> However, the current behavior is to create a StringBuffer with >>>>> length + 16 and >>>>> then append the contents. For -1..-16, it will succeed in >>>>> creating a StringBuffer >>>>> but fail with IndexOutOfBoundsException during the append of the >>>>> contents. >>>>> >>>>> The new Test should pass both before and after the change to the >>>>> code. >>>>> >>>>> Roger >>>>> >>>>> >>>>> On 02/07/2019 10:19 PM, Ivan Gerasimov wrote: >>>>>> >>>>>> >>>>>> On 2/7/19 6:33 PM, David Holmes wrote: >>>>>>> On 8/02/2019 11:59 am, Ivan Gerasimov wrote: >>>>>>>> Hi David! >>>>>>>> >>>>>>>> >>>>>>>> On 2/7/19 5:16 PM, David Holmes wrote: >>>>>>>>> Hi Ivan, >>>>>>>>> >>>>>>>>> On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >>>>>>>>>> Hello! >>>>>>>>>> >>>>>>>>>> The specification states: >>>>>>>>>> """ >>>>>>>>>> If the length of the specified CharSequence is less than or >>>>>>>>>> equal to zero, then an empty buffer of capacity 16 is returned. >>>>>>>>>> """ >>>>>>>>>> >>>>>>>>>> However, the current implementation throws either >>>>>>>>>> NegativeArraySizeException or IndexOutOfBounds instead (the >>>>>>>>>> actual exception type depends on the value of reported >>>>>>>>>> negative length). >>>>>>>>> >>>>>>>>> How can you have a negative length CharSequence ?? >>>>>>>>> >>>>>>>> A custom CharSequence returning negative length() can be created. >>>>>>>> Not sure how useful/popular this may be, though. >>>>>>> >>>>>>> Seems pretty meaningless so just treating that as an error seems >>>>>>> fine. Though somewhat debatable whether you need to add an >>>>>>> appropriate @throws. >>>>>>> >>>>>> Right. There were two reasons not to add @throws here: >>>>>> - by removing the problematic paragraph we just make the javadoc >>>>>> almost the same as for StringBuilder(CharSequence), >>>>>> - we don't seem to have any other places (at least I couldn't >>>>>> find any) specifying exceptions due to negatively sized >>>>>> CharSequence. >>>>>> >>>>>> (To be precise, there is one candidate, but I'll file a separate >>>>>> bug to fix it.) >>>>>> >>>>>>>> That's why I propose just removing the mentioning negative >>>>>>>> length, and not changing the behavior. >>>>>>>> >>>>>>>> The proposed code change is to only unify the behavior for any >>>>>>>> negative value of length. >>>>>>> >>>>>>> Ok. >>>>>>> >>>>>>>>> If its an empty CharSequence then it should return the empty >>>>>>>>> buffer as indicated. >>>>>>>>> >>>>>>>> Empty CharSequence is processed correctly already. >>>>>>> >>>>>>> Okay so by removing this part: >>>>>>> >>>>>>> - *

>>>>>>> - * If the length of the specified {@code CharSequence} is >>>>>>> - * less than or equal to zero, then an empty buffer of >>>>>>> capacity >>>>>>> - * {@code 16} is returned. >>>>>>> >>>>>>> you're relying on the main specification to implicitly handle >>>>>>> the empty case. >>>>>>> >>>>>> Yes. >>>>>> >>>>>> With kind regards, >>>>>> Ivan >>>>>> >>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> With kind regards, >>>>>>>> Ivan >>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> It is proposed to do two things: >>>>>>>>>> 1) remove the problematic sentence from the javadoc (CSR is >>>>>>>>>> filed). >>>>>>>>>> 2) unify the exception type thrown, if the argument reports >>>>>>>>>> negative length. >>>>>>>>>> NegativeArraySizeException will be consistent with, for >>>>>>>>>> example, StringBuffer(negativeCapacity). >>>>>>>>>> >>>>>>>>>> Would you please help review the fix? >>>>>>>>>> >>>>>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >>>>>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >>>>>>>>>> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > -- With kind regards, Ivan Gerasimov From Roger.Riggs at oracle.com Tue Feb 12 16:51:54 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 12 Feb 2019 11:51:54 -0500 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: <650db381-af59-096d-15f8-908f29229c69@oracle.com> References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> <07bbc6e7-0656-0efa-0f24-987aeb43e9cc@oracle.com> <445d726b-5a45-b43f-3aea-452fbfc10124@oracle.com> <141ec0dc-beba-6ae3-1dc2-21f7f77bcb9b@oracle.com> <28ea7fd8-4320-8ac9-b671-134f8fc78ae7@oracle.com> <1e291796-7751-0008-6eb3-96a1e680acd3@oracle.com> <650db381-af59-096d-15f8-908f29229c69@oracle.com> Message-ID: Hi Ivan, Sorry, one more.? The compatibility risk description should be specific about the behavior that is changing.? Something like: Since JDK5, the exception thrown for negative lengths have been unspecified and inconsistent; with this change, NegativeArraySizeException will be thrown. Thanks, Roger p.s.? A release note capturing the essence of the change is probably needed also. Add label release-note=yes to the issue and create a subtask. On 02/12/2019 11:39 AM, Ivan Gerasimov wrote: > > > On 2/12/19 7:33 AM, Roger Riggs wrote: >> Hi Ivan, >> >> The change to consistently throw NegativeSizeArrayException applies >> to StringBuilder also. >> Please mention that with the solution. >> > Right, thanks.? I updated CSR accordingly. > > With kind regards, > Ivan > >> Thanks, Roger >> >> >> On 02/11/2019 06:12 PM, Ivan Gerasimov wrote: >>> Hi Roger! >>> >>> >>> On 2/11/19 7:30 AM, Roger Riggs wrote: >>>> Hi Ivan, >>>> >>>> I called it out because the CSR does not mention that the behavior >>>> of some of the cases (-1..-16) is changing and some of the emails >>>> asserted >>>> there was no change in behavior. >>>> >>>> I'm fine with one changeset as long as both changes are explicit. >>>> The bug and the CSR should both be updated. >>>> >>> Yes, this makes sense. >>> I've updated CSR accordingly, and added a comment to the bug to make >>> the intention of the fix clear. >>> >>> Could you please review the updated CSR? >>> >>> With kind regards, >>> Ivan >>> >>> >>> >>>> Thanks, Roger >>>> >>>> >>>> On 02/08/2019 05:12 PM, Ivan Gerasimov wrote: >>>>> Hi Roger! >>>>> >>>>> That's because two tiny changes are combined in the patch: >>>>> >>>>> 1) remove a problematic statement from the javadoc, as it doesn't >>>>> hold anyway.? This part does not change the behavior. >>>>> >>>>> 2) unify type of the exception thrown for all negative values of >>>>> CharSequence.length().? The regression test is to verify this, >>>>> second change, so it fails prior the fix for length in [-16, -1]. >>>>> >>>>> I can separate them into different bugs, if you think it will make >>>>> it clearer.? Though I thought they can be fixed together. >>>>> >>>>> With kind regards, >>>>> >>>>> Ivan >>>>> >>>>> >>>>> On 2/8/19 1:49 PM, Roger Riggs wrote: >>>>>> Hi Ivan, >>>>>> >>>>>> In the direction of not changing the behavior; the webrev does >>>>>> change the behavior. >>>>>> >>>>>> In the case of CharSeqence with length -1..-16, the new behavior >>>>>> throws NegativeArrayIndexException >>>>>> instead of java.lang.IndexOutOfBoundsException. >>>>>> >>>>>> >>>>>> AbstractStringBuilder:101-102 throw an exception for length < 0. >>>>>> However, the current behavior is to create a StringBuffer with >>>>>> length + 16 and >>>>>> then append the contents.? For -1..-16, it will succeed in >>>>>> creating a StringBuffer >>>>>> but fail with IndexOutOfBoundsException during the append of the >>>>>> contents. >>>>>> >>>>>> The new Test should pass both before and after the change to the >>>>>> code. >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> On 02/07/2019 10:19 PM, Ivan Gerasimov wrote: >>>>>>> >>>>>>> >>>>>>> On 2/7/19 6:33 PM, David Holmes wrote: >>>>>>>> On 8/02/2019 11:59 am, Ivan Gerasimov wrote: >>>>>>>>> Hi David! >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/7/19 5:16 PM, David Holmes wrote: >>>>>>>>>> Hi Ivan, >>>>>>>>>> >>>>>>>>>> On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >>>>>>>>>>> Hello! >>>>>>>>>>> >>>>>>>>>>> The specification states: >>>>>>>>>>> """ >>>>>>>>>>> If the length of the specified CharSequence is less than or >>>>>>>>>>> equal to zero, then an empty buffer of capacity 16 is returned. >>>>>>>>>>> """ >>>>>>>>>>> >>>>>>>>>>> However, the current implementation throws either >>>>>>>>>>> NegativeArraySizeException or IndexOutOfBounds instead (the >>>>>>>>>>> actual exception type depends on the value of reported >>>>>>>>>>> negative length). >>>>>>>>>> >>>>>>>>>> How can you have a negative length CharSequence ?? >>>>>>>>>> >>>>>>>>> A custom CharSequence returning negative length() can be created. >>>>>>>>> Not sure how useful/popular this may be, though. >>>>>>>> >>>>>>>> Seems pretty meaningless so just treating that as an error >>>>>>>> seems fine. Though somewhat debatable whether you need to add >>>>>>>> an appropriate @throws. >>>>>>>> >>>>>>> Right.? There were two reasons not to add @throws here: >>>>>>> - by removing the problematic paragraph we just make the javadoc >>>>>>> almost the same as for StringBuilder(CharSequence), >>>>>>> - we don't seem to have any other places (at least I couldn't >>>>>>> find any) specifying exceptions due to negatively sized >>>>>>> CharSequence. >>>>>>> >>>>>>> (To be precise, there is one candidate, but I'll file a separate >>>>>>> bug to fix it.) >>>>>>> >>>>>>>>> That's why I propose just removing the mentioning negative >>>>>>>>> length, and not changing the behavior. >>>>>>>>> >>>>>>>>> The proposed code change is to only unify the behavior for any >>>>>>>>> negative value of length. >>>>>>>> >>>>>>>> Ok. >>>>>>>> >>>>>>>>>> If its an empty CharSequence then it should return the empty >>>>>>>>>> buffer as indicated. >>>>>>>>>> >>>>>>>>> Empty CharSequence is processed correctly already. >>>>>>>> >>>>>>>> Okay so by removing this part: >>>>>>>> >>>>>>>> -????? *

>>>>>>>> -????? * If the length of the specified {@code CharSequence} is >>>>>>>> -????? * less than or equal to zero, then an empty buffer of >>>>>>>> capacity >>>>>>>> -????? * {@code 16} is returned. >>>>>>>> >>>>>>>> you're relying on the main specification to implicitly handle >>>>>>>> the empty case. >>>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>> With kind regards, >>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> With kind regards, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> It is proposed to do two things: >>>>>>>>>>> 1) remove the problematic sentence from the javadoc (CSR is >>>>>>>>>>> filed). >>>>>>>>>>> 2) unify the exception type thrown, if the argument reports >>>>>>>>>>> negative length. >>>>>>>>>>> NegativeArraySizeException will be consistent with, for >>>>>>>>>>> example, StringBuffer(negativeCapacity). >>>>>>>>>>> >>>>>>>>>>> Would you please help review the fix? >>>>>>>>>>> >>>>>>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >>>>>>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >>>>>>>>>>> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From philipp.kunz at paratix.ch Tue Feb 12 17:05:59 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Tue, 12 Feb 2019 18:05:59 +0100 Subject: Missing Blank Line Suspected in jar.html Message-ID: <1549991159.2497.1.camel@paratix.ch> Hi, https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#per-entry-att ributes shows an example manifest ????Manifest-Version: 1.0 ????Created-By: 1.8 (Oracle Inc.) ????Sealed: true ????Name: foo/bar/ ????Sealed: false with the explanation It means that all the packages archived in a.jar are sealed, except that package foo.bar is not. However, this is not a valid manifest because the same page also states Attribute names cannot be repeated within a section. which I guess also should apply to main attributes and The main section [...]. No attribute in this section can have its name equal to "Name". Long story short, I guess a blank line is missing before line 4 of that example manifest between "Sealed: true" and "Name: foo/bar/". There are example manifests further down at the end of section https:// docs.oracle.com/javase/10/docs/specs/jar/jar.html#signature-validation with such blank lines. It would look then like this: ????Manifest-Version: 1.0 ????Created-By: 1.8 (Oracle Inc.) ????Sealed: true ????Name: foo/bar/ ????Sealed: false I haven't found the sources of that referenced jar.html and therefore I'm not sure whether my concern still currently applies or has been fixed since JDK 10. Regards, Philipp From mandy.chung at oracle.com Tue Feb 12 18:31:44 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 12 Feb 2019 10:31:44 -0800 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> Message-ID: On 2/8/19 11:46 AM, Roger Riggs wrote: > Hi, > > A few higher level issues should be considered, though the details > of the webrev captured my immediate attention. > > Is this the right feature and is this the right level of implementation > (C++/native)? > : > How much of this can be done in Java code with StackWalker and other > java APIs? > It would be a shame to add this much native code if there was a more robust > way to implement it using APIs with more leverage. Improving the NPE message for better diagnosability is helpful while I share the same concern Roger raised. Implementing this feature in Java and the library would be a better choice as this isn't absolutely required to be done in VM in native. NPE keeps a backtrace capturing the method id and bci of each stack frame. One option to explore is to have StackWalker to accept a Throwable object that returns a stream of StackFrame which allows you to get the method and BCI and also code source (I started a prototype for JDK-8189752 some time ago). It can use the bytecode library e.g. ASM to read the bytecode. For NPE message, you can implement a specialized StackFrameTraverser just for building an exception message purpose. Mandy From ecki at zusammenkunft.net Tue Feb 12 19:44:45 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 12 Feb 2019 19:44:45 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> , <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> Message-ID: For security reasons I would add it to `jdk.includeInExceptions`, but maybe as a default? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Roger Riggs Gesendet: Dienstag, Februar 12, 2019 8:07 PM An: Lindenmaier, Goetz; Java Core Libs Cc: hotspot-runtime-dev at openjdk.java.net Betreff: Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. Hi, On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote: > Hi Roger, > > thanks for looking at my change! > >> A few higher level issues should be considered, though the details of >> the webrev captured my immediate attention. >> >> Is this the right feature > Yes!! Maybe, that's what debuggers are for. > >> and is this the right level of implementation (C++/native)? > See below. Maybe 10 years ago, when native was the only solution. Now there are tools to analyze bytecode in java. > >> From a security perspective, adding field names to exceptions exposes >> information to callers that they could not otherwise get and that breaks >> encapsulation. >> That needs to be evaluated. > I can not comment on that. How can I trigger an evaluation of this? > Who needs to evaluate this? > >> I think there are ways to make this easier to implement and be easier to >> maintain and perform better. >> >> NullPointerException: >> 28: unused import of Field > Removed > >> 64: The lazyComputeMessage boolean should be inverted so it does not >> require >> initialization, false is the default, anything else adds overhead. >> And it may not be needed. > Peter Levart proposed to initialize the message with a sentinel instead. > I'll implement this as a proposal. That's an extra overhead too, any assignment is. > >> 91: Why do you think synchonization is necessary? It is a performance hit. >> It is highly unlikely to be called from multiple threads and the >> value will >> be the same whether it is computed once or multiple times by >> different threads. > I guess we can go without. > It would be possible to construct a case where two threads > do getMessage() on the same NPE Object but the string is not > the same. Really!, if the bci is the same, the bytecode is the same, what could be different that would change the data used to create the exception? > >> 99: extendedMessage will never be null (so says the javadoc of >> getExtendedNPEMessage) >> Bug: If it does return null, then null is returned from getMessage >> regardless of the value of super.getMessage(). > Fixed. > >> 121: Simplify getExtendedNPEMessage by making it only responsible for >> the detail >> and not concatenation with an existing message. Put that in >> getMessage(). > Fixed. You are right, I only call this when the message is NULL. > >> Its not strictly necessary to change the updated message with >> setMessage(). >> Avoiding that will avoid complexity and a performance hit. >> The message will be computed each time it is needed, and that happens >> infrequently. >> (Even in the serialization case, it will be re-computed from the >> attached stack frames). > No, you can not recompute it from the stacktrace because that > does not contain the BCI. Also, after deserialization, the bytecode > might look different or not available at all. It depends on the actual > bytecode that has been running when the exception was thrown. Right, I realized this too when thinking about it over the weekend. If a suitable low impact mechanism can't be found, then just go back to not exposing the extended message and use only the original. Its a bad idea to twist and contort the local design and accessibility just for serialization. What remote or delayed client needs to know this? > >> And it avoids adding setMessage() to Throwable, that's significant >> change since >> the current implementation only allows the message to be initialized >> not updated. >> Immutable is an important characteristic to maintain. > Yes, I don't like I have to set this. But it follows the same pattern > as with the stack trace which is only computed on demand. Thus, > Throwable is not immutable anyways. Before, I implemented this by a > JNI call hiding this in the Java code. > I proposed implementing setting the field by reflection, Christoph > proposed a shared secret. David favored the package private setter. > Please advice what is best. All of them are bad. Private needs to mean private. And making it mutable, also means that synchronization or volatile is needed to ensure a consistent value for getMessage(). That turns into a performance issue for all throwables. None of the above. > >> That makes the writeReplace() unnecessary too. > No. I need this, see above. See above, but is not essential to the core feature. > >> Additional command line arguments are an unnecessary complexity, >> documentation, and maintenance overhead. If the feature is as valuable as >> you suggest, it should be enabled all the time. > Removed. > >> I'm assuming there are no tests broken by the modification of the message. >> It is likely that somewhere an application or test looks at the message >> itself. >> Has that been verified? > Our nightly testing runs the headless jdk and hostspot jtreg tests, jck tests and some > other applications. They are all unaffected by this change after adapting the > message in jtreg/vmTestbase/jit/t/t104/t104.gold. > (win-x86_64, linux: ppc64, ppc64le, s390, x86_64, aarch, aix, solaris-sparc, mac) > Also, I modified quite some messages before which didn't cause any follow-up > breakages to my knowledge. It does seem unlikely. > >> I can't speak for the hotspot code, but that seems to add a lot of code >> to support >> only this convenience feature. That's a maintenance overhead and burden. > We uses this code since 2006, it needed only few changes. I would like to > contribute a follow up for hidden frames of lambdas. Valhalla and evolution of the byte code needs to be considered. Just because its worked for years does not mean its the best approach today. Dropping it in now means maintaining it in its current form or needing to re-write it later. > >> The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a >> question >> about how useful the information is, developers should not need to know >> about "slot 1". > Developers should work with class files with debug information and then > they would get the name printed. If exceptions are thrown in production > code, any information is helpful. Should I just write "a local"? Go back to who you think is going to benefit from it, it seems targeted at a fairly novice developer, so exposing low level details may be more confusing that just giving a line number and NPE. > >> The test output of NullPointerExceptionTest shows >> "java.lang.Object.hashCode(()I)". >> Why is the argument type for Integer shown as "()I"; that's not the >> conventional >> representation of a primitive int. > I already discussed this with David Holmes: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058464.html > Other exceptions use the same format. I don't know of an utility in > hotspot to translate the format to Java source code syntax. We > implemented such an utility in our internal VM, though, and I would > like to contribute this, too, adapting all the exceptions. I would do this > in a follow-up. There may be better tools for formatting if it was done in java at a more appropriate level of abstraction. > >> Generally, the explanations are too verbose. >> Method names and field names would be easier to recognize if they were >> quoted, as is done with 'this'. > Fixed, although this is not common in exception messages. See the > messages in http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, > line 57ff. Only the String of the name field is quoted, not any entities > declared in the code. > Similar http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runtime/LoaderConstraints/vtableAME/Test.java > line 60, also showing the internal signature, see above. > >> Argument numbers should be digits, >> not English words (first, second, etc) to make them easier to pick out. > Fixed. >> And has it limits that do not read easily, e.g. "nr. 9". > Sorry, I don't understand src/hotspot/share/classfile/bytecodeUtils.cpp:566 test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerExceptionTest.java:612 >> I would not describe 'this' as a local variable. > Fixed. > >> Tests, especially new tests should compile without warnings. >> NullPointerExceptionTest.java:125 newInstance has been deprecated. > Fixed. > >> The messages can be easier to understand, e.g. >> 'field a1 is null, trying to invoke a1.hashCode...' instead of: >> "while trying to invoke the method java.lang.Object.hashCode(()I) on a >> null reference loaded from local variable 'a1'" > The message is built along the structure of the bytecode. > I'll try to change this and then will come up with a new webrev . > >> It will easier to understand if it looks more like the code. >> BTW, what does this look like for fully optimized code? > You mean whether the bytecode is jitted? It's independent > of how the code is executed, interpreted or compiled. > >> Does it bear any resemblance to the source code at all? >> Or does it have to be deoptimized to come up with a sensible source >> reference. > No, jitted methods must not be deoptimized. > >> How much of this can be done in Java code with StackWalker and other >> java APIs? >> It would be a shame to add this much native code if there was a more robust >> way to implement it using APIs with more leverage. > StackWalker operates on the Java stack tracke, which does not contain the BCI > to my knowledge. Also, I need to read the bytecodes. Are there APIs to access > the bytecode as it resides in the metaspace, rewritten, constants resolved etc? > The code relies on this. From the other thread, beware adding overhead to the constructor. The lazy computation is essential. There are a *lot* of NPEs whose messages will never be needed. Regards, Roger > > Best regards, > Goetz. > > > >> Regards, Roger >> >> >> On 02/08/2019 09:13 AM, Langer, Christoph wrote: >>> Hi Goetz, >>> >>>> ok, so here a new webrev just adding a setter for the field: >>>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 >>>> >>>> ... and incorporating the other comments. >>> Looks better ?? >>> >>> I have a few additions to >> src/java.base/share/classes/java/lang/NullPointerException.java: >>> 28 import java.lang.reflect.Field; >>> 29 >>> -> can be removed now. >>> >>> 91 synchronized (this) { >>> -> I think this is not needed here. The transient modifier for >> lazyComputeMessage already implies the lock on the Object, I think. >>> 108 return extendedMessage; >>> -> I guess it would be more correct if you returned super.getMessage() here. >>> >>> Thanks >>> Christoph From christoph.langer at sap.com Tue Feb 12 21:57:23 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 12 Feb 2019 21:57:23 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> Message-ID: <3aeba9a64a434a968fc1d82a44077745@sap.com> Hi Alan, all, here comes the next proposal for POSIX support in jdk.zipfs - which hopefully represents the converged solution, at least in its overall design. http://cr.openjdk.java.net/~clanger/webrevs/8213031.6/ With that patch, the behavior is the following: a) A ZipFileSystem instance by default does NOT support the PosixFileAttributeView. However, it is possible to query for a known attribute named "zip:storedPermissions". Its value can be null to represent no permission information or any set of PosixFileAttribute. b) A ZipFileSystem instance can be created with the property "posix"=true. In that case, PosixFileAttributeView is supported with default values. -> owner: A UserPrincipal with the name of System.getProperty("user.name") if property access is allowed, "" otherwise -> group: A GroupPrincipal with the name "". -> permissions: Set.of(OWNER_READ, OWNER_WRITE, GROUP_READ) The default values can be modified by using the properties "defaultOwner", "defaultGroup" and "defaultPermissions". Implementation wise the ZipFileAttributeView always extends PosixFileAttributeView but behaves different, depending on how it was obtained. Within ZipFileSystem, the Entry inner class is not static any more but always has a reference to the Enclosing ZipFileSystem. That's needed because default owner/group/permission can be set on ZipFileSystem instance level now and the Entry, implementing the FileAttributes needs to know where it belongs to. This seems somewhat logical anyway. The new test "TestPosix" is quite extensive. I had to add 2 permissions to test.policy to allow testing in a restricted environment. Module-info and CSR have been adopted, too. Thanks in advance for reviewing. Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 21. Januar 2019 10:17 > To: 'Alan Bateman' > Cc: nio-dev ; OpenJDK Dev list dev at openjdk.java.net>; Java Core Libs ; > Volker Simonis > Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions > > Hi Alan, > > first of all, thank you for your input on this. > > > I think the approach to explore are: > > > > 1. zipfs supports PosixFileAttributeView without subsetting. If > > readAttribute(file, BasicFileAttributes.class) succeeds then > > readAttribute(file, PosixFileAttributes.class) should also succeed, even > > if there aren't permissions encoded in the zip entry's external file > > attributes. It would mean that owner and group return default values, > > and permissions may return a default value. It does mean you can't > > distinguish the default value from "no permissions" but there is > > precedence for that, e.g. mount a FAT32 file system on Linux or Unix > > systems and `stat` a file to have the stat structure populated with > > default uid, gid and mode bits. > > OK, I can see the point that in a PosixFileAttributeView as it is, there's no > place for optionality/null values. However, with this approach the benefits > would be that Files::get/setPosixPermissions would work and that's why I > think we should pursue this. The challenge will be to find reasonable > defaults. > > > 2. zipfs defines a new FileAttributeView that defines read and write > > access to permissions stored in a zip entry's external file attribute. > > As it's a new view then it can define the behavior for the case that the > > zip entry doesn't have permissions. Furthermore it does not need to > > extend BasicFileAttributeView so doesn't need to be concerned with bulk > > access, nor concerned with group/owner. As you know, the attributes API > > allows for both type safe and dynamic access so you have a choice as to > > whether to support both or just dynamic access. With the first then > > jdk.zipfs would export a package with a public interface that defines > > the view. If someone wants type safe access to the permissions attribute > > then you need to import the class. The alternative is to not export any > > packages but just define the view in the module-info. The view its name > > and define the name/type of the permissions attribute, it will also > > define how it behaves when the external attributes aren't populated. In > > usage terms it means reading the permissions will be something like > > Files.readAttribute(file, "zip:permissions") and casting the value to > > Set - not pretty but it avoids depending on a > > JDK-specific API. > > For this approach, there are 2 things I dislike. The first is that I don't think we > should export named packages from module jdk.zipfs that people would > develop Java code against while not being in the Java API. And secondly, this > way would not support using Files::set/getPosixPermissions since the > specification/implementation of that utility method explicitly refers to > PosixFileAttributeView. > > I can imagine something like this: > Zipfs by default implements an own view that offers dynamic, not type safe > access to "zip:permissions" and we'll document this. If a user of zipfs wants > to see full PosixFileAttributeView support with default values, then we > should allow for a creation attribute for the zipfs that can control this. Maybe > we can even allow specifying default values for user, group and permissions > via zipfs attributes. > > I'll work to develop the patch into this direction unless you tell me that this > idea is bogus (if so, then I hope it be soon ??) > > Thanks > Christoph > > From brent.christian at oracle.com Tue Feb 12 23:48:21 2019 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 12 Feb 2019 15:48:21 -0800 Subject: Missing Blank Line Suspected in jar.html In-Reply-To: <1549991159.2497.1.camel@paratix.ch> References: <1549991159.2497.1.camel@paratix.ch> Message-ID: Hi, Philipp Yes, I agree it would make sense to add a newline in the example Manifest, as you suggest. I can look into changing it. Thanks, -Brent On 2/12/19 9:05 AM, Philipp Kunz wrote: > Hi, > > https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#per-entry-att > ributes > > shows an example manifest > > ????Manifest-Version: 1.0 > ????Created-By: 1.8 (Oracle Inc.) > ????Sealed: true > ????Name: foo/bar/ > ????Sealed: false > > with the explanation > > It means that all the packages archived in a.jar are sealed, except > that package foo.bar is not. > > However, this is not a valid manifest because the same page also states > > Attribute names cannot be repeated within a section. > > which I guess also should apply to main attributes and > > The main section [...]. No attribute in this section can have its > name equal to "Name". > > > > Long story short, I guess a blank line is missing before line 4 of that > example manifest between "Sealed: true" and "Name: foo/bar/". > There are example manifests further down at the end of section https:// > docs.oracle.com/javase/10/docs/specs/jar/jar.html#signature-validation > with such blank lines. It would look then like this: > > ????Manifest-Version: 1.0 > ????Created-By: 1.8 (Oracle Inc.) > ????Sealed: > true > > ????Name: foo/bar/ > ????Sealed: false > > > > I haven't found the sources of that referenced jar.html and therefore > I'm not sure whether my concern still currently applies or has been > fixed since JDK 10. > > Regards, > Philipp > From ivan.gerasimov at oracle.com Wed Feb 13 01:21:16 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 12 Feb 2019 17:21:16 -0800 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> <07bbc6e7-0656-0efa-0f24-987aeb43e9cc@oracle.com> <445d726b-5a45-b43f-3aea-452fbfc10124@oracle.com> <141ec0dc-beba-6ae3-1dc2-21f7f77bcb9b@oracle.com> <28ea7fd8-4320-8ac9-b671-134f8fc78ae7@oracle.com> <1e291796-7751-0008-6eb3-96a1e680acd3@oracle.com> <650db381-af59-096d-15f8-908f29229c69@oracle.com> Message-ID: <810e5d0c-d585-c3eb-6b3d-8ed627f87eab@oracle.com> Uh, lots of paperwork, comparing to the actual change in the source code :-) Anyways, I updated the CSR as you suggested, and created a release note subtask: https://bugs.openjdk.java.net/browse/JDK-8218884 Could you please review it? With kind regards, Ivan On 2/12/19 8:51 AM, Roger Riggs wrote: > Hi Ivan, > > Sorry, one more. The compatibility risk description should be > specific about > the behavior that is changing. Something like: > > Since JDK5, the exception thrown for negative lengths have been > unspecified > and inconsistent; with this change, NegativeArraySizeException will be > thrown. > > Thanks, Roger > > p.s. A release note capturing the essence of the change is probably > needed also. > Add label release-note=yes to the issue and create a subtask. > > > On 02/12/2019 11:39 AM, Ivan Gerasimov wrote: >> >> >> On 2/12/19 7:33 AM, Roger Riggs wrote: >>> Hi Ivan, >>> >>> The change to consistently throw NegativeSizeArrayException applies >>> to StringBuilder also. >>> Please mention that with the solution. >>> >> Right, thanks. I updated CSR accordingly. >> >> With kind regards, >> Ivan >> >>> Thanks, Roger >>> >>> >>> On 02/11/2019 06:12 PM, Ivan Gerasimov wrote: >>>> Hi Roger! >>>> >>>> >>>> On 2/11/19 7:30 AM, Roger Riggs wrote: >>>>> Hi Ivan, >>>>> >>>>> I called it out because the CSR does not mention that the behavior >>>>> of some of the cases (-1..-16) is changing and some of the emails >>>>> asserted >>>>> there was no change in behavior. >>>>> >>>>> I'm fine with one changeset as long as both changes are explicit. >>>>> The bug and the CSR should both be updated. >>>>> >>>> Yes, this makes sense. >>>> I've updated CSR accordingly, and added a comment to the bug to >>>> make the intention of the fix clear. >>>> >>>> Could you please review the updated CSR? >>>> >>>> With kind regards, >>>> Ivan >>>> >>>> >>>> >>>>> Thanks, Roger >>>>> >>>>> >>>>> On 02/08/2019 05:12 PM, Ivan Gerasimov wrote: >>>>>> Hi Roger! >>>>>> >>>>>> That's because two tiny changes are combined in the patch: >>>>>> >>>>>> 1) remove a problematic statement from the javadoc, as it doesn't >>>>>> hold anyway. This part does not change the behavior. >>>>>> >>>>>> 2) unify type of the exception thrown for all negative values of >>>>>> CharSequence.length(). The regression test is to verify this, >>>>>> second change, so it fails prior the fix for length in [-16, -1]. >>>>>> >>>>>> I can separate them into different bugs, if you think it will >>>>>> make it clearer. Though I thought they can be fixed together. >>>>>> >>>>>> With kind regards, >>>>>> >>>>>> Ivan >>>>>> >>>>>> >>>>>> On 2/8/19 1:49 PM, Roger Riggs wrote: >>>>>>> Hi Ivan, >>>>>>> >>>>>>> In the direction of not changing the behavior; the webrev does >>>>>>> change the behavior. >>>>>>> >>>>>>> In the case of CharSeqence with length -1..-16, the new behavior >>>>>>> throws NegativeArrayIndexException >>>>>>> instead of java.lang.IndexOutOfBoundsException. >>>>>>> >>>>>>> >>>>>>> AbstractStringBuilder:101-102 throw an exception for length < 0. >>>>>>> However, the current behavior is to create a StringBuffer with >>>>>>> length + 16 and >>>>>>> then append the contents. For -1..-16, it will succeed in >>>>>>> creating a StringBuffer >>>>>>> but fail with IndexOutOfBoundsException during the append of the >>>>>>> contents. >>>>>>> >>>>>>> The new Test should pass both before and after the change to the >>>>>>> code. >>>>>>> >>>>>>> Roger >>>>>>> >>>>>>> >>>>>>> On 02/07/2019 10:19 PM, Ivan Gerasimov wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2/7/19 6:33 PM, David Holmes wrote: >>>>>>>>> On 8/02/2019 11:59 am, Ivan Gerasimov wrote: >>>>>>>>>> Hi David! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/7/19 5:16 PM, David Holmes wrote: >>>>>>>>>>> Hi Ivan, >>>>>>>>>>> >>>>>>>>>>> On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >>>>>>>>>>>> Hello! >>>>>>>>>>>> >>>>>>>>>>>> The specification states: >>>>>>>>>>>> """ >>>>>>>>>>>> If the length of the specified CharSequence is less than or >>>>>>>>>>>> equal to zero, then an empty buffer of capacity 16 is >>>>>>>>>>>> returned. >>>>>>>>>>>> """ >>>>>>>>>>>> >>>>>>>>>>>> However, the current implementation throws either >>>>>>>>>>>> NegativeArraySizeException or IndexOutOfBounds instead (the >>>>>>>>>>>> actual exception type depends on the value of reported >>>>>>>>>>>> negative length). >>>>>>>>>>> >>>>>>>>>>> How can you have a negative length CharSequence ?? >>>>>>>>>>> >>>>>>>>>> A custom CharSequence returning negative length() can be >>>>>>>>>> created. >>>>>>>>>> Not sure how useful/popular this may be, though. >>>>>>>>> >>>>>>>>> Seems pretty meaningless so just treating that as an error >>>>>>>>> seems fine. Though somewhat debatable whether you need to add >>>>>>>>> an appropriate @throws. >>>>>>>>> >>>>>>>> Right. There were two reasons not to add @throws here: >>>>>>>> - by removing the problematic paragraph we just make the >>>>>>>> javadoc almost the same as for StringBuilder(CharSequence), >>>>>>>> - we don't seem to have any other places (at least I couldn't >>>>>>>> find any) specifying exceptions due to negatively sized >>>>>>>> CharSequence. >>>>>>>> >>>>>>>> (To be precise, there is one candidate, but I'll file a >>>>>>>> separate bug to fix it.) >>>>>>>> >>>>>>>>>> That's why I propose just removing the mentioning negative >>>>>>>>>> length, and not changing the behavior. >>>>>>>>>> >>>>>>>>>> The proposed code change is to only unify the behavior for >>>>>>>>>> any negative value of length. >>>>>>>>> >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>>>> If its an empty CharSequence then it should return the empty >>>>>>>>>>> buffer as indicated. >>>>>>>>>>> >>>>>>>>>> Empty CharSequence is processed correctly already. >>>>>>>>> >>>>>>>>> Okay so by removing this part: >>>>>>>>> >>>>>>>>> - *

>>>>>>>>> - * If the length of the specified {@code CharSequence} is >>>>>>>>> - * less than or equal to zero, then an empty buffer of >>>>>>>>> capacity >>>>>>>>> - * {@code 16} is returned. >>>>>>>>> >>>>>>>>> you're relying on the main specification to implicitly handle >>>>>>>>> the empty case. >>>>>>>>> >>>>>>>> Yes. >>>>>>>> >>>>>>>> With kind regards, >>>>>>>> Ivan >>>>>>>> >>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> With kind regards, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> It is proposed to do two things: >>>>>>>>>>>> 1) remove the problematic sentence from the javadoc (CSR is >>>>>>>>>>>> filed). >>>>>>>>>>>> 2) unify the exception type thrown, if the argument reports >>>>>>>>>>>> negative length. >>>>>>>>>>>> NegativeArraySizeException will be consistent with, for >>>>>>>>>>>> example, StringBuffer(negativeCapacity). >>>>>>>>>>>> >>>>>>>>>>>> Would you please help review the fix? >>>>>>>>>>>> >>>>>>>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >>>>>>>>>>>> WEBREV: >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >>>>>>>>>>>> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- With kind regards, Ivan Gerasimov From sean.mullan at oracle.com Tue Feb 12 18:25:44 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 12 Feb 2019 13:25:44 -0500 Subject: Java SSLSocketChannel/SSLSelector? In-Reply-To: References: Message-ID: Hi Andi, TLS/JSSE topics are best discussed on the security-dev alias, so I am copying that list for more discussion and -bcc-ing core-libs-dev. --Sean On 2/11/19 3:29 PM, Andi Mullaraj wrote: > Hi java-core community, > > I have been directed to this channel to discuss matters related to Java > performant ssl communications. Maybe this is a topic that has been > discussed in the past, in which case I would appreciate if someone pointed > me to that particular topic. > > Back in 2002 I personally applauded the java.nio.channels (jdk1.4) package, > realizing that there was no way to port this to the secure communications, > due to lack of a comparable implementation for SSL. But I thought it was > going to just be matter of time. A couple of years ago I had to go back > search for it, and was kind of surprised to find the following in > http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG > : > > --- begin quote --- > Newcomers to the API may wonder "Why not just have an SSLSocketChannel > which extends java.nio.channels.SocketChannel?" There are two main reasons: > > 1. There were a lot of very difficult questions about what a > SSLSocketChannel should be, including its class hierarchy and how it should > interoperate with Selectors and other types of SocketChannels. Each > proposal brought up more questions than answers. It was noted that any new > API abstraction extended to work with SSL/TLS would require the same > significant analysis and could result in large and complex APIs. > 2. Any JSSE implementation of a new API would be free to choose the "best" > I/O & compute strategy, but hiding any of these details is inappropriate > for those applications needing full control. Any specific implementation > would be inappropriate for some application segment. > --- end quote --- > > It has been a while since this was stated, and I would really like to > revisit it. I personally believe that the question #1 has a quite natural > answer, while #2 should not really be a concern if we adhere to the spi > model where users can bring their own implementation if needed. I know > because I have also implemented it (but would like to discuss that in a > later stage, if it comes to it). > > The benefit of such implementation would be immense. Imagine many Java > services written with nio and which struggle to move to SSL due to the > great complexity of using SSLEngine (zookeeper service to name one), while > all they would need to do (if SSLSocketChannels were available) is to > instantiate an instance of SSLSocketChannel/SSLSelector when the security > is required and the rest would stay the same (as in case of plain > communication using SocketChannel/Selector). Another important use case is > the advent of IOT, where millions of devices, with relatively low > throughput would want to protect their communication via SSL. > > The ways I have seen the community deal with this are mainly: > > 1. Go through the pain of learning SSLEngine (and hope to get it right) > 2. Build their services around tested libraries (like Jetty, which handle > the SSL offload but don't resurface it in SocketChannel/Selector paradigm, > that also come with their huge set of dependencies, bringing in unavoidable > version collisions) > 3. Use proxies (nginx, ha) to deal with the high number of SSL connections > and divide the load by scaling horizontally in the back end (making for a > harder deployment model) > > We can make this a lot easier! > > Any feedback is greatly appreciated, > Best, > > Andi Mullaraj > From tornaiandrasede at gmail.com Tue Feb 12 15:11:03 2019 From: tornaiandrasede at gmail.com (=?UTF-8?Q?Tornai_Andr=C3=A1s?=) Date: Tue, 12 Feb 2019 16:11:03 +0100 Subject: RFR: JDK-8200758 JEP 343: Packaging Tool Message-ID: Hi all, jpackage* does not have an option to specify the classpath anymore while javapackager** has this feature. jpackage just collects all the .jar files from --input directory and puts them on classpath***. I would like to add some extra .jar files to my application/package but I do not want them on classpath - with jpackage this seems to be impossible. Have I overlook something? Would it be possible to improve jpackage with this? Many thanks, Andr?s * https://bugs.openjdk.java.net/browse/JDK-8200758 ** https://docs.oracle.com/javase/10/tools/javapackager.htm#JSWOR719 under "General Bundler Arguments" *** https://hg.openjdk.java.net/jdk/sandbox/file/225a4ac5bd57/src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java#l270 From goetz.lindenmaier at sap.com Wed Feb 13 09:09:15 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 13 Feb 2019 09:09:15 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> Message-ID: <3245ec3cefe2471e8382048164c0ba6b@sap.com> Hi Mandy, Thanks for supporting my intend of adding the message as such! I'll start implementing this in Java and come back with a webrev in a while. In parallel, I would like to continue discussing the other topics, e.g., the wording of the message. I will probably come up with a separate webrev for that. Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf > Of Mandy Chung > Sent: Tuesday, February 12, 2019 7:32 PM > To: Roger Riggs > Cc: Java Core Libs ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > On 2/8/19 11:46 AM, Roger Riggs wrote: > > Hi, > > > > A few higher level issues should be considered, though the details > > of the webrev captured my immediate attention. > > > > Is this the right feature and is this the right level of implementation > > (C++/native)? > > : > > How much of this can be done in Java code with StackWalker and other > > java APIs? > > It would be a shame to add this much native code if there was a more > robust > > way to implement it using APIs with more leverage. > > Improving the NPE message for better diagnosability is helpful while > I share the same concern Roger raised. > > Implementing this feature in Java and the library would be a better > choice as this isn't absolutely required to be done in VM in native. > > NPE keeps a backtrace capturing the method id and bci of each stack > frame. One option to explore is to have StackWalker to accept a > Throwable object that returns a stream of StackFrame which allows > you to get the method and BCI and also code source (I started a > prototype for JDK-8189752 some time ago). It can use the bytecode > library e.g. ASM to read the bytecode. For NPE message, you can > implement a specialized StackFrameTraverser just for building > an exception message purpose. > > Mandy From goetz.lindenmaier at sap.com Wed Feb 13 09:14:59 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 13 Feb 2019 09:14:59 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> , <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> Message-ID: Hi Bernd, I think this is a feasible idea, while I'm not sure whether this is really critical information. The stack trace already contains the names of Classes, Inner classes etc.. Field names should be not that more sensible information I guess, if at all. > but maybe as a default? You mean to enable it per default? Yes. Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf > Of Bernd Eckenfels > Sent: Tuesday, February 12, 2019 8:45 PM > To: Java Core Libs > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > For security reasons I would add it to `jdk.includeInExceptions`, but maybe as > a default? > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > ________________________________ > Von: core-libs-dev im Auftrag > von Roger Riggs > Gesendet: Dienstag, Februar 12, 2019 8:07 PM > An: Lindenmaier, Goetz; Java Core Libs > Cc: hotspot-runtime-dev at openjdk.java.net > Betreff: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > Hi, > > On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote: > > Hi Roger, > > > > thanks for looking at my change! > > > >> A few higher level issues should be considered, though the details of > >> the webrev captured my immediate attention. > >> > >> Is this the right feature > > Yes!! > Maybe, that's what debuggers are for. > > > >> and is this the right level of implementation (C++/native)? > > See below. > Maybe 10 years ago, when native was the only solution. > Now there are tools to analyze bytecode in java. > > > >> From a security perspective, adding field names to exceptions exposes > >> information to callers that they could not otherwise get and that breaks > >> encapsulation. > >> That needs to be evaluated. > > I can not comment on that. How can I trigger an evaluation of this? > > Who needs to evaluate this? > > > >> I think there are ways to make this easier to implement and be easier to > >> maintain and perform better. > >> > >> NullPointerException: > >> 28: unused import of Field > > Removed > > > >> 64: The lazyComputeMessage boolean should be inverted so it does not > >> require > >> initialization, false is the default, anything else adds overhead. > >> And it may not be needed. > > Peter Levart proposed to initialize the message with a sentinel instead. > > I'll implement this as a proposal. > That's an extra overhead too, any assignment is. > > > >> 91: Why do you think synchonization is necessary? It is a performance hit. > >> It is highly unlikely to be called from multiple threads and the > >> value will > >> be the same whether it is computed once or multiple times by > >> different threads. > > I guess we can go without. > > It would be possible to construct a case where two threads > > do getMessage() on the same NPE Object but the string is not > > the same. > Really!, if the bci is the same, the bytecode is the same, what could be > different > that would change the data used to create the exception? > > > >> 99: extendedMessage will never be null (so says the javadoc of > >> getExtendedNPEMessage) > >> Bug: If it does return null, then null is returned from getMessage > >> regardless of the value of super.getMessage(). > > Fixed. > > > >> 121: Simplify getExtendedNPEMessage by making it only responsible for > >> the detail > >> and not concatenation with an existing message. Put that in > >> getMessage(). > > Fixed. You are right, I only call this when the message is NULL. > > > >> Its not strictly necessary to change the updated message with > >> setMessage(). > >> Avoiding that will avoid complexity and a performance hit. > >> The message will be computed each time it is needed, and that happens > >> infrequently. > >> (Even in the serialization case, it will be re-computed from the > >> attached stack frames). > > No, you can not recompute it from the stacktrace because that > > does not contain the BCI. Also, after deserialization, the bytecode > > might look different or not available at all. It depends on the actual > > bytecode that has been running when the exception was thrown. > Right, I realized this too when thinking about it over the weekend. > > If a suitable low impact mechanism can't be found, then just > go back to not exposing the extended message and use only the original. > Its a bad idea to twist and contort the local design and accessibility > just for serialization. What remote or delayed client needs to know this? > > > > >> And it avoids adding setMessage() to Throwable, that's significant > >> change since > >> the current implementation only allows the message to be initialized > >> not updated. > >> Immutable is an important characteristic to maintain. > > Yes, I don't like I have to set this. But it follows the same pattern > > as with the stack trace which is only computed on demand. Thus, > > Throwable is not immutable anyways. Before, I implemented this by a > > JNI call hiding this in the Java code. > > I proposed implementing setting the field by reflection, Christoph > > proposed a shared secret. David favored the package private setter. > > Please advice what is best. > All of them are bad. Private needs to mean private. > > And making it mutable, also means that synchronization or volatile > is needed to ensure a consistent value for getMessage(). > That turns into a performance issue for all throwables. > None of the above. > > > >> That makes the writeReplace() unnecessary too. > > No. I need this, see above. > See above, but is not essential to the core feature. > > > >> Additional command line arguments are an unnecessary complexity, > >> documentation, and maintenance overhead. If the feature is as valuable > as > >> you suggest, it should be enabled all the time. > > Removed. > > > >> I'm assuming there are no tests broken by the modification of the > message. > >> It is likely that somewhere an application or test looks at the message > >> itself. > >> Has that been verified? > > Our nightly testing runs the headless jdk and hostspot jtreg tests, jck tests > and some > > other applications. They are all unaffected by this change after adapting the > > message in jtreg/vmTestbase/jit/t/t104/t104.gold. > > (win-x86_64, linux: ppc64, ppc64le, s390, x86_64, aarch, aix, solaris-sparc, > mac) > > Also, I modified quite some messages before which didn't cause any > follow-up > > breakages to my knowledge. > It does seem unlikely. > > > >> I can't speak for the hotspot code, but that seems to add a lot of code > >> to support > >> only this convenience feature. That's a maintenance overhead and > burden. > > We uses this code since 2006, it needed only few changes. I would like to > > contribute a follow up for hidden frames of lambdas. > Valhalla and evolution of the byte code needs to be considered. > Just because its worked for years does not mean its the best approach > today. Dropping it in now means maintaining it in its current form > or needing to re-write it later. > > > >> The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a > >> question > >> about how useful the information is, developers should not need to > know > >> about "slot 1". > > Developers should work with class files with debug information and then > > they would get the name printed. If exceptions are thrown in production > > code, any information is helpful. Should I just write "a local"? > Go back to who you think is going to benefit from it, it seems targeted > at a fairly novice developer, so exposing low level details may be more > confusing that just giving a line number and NPE. > > > >> The test output of NullPointerExceptionTest shows > >> "java.lang.Object.hashCode(()I)". > >> Why is the argument type for Integer shown as "()I"; that's not the > >> conventional > >> representation of a primitive int. > > I already discussed this with David Holmes: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019- > February/058464.html > > Other exceptions use the same format. I don't know of an utility in > > hotspot to translate the format to Java source code syntax. We > > implemented such an utility in our internal VM, though, and I would > > like to contribute this, too, adapting all the exceptions. I would do this > > in a follow-up. > There may be better tools for formatting if it was done in java at a > more appropriate level of abstraction. > > > >> Generally, the explanations are too verbose. > >> Method names and field names would be easier to recognize if they were > >> quoted, as is done with 'this'. > > Fixed, although this is not common in exception messages. See the > > messages in > http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/r > untime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, > > line 57ff. Only the String of the name field is quoted, not any entities > > declared in the code. > > Similar > http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/r > untime/LoaderConstraints/vtableAME/Test.java > > line 60, also showing the internal signature, see above. > > > >> Argument numbers should be digits, > >> not English words (first, second, etc) to make them easier to pick out. > > Fixed. > >> And has it limits that do not read easily, e.g. "nr. 9". > > Sorry, I don't understand > > src/hotspot/share/classfile/bytecodeUtils.cpp:566 > > test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPoint > erExceptionTest.java:612 > > >> I would not describe 'this' as a local variable. > > Fixed. > > > >> Tests, especially new tests should compile without warnings. > >> NullPointerExceptionTest.java:125 newInstance has been deprecated. > > Fixed. > > > >> The messages can be easier to understand, e.g. > >> 'field a1 is null, trying to invoke a1.hashCode...' instead of: > >> "while trying to invoke the method java.lang.Object.hashCode(()I) on a > >> null reference loaded from local variable 'a1'" > > The message is built along the structure of the bytecode. > > I'll try to change this and then will come up with a new webrev . > > > >> It will easier to understand if it looks more like the code. > >> BTW, what does this look like for fully optimized code? > > You mean whether the bytecode is jitted? It's independent > > of how the code is executed, interpreted or compiled. > > > >> Does it bear any resemblance to the source code at all? > >> Or does it have to be deoptimized to come up with a sensible source > >> reference. > > No, jitted methods must not be deoptimized. > > > >> How much of this can be done in Java code with StackWalker and other > >> java APIs? > >> It would be a shame to add this much native code if there was a more > robust > >> way to implement it using APIs with more leverage. > > StackWalker operates on the Java stack tracke, which does not contain the > BCI > > to my knowledge. Also, I need to read the bytecodes. Are there APIs to > access > > the bytecode as it resides in the metaspace, rewritten, constants resolved > etc? > > The code relies on this. > > From the other thread, beware adding overhead to the constructor. > The lazy computation is essential. > There are a *lot* of NPEs whose messages will never be needed. > > Regards, Roger > > > > > Best regards, > > Goetz. > > > > > > > >> Regards, Roger > >> > >> > >> On 02/08/2019 09:13 AM, Langer, Christoph wrote: > >>> Hi Goetz, > >>> > >>>> ok, so here a new webrev just adding a setter for the field: > >>>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 > >>>> > >>>> ... and incorporating the other comments. > >>> Looks better ?? > >>> > >>> I have a few additions to > >> src/java.base/share/classes/java/lang/NullPointerException.java: > >>> 28 import java.lang.reflect.Field; > >>> 29 > >>> -> can be removed now. > >>> > >>> 91 synchronized (this) { > >>> -> I think this is not needed here. The transient modifier for > >> lazyComputeMessage already implies the lock on the Object, I think. > >>> 108 return extendedMessage; > >>> -> I guess it would be more correct if you returned super.getMessage() > here. > >>> > >>> Thanks > >>> Christoph From Alan.Bateman at oracle.com Wed Feb 13 15:33:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Feb 2019 15:33:33 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <3aeba9a64a434a968fc1d82a44077745@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> Message-ID: On 12/02/2019 21:57, Langer, Christoph wrote: > Hi Alan, all, > > here comes the next proposal for POSIX support in jdk.zipfs - which hopefully represents the converged solution, at least in its overall design. I don't have time to do a detailed code review right now but I did read the updated proposal and javadoc. Overall I think this looks good, meaning opt-in seems right, as does allow specifying configuration to newFileSystem to override defaults. I think the javadoc changes will need a few iterations but we can get to that once some of the finer details are sorted out. For example, "Posix Support" isn't quite right as this is about optional support for the POSIX view of file attributes rather than complete support for POSIX. Also the "Zip" view of file attributes will need to be fleshed out more (the view name for example). I'm not sure about using ${user.name} and "" as default.? Have you looked at using the zip file owner/group (or owner/owner on Windows) as the default?? Also just wondering if 777 might be more appropriate (maybe you have a reason for choosing 660?). It might be useful to see what Linux, macOS and other operating systems do when mounting a FAT file system. The names of the defaultXXX properties when configuring the zip file look okay. Did you consider using the string representation of the user, group and permissions in the configuration properties? The zip file system provider could support both of course. String might make it a bit easier to create the map of configuration properties when creating the file system e.g Map.of("enablePosixPermissions", "true", "defaultOwner", "joe", "defaultPermissions", "rw-rw---"); -Alan From roger.riggs at oracle.com Wed Feb 13 15:56:28 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 13 Feb 2019 10:56:28 -0500 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: References: Message-ID: <42e0bf43-7235-efc3-3ef6-2cfc5d57303c@oracle.com> Hi Thomas, This is a change that should have a release note, can you fill it in: https://bugs.openjdk.java.net/browse/JDK-8218924 Also, I had to do some manual updates to the issues to get the changeset into the history. The issue number should have been 8213192 in the summary lineand on the emails. Hgupdater watches the commits and uses the bugid to update the bug; wrong bug, wrong updates. Thanks, Roger On 2/12/19 1:41 AM, Thomas St?fe wrote: > > > On Mon, Feb 11, 2019 at 9:18 PM Martin Buchholz > wrote: > > Looks good to me. > > > Thank you, I just pushed. > > It's true that these tests depending on external tools are very > brittle. > In particular, strace is in the middle of a flag re-org > > ? ? ? ?-e trace=%process > ? ? ? ?-e trace=process (deprecated) > > Nevertheless, we have such tests - are they worth the maintenance > burden? > My own Zombies.java test is a good example. > > > It is more useful than my proposed test was. I wince a bit at the perl > requirement though. Especially since the test silently quits if no > perl is installed. > > (As a side note, I wonder whether we could have a mechanism to signal > requirements not met, eg. with a TestRequirementsNotMetException, and > then let the test executor decide what to do: warn, ignore, error...) > > I guess part of this could be redone nowadays with Rogers > ProcessHandle API (the child seeking), but we still would need to find > out if the child is a zombie. > > I like the test name btw. Very succinct :) > > ..Thomas > > > > > On Mon, Feb 11, 2019 at 10:50 AM Thomas St?fe > > wrote: > > Hi Roger, Martin, > > hopefully final version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.03/webrev/ > > I removed the test and the changes in the test library made > for the test. Test is just too brittle with too little > nourishing value. Everything else is unchanged from webrev.02. > > Thank you, Thomas > > > > On Fri, Feb 8, 2019 at 10:38 AM Thomas St?fe > > wrote: > > Hi Roger, Martin, > > next version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.02/webrev > > - did massage the comment in ProcessImpl.c > - made the test more resilient by scanning for the strace > tool and by silently ignoring all problems stemming from > strace or the payload binary not being there. The test now > only fails if the forks were successully executed but it > does not seem to use posix-spawn. > - added output to the test by printing the "interesting" > lines of the strace output. Note that this filtering is > not really sophisticated and will show all thread related > clone() calls as well: > > 614 ? [pid 12447] <... clone resumed> > child_stack=0x7fe00c4baff0, > flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, > parent_tidptr=0x7fe00c4bb9d0, tls=0x7fe00c4bb700, > child_tidptr=0x7fe00c4bb9d0) = 12452 > 646 ? [pid 12447] clone(/usr/bin/strace: Process 12453 > attached > 649 ? [pid 12447] <... clone resumed> > child_stack=0x7fe00c3b9ff0, > flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, > parent_tidptr=0x7fe00c3ba9d0, tls=0x7fe00c3ba700, > child_tidptr=0x7fe00c3ba9d0) = 12453 > .... > > I am sure this could be made more intelligent but lets > keep it simple for now. > > - I removed the helperPath() methods Roger mentioned, they > are not needed anymore. > > @Martin: I like the -e signal=none -e trace=process idea > but I'm not sure if all versions of strace support these > options. I think the strace output is small enough for > this small use case, some kB only. > > Cheers, Thomas > > > > > > On Thu, Feb 7, 2019 at 6:01 PM Thomas St?fe > > > wrote: > > Hi all, > > second version, including the updated comment in > ProcessImpl.c Martin requested: > > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html > > @Roger: thanks for feeding this into your tests. I > still try to get it to run thru jdk-submit, but that > seems to be stuck again.. > > Cheers, Thomas > > > > > > On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe > > wrote: > > Hi all > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html > > (@Roger: I hope you do not mind? The bug is > assigned to you but since I happened to play > around with posix_spawn I prepared this webrev. If > you rather do this change, that is fine and I will > leave it to you.) > > When we added the possibility to use posix_spawn > as underlying implementation for Runtime.exec() on > Linux with > https://bugs.openjdk.java.net/browse/JDK-8212828, > we agreed to keep VFORK as default until work on > 13 starts. So now would be a good time to switch > the default to posix_spawn to get a good testing > window. Note that at SAP we run our VMs internally > with posix_spawn as default since some months and > have not seen problems. > > As for the fix, I added a test which tests that > the default is indeed posix_spawn - not sure > whether this is overdoing it though. Also, I use > strace for the test, and /bin/true, and while > strace is usually available and reachable by path > resolution, I am afraid on some test machines it > may not. What do you think, should I leave the > test out? > > The fix ran through all java/lang/ProcessBuilder > jtreg tests ok. > > Thanks, Thomas > From thomas.stuefe at gmail.com Wed Feb 13 16:11:43 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 13 Feb 2019 17:11:43 +0100 Subject: RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn In-Reply-To: <42e0bf43-7235-efc3-3ef6-2cfc5d57303c@oracle.com> References: <42e0bf43-7235-efc3-3ef6-2cfc5d57303c@oracle.com> Message-ID: Sorry, Roger, I must have messed up the bug id when pushing. Thank you for fixing! This would be a good thing to have a jcheck for. ..Thomas On Wed, Feb 13, 2019 at 4:56 PM Roger Riggs wrote: > Hi Thomas, > > This is a change that should have a release note, can you fill it in: > https://bugs.openjdk.java.net/browse/JDK-8218924 > > Also, I had to do some manual updates to the issues to get the changeset > into the history. > The issue number should have been 8213192 in the summary lineand on the > emails. > Hgupdater watches the commits and uses the bugid to update the bug; wrong > bug, wrong updates. > > Thanks, Roger > > > On 2/12/19 1:41 AM, Thomas St?fe wrote: > > > > On Mon, Feb 11, 2019 at 9:18 PM Martin Buchholz > wrote: > >> Looks good to me. >> >> > Thank you, I just pushed. > > >> It's true that these tests depending on external tools are very brittle. >> In particular, strace is in the middle of a flag re-org >> >> -e trace=%process >> -e trace=process (deprecated) >> >> Nevertheless, we have such tests - are they worth the maintenance burden? >> My own Zombies.java test is a good example. >> > > It is more useful than my proposed test was. I wince a bit at the perl > requirement though. Especially since the test silently quits if no perl is > installed. > > (As a side note, I wonder whether we could have a mechanism to signal > requirements not met, eg. with a TestRequirementsNotMetException, and then > let the test executor decide what to do: warn, ignore, error...) > > I guess part of this could be redone nowadays with Rogers ProcessHandle > API (the child seeking), but we still would need to find out if the child > is a zombie. > > I like the test name btw. Very succinct :) > > ..Thomas > > > >> >> On Mon, Feb 11, 2019 at 10:50 AM Thomas St?fe >> wrote: >> >>> Hi Roger, Martin, >>> >>> hopefully final version: >>> >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.03/webrev/ >>> >>> I removed the test and the changes in the test library made for the >>> test. Test is just too brittle with too little nourishing value. Everything >>> else is unchanged from webrev.02. >>> >>> Thank you, Thomas >>> >>> >>> >>> On Fri, Feb 8, 2019 at 10:38 AM Thomas St?fe >>> wrote: >>> >>>> Hi Roger, Martin, >>>> >>>> next version: >>>> >>>> >>>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.02/webrev >>>> >>>> - did massage the comment in ProcessImpl.c >>>> - made the test more resilient by scanning for the strace tool and by >>>> silently ignoring all problems stemming from strace or the payload binary >>>> not being there. The test now only fails if the forks were successully >>>> executed but it does not seem to use posix-spawn. >>>> - added output to the test by printing the "interesting" lines of the >>>> strace output. Note that this filtering is not really sophisticated and >>>> will show all thread related clone() calls as well: >>>> >>>> 614 [pid 12447] <... clone resumed> child_stack=0x7fe00c4baff0, >>>> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, >>>> parent_tidptr=0x7fe00c4bb9d0, tls=0x7fe00c4bb700, >>>> child_tidptr=0x7fe00c4bb9d0) = 12452 >>>> 646 [pid 12447] clone(/usr/bin/strace: Process 12453 attached >>>> 649 [pid 12447] <... clone resumed> child_stack=0x7fe00c3b9ff0, >>>> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, >>>> parent_tidptr=0x7fe00c3ba9d0, tls=0x7fe00c3ba700, >>>> child_tidptr=0x7fe00c3ba9d0) = 12453 >>>> .... >>>> >>>> I am sure this could be made more intelligent but lets keep it simple >>>> for now. >>>> >>>> - I removed the helperPath() methods Roger mentioned, they are not >>>> needed anymore. >>>> >>>> @Martin: I like the -e signal=none -e trace=process idea but I'm not >>>> sure if all versions of strace support these options. I think the strace >>>> output is small enough for this small use case, some kB only. >>>> >>>> Cheers, Thomas >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Feb 7, 2019 at 6:01 PM Thomas St?fe >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> second version, including the updated comment in ProcessImpl.c Martin >>>>> requested: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.01/webrev/index.html >>>>> >>>>> @Roger: thanks for feeding this into your tests. I still try to get it >>>>> to run thru jdk-submit, but that seems to be stuck again.. >>>>> >>>>> Cheers, Thomas >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 6, 2019 at 10:29 AM Thomas St?fe >>>>> wrote: >>>>> >>>>>> Hi all >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213192 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html >>>>>> >>>>>> (@Roger: I hope you do not mind? The bug is assigned to you but since >>>>>> I happened to play around with posix_spawn I prepared this webrev. If you >>>>>> rather do this change, that is fine and I will leave it to you.) >>>>>> >>>>>> When we added the possibility to use posix_spawn as underlying >>>>>> implementation for Runtime.exec() on Linux with >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep >>>>>> VFORK as default until work on 13 starts. So now would be a good time to >>>>>> switch the default to posix_spawn to get a good testing window. Note that >>>>>> at SAP we run our VMs internally with posix_spawn as default since some >>>>>> months and have not seen problems. >>>>>> >>>>>> As for the fix, I added a test which tests that the default is indeed >>>>>> posix_spawn - not sure whether this is overdoing it though. Also, I use >>>>>> strace for the test, and /bin/true, and while strace is usually available >>>>>> and reachable by path resolution, I am afraid on some test machines it may >>>>>> not. What do you think, should I leave the test out? >>>>>> >>>>>> The fix ran through all java/lang/ProcessBuilder jtreg tests ok. >>>>>> >>>>>> Thanks, Thomas >>>>>> >>>>>> > From henry.jen at oracle.com Wed Feb 13 17:37:48 2019 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 13 Feb 2019 09:37:48 -0800 Subject: RFR: 8217216: Launcher does not defend itself against LD_LIBRARY_PATH_64 (Solaris) Message-ID: Hi, Please review the webrev[1] for 8217216. The fix makes sure on Solaris, when LD_LIBRARY_PATH_64 is set, we setup LD_LIBRARY_PATH based on that value and unset LD_LIBRARY_PATH_64 in the relaunched process. Same approach was used before JDK-6367077, and the override is expected behavior on Solaris 64-bit as stated in Solaris 64-bit Developer's Guide[2], "The 64-bit dynamic linker's search path can be completely overridden using the LD_LIBRARY_PATH_64 environment variable." Cheers, Henry [1] http://cr.openjdk.java.net/~henryjen/8217216/0/webrev/ [2] https://docs.oracle.com/cd/E19455-01/806-0477/dev-env-7/index.html From mandy.chung at oracle.com Wed Feb 13 17:46:43 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Feb 2019 09:46:43 -0800 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <3245ec3cefe2471e8382048164c0ba6b@sap.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <3245ec3cefe2471e8382048164c0ba6b@sap.com> Message-ID: <34a10a4f-7c33-125a-d8ce-cc8915af5fa6@oracle.com> I have to say that the example NPE messages this patch has are like stuffing as much relevant information in the message but they are not developer-friendly as Roger and David has commented. Exposing bytecode-level details is very confusing to Joe's developer while, from your perspective, anything would be useful because this is helpful for production support purpose. It's a tradeoff. That's why I think the default message should include an informative and developer-friendly message whereas the field support needs the customization ability for better serviceability at production environment. Prototyping this in Java will allow us to explore other possibility for example enabling a plugin to format a custom exception message rather than hardcoding this in the default message. This RFE and JDK-8211152 may better be addressed by providing the ability to customize the exception message format (that's the idea in my mind but I have not had time to pursue further). Mandy On 2/13/19 1:09 AM, Lindenmaier, Goetz wrote: > Hi Mandy, > > Thanks for supporting my intend of adding the message as such! > I'll start implementing this in Java and come back with a webrev > in a while. > > In parallel, I would like to continue discussing the other > topics, e.g., the wording of the message. I will probably come up > with a separate webrev for that. > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: core-libs-dev On Behalf >> Of Mandy Chung >> Sent: Tuesday, February 12, 2019 7:32 PM >> To: Roger Riggs >> Cc: Java Core Libs ; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException >> describing what is null. >> >> On 2/8/19 11:46 AM, Roger Riggs wrote: >>> Hi, >>> >>> A few higher level issues should be considered, though the details >>> of the webrev captured my immediate attention. >>> >>> Is this the right feature and is this the right level of implementation >>> (C++/native)? >>> : >>> How much of this can be done in Java code with StackWalker and other >>> java APIs? >>> It would be a shame to add this much native code if there was a more >> robust >>> way to implement it using APIs with more leverage. >> >> Improving the NPE message for better diagnosability is helpful while >> I share the same concern Roger raised. >> >> Implementing this feature in Java and the library would be a better >> choice as this isn't absolutely required to be done in VM in native. >> >> NPE keeps a backtrace capturing the method id and bci of each stack >> frame. One option to explore is to have StackWalker to accept a >> Throwable object that returns a stream of StackFrame which allows >> you to get the method and BCI and also code source (I started a >> prototype for JDK-8189752 some time ago). It can use the bytecode >> library e.g. ASM to read the bytecode. For NPE message, you can >> implement a specialized StackFrameTraverser just for building >> an exception message purpose. >> >> Mandy From huizhe.wang at oracle.com Wed Feb 13 18:15:07 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 13 Feb 2019 10:15:07 -0800 Subject: RFR(JDK 13/java.xml) 8187697: Cleanup: irrelevant code in OutputPropertiesFactory Message-ID: <5C645EAB.2030509@oracle.com> Please review a cleanup patch for the OutputPropertiesFactory. The original intention was to remove the (awkward) JDK 1.2-related code, line 235-258 in the old file. I then went a bit further to remove another nuisance that annoyed users with an error "Could not load the property file 'output_xml.properties' for output method 'xml'" from time to time. The output properties files are now removed and the contents moved into static arrays in OutputPropertiesFactory between line 192 and 288 in the new file. The processing process is kept mostly as is. The only change was removing the "fixupPropertyString" process, as a result the only line kept from the old file line 447 - 500 was line 376 in the new file. JBS: https://bugs.openjdk.java.net/browse/JDK-8187697 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8187697/webrev/ Thanks, Joe From lance.andersen at oracle.com Wed Feb 13 19:55:54 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 13 Feb 2019 14:55:54 -0500 Subject: RFR(JDK 13/java.xml) 8187697: Cleanup: irrelevant code in OutputPropertiesFactory In-Reply-To: <5C645EAB.2030509@oracle.com> References: <5C645EAB.2030509@oracle.com> Message-ID: <82C41B1A-23FC-4A78-8AF1-4E9CFA2947A9@oracle.com> Hi Joe Overall the change seems Ok, assuming all the tests are happy :-) One minor suggestion for: src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java - line 150, please put the ?*/? on its own line > On Feb 13, 2019, at 1:15 PM, Joe Wang wrote: > > Please review a cleanup patch for the OutputPropertiesFactory. > > The original intention was to remove the (awkward) JDK 1.2-related code, line 235-258 in the old file. I then went a bit further to remove another nuisance that annoyed users with an error "Could not load the property file 'output_xml.properties' for output method 'xml'" from time to time. The output properties files are now removed and the contents moved into static arrays in OutputPropertiesFactory between line 192 and 288 in the new file. > > The processing process is kept mostly as is. The only change was removing the "fixupPropertyString" process, as a result the only line kept from the old file line 447 - 500 was line 376 in the new file. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8187697 > webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8187697/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 Roger.Riggs at oracle.com Wed Feb 13 20:27:59 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 13 Feb 2019 15:27:59 -0500 Subject: RFR 8218228 : The constructor StringBuffer(CharSequence) violates spec for negatively sized argument In-Reply-To: <810e5d0c-d585-c3eb-6b3d-8ed627f87eab@oracle.com> References: <5bc52e4c-d829-dc38-de1d-2f1e59f89f30@oracle.com> <05b02192-d8b8-f49a-5b2f-299b8c4e1fad@oracle.com> <07bbc6e7-0656-0efa-0f24-987aeb43e9cc@oracle.com> <445d726b-5a45-b43f-3aea-452fbfc10124@oracle.com> <141ec0dc-beba-6ae3-1dc2-21f7f77bcb9b@oracle.com> <28ea7fd8-4320-8ac9-b671-134f8fc78ae7@oracle.com> <1e291796-7751-0008-6eb3-96a1e680acd3@oracle.com> <650db381-af59-096d-15f8-908f29229c69@oracle.com> <810e5d0c-d585-c3eb-6b3d-8ed627f87eab@oracle.com> Message-ID: Hi Ivan, The release note looks fine,? Resolve -> FixDelivered to pass it on to the tech writer for review. Yes, communication is sometimes the hard part. Thanks, Roger On 02/12/2019 08:21 PM, Ivan Gerasimov wrote: > Uh, lots of paperwork, comparing to the actual change in the source > code :-) > > Anyways, I updated the CSR as you suggested, and created a release > note subtask: > https://bugs.openjdk.java.net/browse/JDK-8218884 > > Could you please review it? > > With kind regards, > Ivan > > On 2/12/19 8:51 AM, Roger Riggs wrote: >> Hi Ivan, >> >> Sorry, one more.? The compatibility risk description should be >> specific about >> the behavior that is changing.? Something like: >> >> Since JDK5, the exception thrown for negative lengths have been >> unspecified >> and inconsistent; with this change, NegativeArraySizeException will >> be thrown. >> >> Thanks, Roger >> >> p.s.? A release note capturing the essence of the change is probably >> needed also. >> Add label release-note=yes to the issue and create a subtask. >> >> >> On 02/12/2019 11:39 AM, Ivan Gerasimov wrote: >>> >>> >>> On 2/12/19 7:33 AM, Roger Riggs wrote: >>>> Hi Ivan, >>>> >>>> The change to consistently throw NegativeSizeArrayException applies >>>> to StringBuilder also. >>>> Please mention that with the solution. >>>> >>> Right, thanks.? I updated CSR accordingly. >>> >>> With kind regards, >>> Ivan >>> >>>> Thanks, Roger >>>> >>>> >>>> On 02/11/2019 06:12 PM, Ivan Gerasimov wrote: >>>>> Hi Roger! >>>>> >>>>> >>>>> On 2/11/19 7:30 AM, Roger Riggs wrote: >>>>>> Hi Ivan, >>>>>> >>>>>> I called it out because the CSR does not mention that the behavior >>>>>> of some of the cases (-1..-16) is changing and some of the emails >>>>>> asserted >>>>>> there was no change in behavior. >>>>>> >>>>>> I'm fine with one changeset as long as both changes are explicit. >>>>>> The bug and the CSR should both be updated. >>>>>> >>>>> Yes, this makes sense. >>>>> I've updated CSR accordingly, and added a comment to the bug to >>>>> make the intention of the fix clear. >>>>> >>>>> Could you please review the updated CSR? >>>>> >>>>> With kind regards, >>>>> Ivan >>>>> >>>>> >>>>> >>>>>> Thanks, Roger >>>>>> >>>>>> >>>>>> On 02/08/2019 05:12 PM, Ivan Gerasimov wrote: >>>>>>> Hi Roger! >>>>>>> >>>>>>> That's because two tiny changes are combined in the patch: >>>>>>> >>>>>>> 1) remove a problematic statement from the javadoc, as it >>>>>>> doesn't hold anyway.? This part does not change the behavior. >>>>>>> >>>>>>> 2) unify type of the exception thrown for all negative values of >>>>>>> CharSequence.length().? The regression test is to verify this, >>>>>>> second change, so it fails prior the fix for length in [-16, -1]. >>>>>>> >>>>>>> I can separate them into different bugs, if you think it will >>>>>>> make it clearer.? Though I thought they can be fixed together. >>>>>>> >>>>>>> With kind regards, >>>>>>> >>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> On 2/8/19 1:49 PM, Roger Riggs wrote: >>>>>>>> Hi Ivan, >>>>>>>> >>>>>>>> In the direction of not changing the behavior; the webrev does >>>>>>>> change the behavior. >>>>>>>> >>>>>>>> In the case of CharSeqence with length -1..-16, the new >>>>>>>> behavior throws NegativeArrayIndexException >>>>>>>> instead of java.lang.IndexOutOfBoundsException. >>>>>>>> >>>>>>>> >>>>>>>> AbstractStringBuilder:101-102 throw an exception for length < 0. >>>>>>>> However, the current behavior is to create a StringBuffer with >>>>>>>> length + 16 and >>>>>>>> then append the contents.? For -1..-16, it will succeed in >>>>>>>> creating a StringBuffer >>>>>>>> but fail with IndexOutOfBoundsException during the append of >>>>>>>> the contents. >>>>>>>> >>>>>>>> The new Test should pass both before and after the change to >>>>>>>> the code. >>>>>>>> >>>>>>>> Roger >>>>>>>> >>>>>>>> >>>>>>>> On 02/07/2019 10:19 PM, Ivan Gerasimov wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/7/19 6:33 PM, David Holmes wrote: >>>>>>>>>> On 8/02/2019 11:59 am, Ivan Gerasimov wrote: >>>>>>>>>>> Hi David! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2/7/19 5:16 PM, David Holmes wrote: >>>>>>>>>>>> Hi Ivan, >>>>>>>>>>>> >>>>>>>>>>>> On 8/02/2019 11:02 am, Ivan Gerasimov wrote: >>>>>>>>>>>>> Hello! >>>>>>>>>>>>> >>>>>>>>>>>>> The specification states: >>>>>>>>>>>>> """ >>>>>>>>>>>>> If the length of the specified CharSequence is less than >>>>>>>>>>>>> or equal to zero, then an empty buffer of capacity 16 is >>>>>>>>>>>>> returned. >>>>>>>>>>>>> """ >>>>>>>>>>>>> >>>>>>>>>>>>> However, the current implementation throws either >>>>>>>>>>>>> NegativeArraySizeException or IndexOutOfBounds instead >>>>>>>>>>>>> (the actual exception type depends on the value of >>>>>>>>>>>>> reported negative length). >>>>>>>>>>>> >>>>>>>>>>>> How can you have a negative length CharSequence ?? >>>>>>>>>>>> >>>>>>>>>>> A custom CharSequence returning negative length() can be >>>>>>>>>>> created. >>>>>>>>>>> Not sure how useful/popular this may be, though. >>>>>>>>>> >>>>>>>>>> Seems pretty meaningless so just treating that as an error >>>>>>>>>> seems fine. Though somewhat debatable whether you need to add >>>>>>>>>> an appropriate @throws. >>>>>>>>>> >>>>>>>>> Right.? There were two reasons not to add @throws here: >>>>>>>>> - by removing the problematic paragraph we just make the >>>>>>>>> javadoc almost the same as for StringBuilder(CharSequence), >>>>>>>>> - we don't seem to have any other places (at least I couldn't >>>>>>>>> find any) specifying exceptions due to negatively sized >>>>>>>>> CharSequence. >>>>>>>>> >>>>>>>>> (To be precise, there is one candidate, but I'll file a >>>>>>>>> separate bug to fix it.) >>>>>>>>> >>>>>>>>>>> That's why I propose just removing the mentioning negative >>>>>>>>>>> length, and not changing the behavior. >>>>>>>>>>> >>>>>>>>>>> The proposed code change is to only unify the behavior for >>>>>>>>>>> any negative value of length. >>>>>>>>>> >>>>>>>>>> Ok. >>>>>>>>>> >>>>>>>>>>>> If its an empty CharSequence then it should return the >>>>>>>>>>>> empty buffer as indicated. >>>>>>>>>>>> >>>>>>>>>>> Empty CharSequence is processed correctly already. >>>>>>>>>> >>>>>>>>>> Okay so by removing this part: >>>>>>>>>> >>>>>>>>>> -????? *

>>>>>>>>>> -????? * If the length of the specified {@code CharSequence} is >>>>>>>>>> -????? * less than or equal to zero, then an empty buffer of >>>>>>>>>> capacity >>>>>>>>>> -????? * {@code 16} is returned. >>>>>>>>>> >>>>>>>>>> you're relying on the main specification to implicitly handle >>>>>>>>>> the empty case. >>>>>>>>>> >>>>>>>>> Yes. >>>>>>>>> >>>>>>>>> With kind regards, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> With kind regards, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> It is proposed to do two things: >>>>>>>>>>>>> 1) remove the problematic sentence from the javadoc (CSR >>>>>>>>>>>>> is filed). >>>>>>>>>>>>> 2) unify the exception type thrown, if the argument >>>>>>>>>>>>> reports negative length. >>>>>>>>>>>>> NegativeArraySizeException will be consistent with, for >>>>>>>>>>>>> example, StringBuffer(negativeCapacity). >>>>>>>>>>>>> >>>>>>>>>>>>> Would you please help review the fix? >>>>>>>>>>>>> >>>>>>>>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218228 >>>>>>>>>>>>> WEBREV: >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8218228/00/webrev/ >>>>>>>>>>>>> CRS: https://bugs.openjdk.java.net/browse/JDK-8218649 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From huizhe.wang at oracle.com Wed Feb 13 20:35:57 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 13 Feb 2019 12:35:57 -0800 Subject: RFR(JDK 13/java.xml) 8187697: Cleanup: irrelevant code in OutputPropertiesFactory In-Reply-To: <82C41B1A-23FC-4A78-8AF1-4E9CFA2947A9@oracle.com> References: <5C645EAB.2030509@oracle.com> <82C41B1A-23FC-4A78-8AF1-4E9CFA2947A9@oracle.com> Message-ID: <5C647FAD.6040200@oracle.com> On 2/13/19, 11:55 AM, Lance Andersen wrote: > Hi Joe > > Overall the change seems Ok, assuming all the tests are happy :-) Yes, they all are happy. > > One minor suggestion for: > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java > > - line 150, please put the ?*/? on its own line Done. Thanks, Joe > >> On Feb 13, 2019, at 1:15 PM, Joe Wang > > wrote: >> >> Please review a cleanup patch for the OutputPropertiesFactory. >> >> The original intention was to remove the (awkward) JDK 1.2-related >> code, line 235-258 in the old file. I then went a bit further to >> remove another nuisance that annoyed users with an error "Could not >> load the property file 'output_xml.properties' for output method >> 'xml'" from time to time. The output properties files are now removed >> and the contents moved into static arrays in OutputPropertiesFactory >> between line 192 and 288 in the new file. >> >> The processing process is kept mostly as is. The only change was >> removing the "fixupPropertyString" process, as a result the only line >> kept from the old file line 447 - 500 was line 376 in the new file. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8187697 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8187697/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 lance.andersen at oracle.com Wed Feb 13 22:05:09 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 13 Feb 2019 17:05:09 -0500 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <3aeba9a64a434a968fc1d82a44077745@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> Message-ID: Hi Christoph, Just starting to take a peek at this and noticed one quick thing in your test: ------------ Paths.get(System.getProperty("test.dir", "."), "testPosix.zip") ?????? You do not need the test.dir property or the permission added to test.policy to access it, just reference the jar and it will be created in user.dir which is also writable. Best Lance > On Feb 12, 2019, at 4:57 PM, Langer, Christoph wrote: > > Hi Alan, all, > > here comes the next proposal for POSIX support in jdk.zipfs - which hopefully represents the converged solution, at least in its overall design. > > http://cr.openjdk.java.net/~clanger/webrevs/8213031.6/ > > With that patch, the behavior is the following: > a) A ZipFileSystem instance by default does NOT support the PosixFileAttributeView. However, it is possible to query for a known attribute named "zip:storedPermissions". Its value can be null to represent no permission information or any set of PosixFileAttribute. > b) A ZipFileSystem instance can be created with the property "posix"=true. In that case, PosixFileAttributeView is supported with default values. > -> owner: A UserPrincipal with the name of System.getProperty("user.name") if property access is allowed, "" otherwise > -> group: A GroupPrincipal with the name "". > -> permissions: Set.of(OWNER_READ, OWNER_WRITE, GROUP_READ) > > The default values can be modified by using the properties "defaultOwner", "defaultGroup" and "defaultPermissions". > > Implementation wise the ZipFileAttributeView always extends PosixFileAttributeView but behaves different, depending on how it was obtained. > > Within ZipFileSystem, the Entry inner class is not static any more but always has a reference to the Enclosing ZipFileSystem. That's needed because default owner/group/permission can be set on ZipFileSystem instance level now and the Entry, implementing the FileAttributes needs to know where it belongs to. This seems somewhat logical anyway. > > The new test "TestPosix" is quite extensive. I had to add 2 permissions to test.policy to allow testing in a restricted environment. > > Module-info and CSR have been adopted, too. > > Thanks in advance for reviewing. > > Best regards > Christoph > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Montag, 21. Januar 2019 10:17 >> To: 'Alan Bateman' >> Cc: nio-dev ; OpenJDK Dev list > dev at openjdk.java.net>; Java Core Libs ; >> Volker Simonis >> Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions >> >> Hi Alan, >> >> first of all, thank you for your input on this. >> >>> I think the approach to explore are: >>> >>> 1. zipfs supports PosixFileAttributeView without subsetting. If >>> readAttribute(file, BasicFileAttributes.class) succeeds then >>> readAttribute(file, PosixFileAttributes.class) should also succeed, even >>> if there aren't permissions encoded in the zip entry's external file >>> attributes. It would mean that owner and group return default values, >>> and permissions may return a default value. It does mean you can't >>> distinguish the default value from "no permissions" but there is >>> precedence for that, e.g. mount a FAT32 file system on Linux or Unix >>> systems and `stat` a file to have the stat structure populated with >>> default uid, gid and mode bits. >> >> OK, I can see the point that in a PosixFileAttributeView as it is, there's no >> place for optionality/null values. However, with this approach the benefits >> would be that Files::get/setPosixPermissions would work and that's why I >> think we should pursue this. The challenge will be to find reasonable >> defaults. >> >>> 2. zipfs defines a new FileAttributeView that defines read and write >>> access to permissions stored in a zip entry's external file attribute. >>> As it's a new view then it can define the behavior for the case that the >>> zip entry doesn't have permissions. Furthermore it does not need to >>> extend BasicFileAttributeView so doesn't need to be concerned with bulk >>> access, nor concerned with group/owner. As you know, the attributes API >>> allows for both type safe and dynamic access so you have a choice as to >>> whether to support both or just dynamic access. With the first then >>> jdk.zipfs would export a package with a public interface that defines >>> the view. If someone wants type safe access to the permissions attribute >>> then you need to import the class. The alternative is to not export any >>> packages but just define the view in the module-info. The view its name >>> and define the name/type of the permissions attribute, it will also >>> define how it behaves when the external attributes aren't populated. In >>> usage terms it means reading the permissions will be something like >>> Files.readAttribute(file, "zip:permissions") and casting the value to >>> Set - not pretty but it avoids depending on a >>> JDK-specific API. >> >> For this approach, there are 2 things I dislike. The first is that I don't think we >> should export named packages from module jdk.zipfs that people would >> develop Java code against while not being in the Java API. And secondly, this >> way would not support using Files::set/getPosixPermissions since the >> specification/implementation of that utility method explicitly refers to >> PosixFileAttributeView. >> >> I can imagine something like this: >> Zipfs by default implements an own view that offers dynamic, not type safe >> access to "zip:permissions" and we'll document this. If a user of zipfs wants >> to see full PosixFileAttributeView support with default values, then we >> should allow for a creation attribute for the zipfs that can control this. Maybe >> we can even allow specifying default values for user, group and permissions >> via zipfs attributes. >> >> I'll work to develop the patch into this direction unless you tell me that this >> idea is bogus (if so, then I hope it be soon ??) >> >> 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 christoph.langer at sap.com Wed Feb 13 22:26:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 13 Feb 2019 22:26:02 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> Message-ID: <21cfb27e67514b26a4505c589adf2781@sap.com> Hi Alan, thanks for taking a first look into this new edition. > I think the javadoc changes will need a few iterations but we can get to > that once some of the finer details are sorted out. For example, "Posix > Support" isn't quite right as this is about optional support for the > POSIX view of file attributes rather than complete support for POSIX. Ok. > Also the "Zip" view of file attributes will need to be fleshed out more > (the view name for example). I don't know if that's really necessary as the "Zip" view currently is internal to jdk.zips and I don't propose to export it. > I'm not sure about using ${user.name} and "" as default. > Have you looked at using the zip file owner/group (or owner/owner on > Windows) as the default?? Hm, I guess for Unix that'd be ok. But how would I get to the owner of a file in Window's default file system? > Also just wondering if 777 might be more > appropriate (maybe you have a reason for choosing 660?). It might be > useful to see what Linux, macOS and other operating systems do when > mounting a FAT file system. I implemented 640, but it was just chosen without much thinking. I can agree to 777. > Did you consider using the string representation of the user, group and > permissions in the configuration properties? The zip file system > provider could support both of course. String might make it a bit easier > to create the map of configuration properties when creating the file > system e.g > Map.of("enablePosixPermissions", "true", "defaultOwner", "joe", > "defaultPermissions", "rw-rw---"); Sounds like a good and feasible idea. I'll try to address these points in a next iteration. Best regards Christoph From christoph.langer at sap.com Wed Feb 13 22:30:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 13 Feb 2019 22:30:45 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> Message-ID: <818ca9a7fe2445638dddc2481f95f9f8@sap.com> Hi Lance, thanks for looking. > Just starting to take a peek at this and noticed one quick thing in your test: > ------------ > Paths.get(System.getProperty("test.dir", "."), "testPosix.zip") > ?????? > > You do not need the test.dir property ?or the permission added to test.policy > to access it, ?just reference the jar and it will be created in user.dir which is > also writable. Hm, I thought I didn't want to mess around in "user.dir" as it can be some more global directory where you wouldn't want to leave artefacts... To me "test.dir" feels cleaner. Are there other opinions about that? Thanks Christoph From lance.andersen at oracle.com Wed Feb 13 22:53:15 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 13 Feb 2019 17:53:15 -0500 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <818ca9a7fe2445638dddc2481f95f9f8@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <818ca9a7fe2445638dddc2481f95f9f8@sap.com> Message-ID: <3854DFE0-C244-4920-9554-65F6401438BF@oracle.com> Hi Christoph > On Feb 13, 2019, at 5:30 PM, Langer, Christoph wrote: > > Hi Lance, > > thanks for looking. > >> Just starting to take a peek at this and noticed one quick thing in your test: >> ------------ >> Paths.get(System.getProperty("test.dir", "."), "testPosix.zip") >> ?????? >> >> You do not need the test.dir property or the permission added to test.policy >> to access it, just reference the jar and it will be created in user.dir which is >> also writable. > > Hm, I thought I didn't want to mess around in "user.dir" as it can be some more global directory where you wouldn't want to leave artefacts... To me "test.dir" feels cleaner. Are there other opinions about that? user.dir points to the scratch directory that test uses, so it is where you want to create the tests. Workspaces can sometimes be read only: For example: ?????? @Test public void test000() throws IOException { System.out.println("test.dir = " + System.getProperty("test.dir", ".")); System.out.println("user.dir = " + System.getProperty("user.dir", ".")); System.out.println( Paths.get(System.getProperty("test.dir", "."), "basic.jar").toAbsolutePath() ); } ----------------- Results in: -------------------- test.dir = . user.dir = /Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch /Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/./basic.jar Please see http://openjdk.java.net/jtreg/tag-spec.html for the system properties. I do not see test.dir there. ????????? I would just do: ????????? Path foo = Path.of("test.zip"); System.out.println("test.zip path=" + foo.toAbsolutePath()); -------------------------- which results in the output: test.zip path=/Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/test.zip 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 stuart.marks at oracle.com Thu Feb 14 02:44:28 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 13 Feb 2019 18:44:28 -0800 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> Message-ID: On 2/8/19 5:13 AM, Tagir Valeev wrote: >> I would argue that iterating the argument and calling remove() on "this" are the >> right semantics, because you want set membership to be determined by this set, >> not by whatever collection you pass as an argument. However, I note that >> AbstractCollection.removeAll and other removeAll implementations iterate over >> "this" and do a contains() check on the argument. The revised >> AbstractSet.removeAll would be an outlier here, though it makes sense to me to >> do it this way. > > For complete picture it should be noted that there's a slight > difference in remove and removeAll spec: remove removes at most one > element while removeAll removes all elements from the specified > collection. > E.g. c.removeAll(Collections.singleton(foo)) would remove all > instances of foo from c while c.remove(foo) would return only one foo. > These should be equivalent for Set where repeating elements should not > normally appear, but it's wrong for any Collection. That's why > AbstractCollection.removeAll > cannot be rewritten in the same way. Yes, this is a good point. This increases my concern over my earlier proposal for AbstractSet.removeAll being an "outlier". The main issue here is whose semantics for containership are used. I had proposed iterating "arg" and calling this.remove() because that makes sense in isolation. However, AbstractCollection iterates "this" and calls arg.contains(). As you note, the specification implies that it must be done this way. This conflicts with my AbstractSet proposal. In addition, there is the matter of retainAll(). You can't iterate "arg" and call this.remove(), since you need to remove elements that *aren't* present in "arg". At least, you can't without building an intermediate data structure, which seems out of bounds here. So retainAll() pretty much needs to iterate "this" and call arg.contains(). Based on this, I've changed my mind. AbstractSet.removeAll() really should do the same thing as AbstractCollection.removeAll(), namely to iterate "this" and call arg.contains(). In fact, AbstractSet can simply inherit the AbstractCollection implementation, and its specification adjusted accordingly. Unfortunately, this means that code like the following: someSet.removeAll(someList) will have O(m*n) performance, since it will repeatedly call someList.contains(). This doesn't alleviate the performance concern. However, it's at least specified and predictable, so one can work around it if necessary. Also, set1.removeAll(set2) will unconditionally use set2's semantics for containership. This is a bit counterintuitive, as one might expect set1's semantics to be used. But it needs to be this way to be consistent with Collection.removeAll(), Collection.retainAll(), and Set.retainAll(). And at least it's predictable, and it doesn't vary based on the relative sizes of the sets! > Another interesting thing is > java.util.IdentityHashMap.KeySet#removeAll implementation [1]: > it reimplements the AbstractCollection#removeAll, because of the same > reason: now > the first branch of AbstractSet#removeAll becomes incorrect. See the > comment before it: > > /* > * Must revert from AbstractSet's impl to AbstractCollection's, as > * the former contains an optimization that results in incorrect > * behavior when c is a smaller "normal" (non-identity-based) Set. > */ > > Btw this comment should be updated to remove a "smaller" condition if > the proposed > change for AbstractSet will be implemented. > > [1] http://hg.openjdk.java.net/jdk/jdk/file/e57bcfd7bf79/src/java.base/share/classes/java/util/IdentityHashMap.java#l990 Also a good point. In fact, with my current thinking, this comment and the override can be removed, since it can be inherited from AbstractCollection. (This also applies to EntrySet later in the same file.) ** I also note that ConcurrentHashMap's CollectionView nested class [1] has a removeAll() implementation that uses a similar (but slightly different) heuristic for deciding whether to iterate "this" or "arg". I think this heuristic should be removed, since it suffers from the same semantic shift depending on relative sizes. I further note that ConcurrentSkipListSet.removeAll() overrides AbstractSet.removeAll() in order to avoid an expensive call to size(). But it always iterates its arg and removes from this, which is backwards from everywhere else. (But at least it doesn't do any size-based "optimization".) I think this is simply a bug. I've filed JDK-8218945 [2] to cover this. ** If we all agree on this, I'll proceed with working up a changeset for JDK-6394757.[3] It's time to fix this one. s'marks [1] http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#l4538 [2] https://bugs.openjdk.java.net/browse/JDK-8218945 [3] https://bugs.openjdk.java.net/browse/JDK-6394757 From stuart.marks at oracle.com Thu Feb 14 03:12:22 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 13 Feb 2019 19:12:22 -0800 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> Message-ID: Right, as I mentioned in my earlier emails [1][2] this is related to JDK-6394757 [3] where the semantics shift depending on the relative sizes of the collections. This has a complicated history. In JDK-6982173 [4] there is a lot of discussion about what heuristics to use for iterating this vs the arg, in order to get the best performance. This assumes that these operations are equivalent, when they aren't! In JDK-6394757 there's some discussion about the dubious semantics of this optimization and the potential of simply removing it. At this point I think we need to remove the performance heurstic in order to get consistent semantics. The performance won't be optimal -- indeed, it wasn't before -- but at least it should be more predictable. Your example is indeed counterintuitive, as it uses the contains() semantics of the argument -- the string length -- instead of the contains() semantics of "this". However, it's defensible, and it's supported by the spec, so I don't really see any alternative. The example set is pretty counterintuitive in the first place. For example: jshell> Set set = new TreeSet<>(Comparator.comparingInt(String::length)) jshell> set.addAll(List.of("a", "if", "the", "when")) jshell> set set ==> [a, if, the, when] jshell> set.contains("foo") $235 ==> true Also, this comparator isn't consistent with equals. This isn't a bug. But it does give rise to even more counterintuitive behavior: jshell> var set2 = Set.of("x", "xx", "xxx", "xxxx") jshell> set2.equals(set) $237 ==> false jshell> set.equals(set2) $238 ==> true Fun with collections! :-) s'marks [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058172.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058539.html [3] https://bugs.openjdk.java.net/browse/JDK-6394757 [4] https://bugs.openjdk.java.net/browse/JDK-6982173 On 2/11/19 2:23 PM, Michael Rasmussen wrote: > The current implementation seems very counter-intuitive with anything that doesn't have the same comparison semantics, for instance a TreeSet/Map with a Comparator, Identity-based Set/Map etc. > > The output of the following snippet would probably surprise most: > /* --- snip --- */ > import java.util.*; > class Test { > public static void main(String[] args) { > TreeMap> lengthMap = new TreeMap<>(Comparator.comparingInt(String::length)); > List strings = new ArrayList<>(Arrays.asList("The quick brown fox jumps over the lazy dog".split(" "))); > for (String s : strings) { > lengthMap.computeIfAbsent(s, k -> new ArrayList<>()).add(s); > } > > Set toRemove = lengthMap.keySet(); > > System.out.println("List before: " + strings); > System.out.println("Set to remove: " + toRemove); > > strings.removeAll(toRemove); > System.out.println("List after:" + strings); > } > } > /* --- snip --- */ > List before: [The, quick, brown, fox, jumps, over, the, lazy, dog] > Set to remove: [The, over, quick] > List after:[] > > > /Michael > > > From: core-libs-dev on behalf of Tagir Valeev > Sent: 08 February 2019 15:13 > To: Stuart Marks > Cc: core-libs-dev; Jan Peter Stotz > Subject: Re: JDK-6982173: Small problem causing thousands of wasted CPU hours > > > Hello! > >> I would argue that iterating the argument and calling remove() on "this" are the >> right semantics, because you want set membership to be determined by this set, >> not by whatever collection you pass as an argument. However, I note that >> AbstractCollection.removeAll and other removeAll implementations iterate over >> "this" and do a contains() check on the argument. The revised >> AbstractSet.removeAll would be an outlier here, though it makes sense to me to >> do it this way. > > For complete picture it should be noted that there's a slight > difference in remove and removeAll spec: remove removes at most one > element while removeAll removes all elements from the specified > collection. > E.g. c.removeAll(Collections.singleton(foo)) would remove all > instances of foo from c while c.remove(foo) would return only one foo. > These should be equivalent for Set where repeating elements should not > normally appear, but it's wrong for any Collection. That's why > AbstractCollection.removeAll > cannot be rewritten in the same way. > > Another interesting thing is > java.util.IdentityHashMap.KeySet#removeAll implementation [1]: > it reimplements the AbstractCollection#removeAll, because of the same > reason: now > the first branch of AbstractSet#removeAll becomes incorrect. See the > comment before it: > > ??????? /* > ???????? * Must revert from AbstractSet's impl to AbstractCollection's, as > ???????? * the former contains an optimization that results in incorrect > ???????? * behavior when c is a smaller "normal" (non-identity-based) Set. > ???????? */ > > Btw this comment should be updated to remove a "smaller" condition if > the proposed > change for AbstractSet will be implemented. > > [1] http://hg.openjdk.java.net/jdk/jdk/file/e57bcfd7bf79/src/java.base/share/classes/java/util/IdentityHashMap.java#l990 > > With best regards, > Tagir Valeev > > > On Fri, Jan 25, 2019 at 7:11 AM Stuart Marks wrote: >> >> On 1/23/19 12:05 PM, Jan Peter Stotz wrote: >>> like many other I ran into bug JDK-698217 which is about AbstractSet.removeAll() >>> and it's "aptitude" in wasting CPU time if you accidentally hit this bug. And >>> there are hundred of developers hitting this bug every year. >>> >>> I simply don't understand why there was no progress in 8 years, on a severe >>> performance issue (a removeAll method on an efficient set that can require >>> O(n^2)!) caused by code that was written to speed-up the removeAll implementation. >>> >>> Which makes this bug worse is that it is triggered by the relative size of the >>> current set compared to the collection passed as parameter. >>> Therefore for most developers this means not to use this buggy function at all >>> (once they realized how worse it is). >> >> I wasn't aware that hundreds of developers are hitting this bug every year. I >> haven't seen any mention of it (besides in the bug database) on Twitter, on >> Reddit, on DZone, at the conferences I attend, or in several years of >> core-libs-dev emails. Well, it was mentioned on core-libs-dev once in 2011 [1] >> although that was a suggestion for improvement, not a complaint about performance. >> >> Nonetheless this is a real problem, and if it's causing difficulties we can >> certainly take a look at it. >> >> There is, however, more to the story. The ACTUAL problem is a semantic one; see >> JDK-6394757. [2] Briefly, consider x.removeAll(y). Depending on the relative >> sizes of x and y, this method might end up using either x's or y's definition of >> membership, which could differ from each other. (See the bug report for an >> example.) Thus the semantics of this method depend upon the relative sizes of >> the collections, which is arguably flawed. >> >> Worse, this behavior is specified to iterate this set or the argument, depending >> upon their relative sizes. [3] So, fixing this will require an incompatible >> specification change. >> >> The obvious way to fix this is to get rid of the "optimizations" (that turn out >> not to be optimizations at all in some cases) and replace it with a simple loop: >> >> ????? public boolean removeAll(Collection c) { >> ????????? Objects.requireNonNull(c); >> ????????? boolean modified = false; >> ????????? for (Object e : c) >> ????????????? modified |= remove(e); >> ????????? return modified; >> ????? } >> >> I would argue that iterating the argument and calling remove() on "this" are the >> right semantics, because you want set membership to be determined by this set, >> not by whatever collection you pass as an argument. However, I note that >> AbstractCollection.removeAll and other removeAll implementations iterate over >> "this" and do a contains() check on the argument. The revised >> AbstractSet.removeAll would be an outlier here, though it makes sense to me to >> do it this way. >> >> Is it worth the incompatibility? >> >> s'marks >> >> >> >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html >> >> [2] https://bugs.openjdk.java.net/browse/JDK-6394757 >> >> [3] >> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/AbstractSet.html#removeAll(java.util.Collection) >> > > From javalists at cbfiddle.com Thu Feb 14 03:22:37 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 13 Feb 2019 19:22:37 -0800 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> Message-ID: <220EE759-20E8-429D-AA4B-CC5D4115CA7E@cbfiddle.com> If we take this route, how about changing the parameter type to Iterable? Alan > On Feb 13, 2019, at 7:12 PM, Stuart Marks wrote: > > Right, as I mentioned in my earlier emails [1][2] this is related to JDK-6394757 [3] where the semantics shift depending on the relative sizes of the collections. This has a complicated history. In JDK-6982173 [4] there is a lot of discussion about what heuristics to use for iterating this vs the arg, in order to get the best performance. This assumes that these operations are equivalent, when they aren't! In JDK-6394757 there's some discussion about the dubious semantics of this optimization and the potential of simply removing it. > > At this point I think we need to remove the performance heurstic in order to get consistent semantics. The performance won't be optimal -- indeed, it wasn't before -- but at least it should be more predictable. > > Your example is indeed counterintuitive, as it uses the contains() semantics of the argument -- the string length -- instead of the contains() semantics of "this". However, it's defensible, and it's supported by the spec, so I don't really see any alternative. > > The example set is pretty counterintuitive in the first place. For example: > > jshell> Set set = new TreeSet<>(Comparator.comparingInt(String::length)) > jshell> set.addAll(List.of("a", "if", "the", "when")) > jshell> set > set ==> [a, if, the, when] > jshell> set.contains("foo") > $235 ==> true > > Also, this comparator isn't consistent with equals. This isn't a bug. But it does give rise to even more counterintuitive behavior: > > jshell> var set2 = Set.of("x", "xx", "xxx", "xxxx") > jshell> set2.equals(set) > $237 ==> false > jshell> set.equals(set2) > $238 ==> true > > Fun with collections! :-) > > s'marks > > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058172.html > > [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058539.html > > [3] https://bugs.openjdk.java.net/browse/JDK-6394757 > > [4] https://bugs.openjdk.java.net/browse/JDK-6982173 > > > On 2/11/19 2:23 PM, Michael Rasmussen wrote: >> The current implementation seems very counter-intuitive with anything that doesn't have the same comparison semantics, for instance a TreeSet/Map with a Comparator, Identity-based Set/Map etc. >> The output of the following snippet would probably surprise most: >> /* --- snip --- */ >> import java.util.*; >> class Test { >> public static void main(String[] args) { >> TreeMap> lengthMap = new TreeMap<>(Comparator.comparingInt(String::length)); >> List strings = new ArrayList<>(Arrays.asList("The quick brown fox jumps over the lazy dog".split(" "))); >> for (String s : strings) { >> lengthMap.computeIfAbsent(s, k -> new ArrayList<>()).add(s); >> } >> Set toRemove = lengthMap.keySet(); >> System.out.println("List before: " + strings); >> System.out.println("Set to remove: " + toRemove); >> strings.removeAll(toRemove); >> System.out.println("List after:" + strings); >> } >> } >> /* --- snip --- */ >> List before: [The, quick, brown, fox, jumps, over, the, lazy, dog] >> Set to remove: [The, over, quick] >> List after:[] >> /Michael >> From: core-libs-dev on behalf of Tagir Valeev >> Sent: 08 February 2019 15:13 >> To: Stuart Marks >> Cc: core-libs-dev; Jan Peter Stotz >> Subject: Re: JDK-6982173: Small problem causing thousands of wasted CPU hours >> Hello! >>> I would argue that iterating the argument and calling remove() on "this" are the >>> right semantics, because you want set membership to be determined by this set, >>> not by whatever collection you pass as an argument. However, I note that >>> AbstractCollection.removeAll and other removeAll implementations iterate over >>> "this" and do a contains() check on the argument. The revised >>> AbstractSet.removeAll would be an outlier here, though it makes sense to me to >>> do it this way. >> For complete picture it should be noted that there's a slight >> difference in remove and removeAll spec: remove removes at most one >> element while removeAll removes all elements from the specified >> collection. >> E.g. c.removeAll(Collections.singleton(foo)) would remove all >> instances of foo from c while c.remove(foo) would return only one foo. >> These should be equivalent for Set where repeating elements should not >> normally appear, but it's wrong for any Collection. That's why >> AbstractCollection.removeAll >> cannot be rewritten in the same way. >> Another interesting thing is >> java.util.IdentityHashMap.KeySet#removeAll implementation [1]: >> it reimplements the AbstractCollection#removeAll, because of the same >> reason: now >> the first branch of AbstractSet#removeAll becomes incorrect. See the >> comment before it: >> /* >> * Must revert from AbstractSet's impl to AbstractCollection's, as >> * the former contains an optimization that results in incorrect >> * behavior when c is a smaller "normal" (non-identity-based) Set. >> */ >> Btw this comment should be updated to remove a "smaller" condition if >> the proposed >> change for AbstractSet will be implemented. >> [1] http://hg.openjdk.java.net/jdk/jdk/file/e57bcfd7bf79/src/java.base/share/classes/java/util/IdentityHashMap.java#l990 >> With best regards, >> Tagir Valeev >> On Fri, Jan 25, 2019 at 7:11 AM Stuart Marks wrote: >>> >>> On 1/23/19 12:05 PM, Jan Peter Stotz wrote: >>>> like many other I ran into bug JDK-698217 which is about AbstractSet.removeAll() >>>> and it's "aptitude" in wasting CPU time if you accidentally hit this bug. And >>>> there are hundred of developers hitting this bug every year. >>>> >>>> I simply don't understand why there was no progress in 8 years, on a severe >>>> performance issue (a removeAll method on an efficient set that can require >>>> O(n^2)!) caused by code that was written to speed-up the removeAll implementation. >>>> >>>> Which makes this bug worse is that it is triggered by the relative size of the >>>> current set compared to the collection passed as parameter. >>>> Therefore for most developers this means not to use this buggy function at all >>>> (once they realized how worse it is). >>> >>> I wasn't aware that hundreds of developers are hitting this bug every year. I >>> haven't seen any mention of it (besides in the bug database) on Twitter, on >>> Reddit, on DZone, at the conferences I attend, or in several years of >>> core-libs-dev emails. Well, it was mentioned on core-libs-dev once in 2011 [1] >>> although that was a suggestion for improvement, not a complaint about performance. >>> >>> Nonetheless this is a real problem, and if it's causing difficulties we can >>> certainly take a look at it. >>> >>> There is, however, more to the story. The ACTUAL problem is a semantic one; see >>> JDK-6394757. [2] Briefly, consider x.removeAll(y). Depending on the relative >>> sizes of x and y, this method might end up using either x's or y's definition of >>> membership, which could differ from each other. (See the bug report for an >>> example.) Thus the semantics of this method depend upon the relative sizes of >>> the collections, which is arguably flawed. >>> >>> Worse, this behavior is specified to iterate this set or the argument, depending >>> upon their relative sizes. [3] So, fixing this will require an incompatible >>> specification change. >>> >>> The obvious way to fix this is to get rid of the "optimizations" (that turn out >>> not to be optimizations at all in some cases) and replace it with a simple loop: >>> >>> public boolean removeAll(Collection c) { >>> Objects.requireNonNull(c); >>> boolean modified = false; >>> for (Object e : c) >>> modified |= remove(e); >>> return modified; >>> } >>> >>> I would argue that iterating the argument and calling remove() on "this" are the >>> right semantics, because you want set membership to be determined by this set, >>> not by whatever collection you pass as an argument. However, I note that >>> AbstractCollection.removeAll and other removeAll implementations iterate over >>> "this" and do a contains() check on the argument. The revised >>> AbstractSet.removeAll would be an outlier here, though it makes sense to me to >>> do it this way. >>> >>> Is it worth the incompatibility? >>> >>> s'marks >>> >>> >>> >>> >>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-6394757 >>> >>> [3] >>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/AbstractSet.html#removeAll(java.util.Collection) >>> >> > From stuart.marks at oracle.com Thu Feb 14 05:07:37 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 13 Feb 2019 21:07:37 -0800 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: <220EE759-20E8-429D-AA4B-CC5D4115CA7E@cbfiddle.com> References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> <220EE759-20E8-429D-AA4B-CC5D4115CA7E@cbfiddle.com> Message-ID: <6636354e-99af-87d1-e80a-52f8e45f69f1@oracle.com> On 2/13/19 7:22 PM, Alan Snyder wrote: > If we take this route, how about changing the parameter type to Iterable? Won't work. Where I've ended up is that we need to iterate over "this" collection and, for each element, call contains() on the parameter. The AbstractCollection.removeAll() implementation does something like this: removeAll(Collection c) { for (Iterator it = iterator(); it.hasNext();) { if (c.contains(it.next())) { it.remove(); } } } Since we call contains() on the parameter, it has to be a Collection. s'marks From christoph.langer at sap.com Thu Feb 14 07:54:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 14 Feb 2019 07:54:16 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <3854DFE0-C244-4920-9554-65F6401438BF@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <818ca9a7fe2445638dddc2481f95f9f8@sap.com> <3854DFE0-C244-4920-9554-65F6401438BF@oracle.com> Message-ID: Hi Lance, thanks for the detailed explanation, sounds great. I?ll work that in in my next edition ?? Best regards Christoph From: Lance Andersen Sent: Mittwoch, 13. Februar 2019 23:53 To: Langer, Christoph Cc: Alan Bateman ; nio-dev ; Java Core Libs ; OpenJDK Dev list ; Volker Simonis Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions Hi Christoph On Feb 13, 2019, at 5:30 PM, Langer, Christoph > wrote: Hi Lance, thanks for looking. Just starting to take a peek at this and noticed one quick thing in your test: ------------ Paths.get(System.getProperty("test.dir", "."), "testPosix.zip") ?????? You do not need the test.dir property or the permission added to test.policy to access it, just reference the jar and it will be created in user.dir which is also writable. Hm, I thought I didn't want to mess around in "user.dir" as it can be some more global directory where you wouldn't want to leave artefacts... To me "test.dir" feels cleaner. Are there other opinions about that? user.dir points to the scratch directory that test uses, so it is where you want to create the tests. Workspaces can sometimes be read only: For example: ?????? @Test public void test000() throws IOException { System.out.println("test.dir = " + System.getProperty("test.dir", ".")); System.out.println("user.dir = " + System.getProperty("user.dir", ".")); System.out.println( Paths.get(System.getProperty("test.dir", "."), "basic.jar").toAbsolutePath() ); } ----------------- Results in: -------------------- test.dir = . user.dir = /Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch /Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/./basic.jar Please see http://openjdk.java.net/jtreg/tag-spec.html for the system properties. I do not see test.dir there. ????????? I would just do: ????????? Path foo = Path.of("test.zip"); System.out.println("test.zip path=" + foo.toAbsolutePath()); -------------------------- which results in the output: test.zip path=/Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/test.zip 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 Thu Feb 14 11:16:56 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 14 Feb 2019 11:16:56 +0000 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: <85b88a8c-0925-25ff-dedb-2ec3d588c841@oracle.com> References: <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: Hi Mandy, Apologies for the delay. Could you review this cdiff as a proposal for the jtreg test? Made sense to modify the existing test set for MethodHandle rather than add a new one. ------------------------------------------------ test/jdk/java/lang/invoke/MethodHandlesGeneralTest.java *** 830,844 **** --- 830,860 ---- public void testUnreflectSetter() throws Throwable { CodeCacheOverflowProcessor.runMHTest(this::testUnreflectSetter0); } public void testUnreflectSetter0() throws Throwable { + //First we test the newer "static final field" behaviour. + testUnreflectSetterStaticFinalField(); + //Now we test the more proven functionality. if (CAN_SKIP_WORKING) return; startTest("unreflectSetter"); testSetter(TEST_UNREFLECT); } + static final int staticFinalField = 0; + public void testUnreflectSetterStaticFinalField() throws Throwable { + try { + Lookup l = MethodHandles.lookup(); + Field f = MethodHandlesGeneralTest.class.getDeclaredField("staticFinalField"); + f.setAccessible(true); + MethodHandle s = l.unreflectSetter(f); + throw new RuntimeException("MethodHandle.Lookup.unreflectSetter(Field) failed to throw IAE when Field is static and final."); + } catch (IllegalAccessException e) { + // IllegalAccessException expected. + } + } + @Test public void testFindSetter() throws Throwable { CodeCacheOverflowProcessor.runMHTest(this::testFindSetter0); } ------------------------------------------------ Best Regards Adam Farley IBM Runtimes Mandy Chung wrote on 31/01/2019 18:58:25: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 31/01/2019 18:58 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > > > On 1/31/19 4:18 AM, Adam Farley8 wrote: > > Hi Mandy, > > > > I've made the changes to the webrev and uploaded the corrected version. > > > > I've also uploaded the zips in the csr and bug. > > > > As for the test, I have mentioned that the test is attached to the bug. > > I attached the same test to the CSR. > > I did look at that but it's not a jtreg regression test. I assume > you planned to convert it to jtreg test. Anyway, the test attached > in the bug report is the reproducer of the bug. > > It would help the reviewer to include the regression test in > the webrev along with the fix unless a test is not necessary. > The OpenJDK developer guide gives a pretty good overview on the > process [1] and please do ask if you have any question. > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__openjdk.java.net_guide_changePlanning.html-23bug&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=uZYDsYv1Pe21YaYk_fuEwKg7Cc5a9sdsiGMPjDqgT5k&s=mvs_zaoLuTOUkmdByobfKcpvovlTEiHtNcz- > UMc3d70&e= > > > Are you saying that the test supplied is not a suitable test? > > TestStaticFinal.java is a standalone test. It needs to convert > to a jtreg regression test. > > The regression should throw an exception if Lookup::unreflectSetter > returns MH on a static final field with and without accessible flag > set. However TestStaticFinal.java also exits with 0. The regression > test should pass with your bug and fail without the fix (throwing > an exception). > > This test verifies unreflectSetter on a static final field. I > suggest it also includes a case with instance final field with > and without accessible flag set to show the exception for > unreflectSetter what case allows setting final fields. > > Mandy > [1] https://urldefense.proofpoint.com/v2/url? > u=http-3A__openjdk.java.net_guide_changePlanning.html-23bug&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=uZYDsYv1Pe21YaYk_fuEwKg7Cc5a9sdsiGMPjDqgT5k&s=mvs_zaoLuTOUkmdByobfKcpvovlTEiHtNcz- > UMc3d70&e= > P.S. should be updated to refer to CSR that replaced CCC. > 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 Alan.Bateman at oracle.com Thu Feb 14 13:41:05 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Feb 2019 13:41:05 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <21cfb27e67514b26a4505c589adf2781@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <21cfb27e67514b26a4505c589adf2781@sap.com> Message-ID: <5397dcad-bc93-618f-6a30-c3b1227b2b9e@oracle.com> On 13/02/2019 22:26, Langer, Christoph wrote: > : >> Also the "Zip" view of file attributes will need to be fleshed out more >> (the view name for example). > I don't know if that's really necessary as the "Zip" view currently is internal to jdk.zips and I don't propose to export it. Not exporting it is fine but are you planning to document "zip:storedPermissions"? The version I looked at did document "storedPermissions" which amounts to zipfs documenting an interface. > >> I'm not sure about using ${user.name} and "" as default. >> Have you looked at using the zip file owner/group (or owner/owner on >> Windows) as the default? > Hm, I guess for Unix that'd be ok. But how would I get to the owner of a file in Window's default file system? The zip provider can use Files.getOwner and that can be used for group when PosixFileAttributeView isn't supported by the file system containing the zip file. > : > I'll try to address these points in a next iteration. Great, I think the finial line on this feature isn't too far away. -Alan From goetz.lindenmaier at sap.com Thu Feb 14 16:35:16 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Feb 2019 16:35:16 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> Message-ID: <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> Hi Roger, > Maybe 10 years ago, when native was the only solution. > Now there are tools to analyze bytecode in java. I'm working on a Java implementation. > > Peter Levart proposed to initialize the message with a sentinel instead. > > I'll implement this as a proposal. > That's an extra overhead too, any assignment is. Yes, any code requires some run time. But I think this really is negligible in comparison to generating the backtrace, which happens on every exception. But I'm fine with the 'always recompute, no serialization' solution. If it turns out to be limited, it still can be changed easily. > > I guess we can go without. > > It would be possible to construct a case where two threads > > do getMessage() on the same NPE Object but the string is not > > the same. > Really!, if the bci is the same, the bytecode is the same, what could be different > that would change the data used to create the exception? e.getMessage().equals(e.getMessage()) will hold, but e.getMessage() != e.getMessage(). I just implemented the two variants of computing the message, they basically differ in NullPointerException.java: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/03-PeterLevart/ http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/04-RogerRiggs/ I also cleaned up the parameters passed as proposed. > > We uses this code since 2006, it needed only few changes. I would like to > > contribute a follow up for hidden frames of lambdas. > Valhalla and evolution of the byte code needs to be considered. > Just because its worked for years does not mean it's the best approach > today. Dropping it in now means maintaining it in its current form > or needing to re-write it later. Well, yes, that is true. For any change. For any project. We have heard this argument for many of our changes. I don't really think it's a good argument. As I understand Valhalla is not targeted for jdk13, and holding up changes for some future projects not really is the process of OpenJDK, is it? > > > The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a > > > question > > > about how useful the information is, developers should not need to know > > > about "slot 1". > > Developers should work with class files with debug information and then > > they would get the name printed. If exceptions are thrown in production > > code, any information is helpful. Should I just write "a local"? > Go back to who you think is going to benefit from it, it seems targeted > at a fairly novice developer, so exposing low level details may be more > confusing that just giving a line number and NPE. Especially on our improved NPE messages we always got good feedback from the developers within SAP. And there are quite some experienced people. Any message requires some background to be helpful. And I like to get any information I can have in first place. Attaching the debugger often is a big overhead. E.g., I look at about 50 failing jtreg tests every day, I don't want to get each into the debugger every time in the setup where it was running to see what is wrong ... E.g., com/sun/java/swing/plaf/windows/AltFocusIssueTest.java is failing in a headless environment with an NPE on this line: SwingUtilities.invokeAndWait(() -> frame.dispose()); With this change it said "while trying to invoke the method javax.swing.JFrame.dispose(()V) of a null object loaded from static field AltFocusIssueTest.frame" and I figured it's the fact we run headless that makes the test fail without even looking at the code. Best regards, Goetz From: Roger Riggs Sent: Dienstag, 12. Februar 2019 17:03 To: Lindenmaier, Goetz ; Java Core Libs Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. Hi, On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote: Hi Roger, thanks for looking at my change! A few higher level issues should be considered, though the details of the webrev captured my immediate attention. Is this the right feature Yes!! Maybe, that's what debuggers are for. and is this the right level of implementation (C++/native)? See below. Maybe 10 years ago, when native was the only solution. Now there are tools to analyze bytecode in java. From a security perspective, adding field names to exceptions exposes information to callers that they could not otherwise get and that breaks encapsulation. That needs to be evaluated. I can not comment on that. How can I trigger an evaluation of this? Who needs to evaluate this? I think there are ways to make this easier to implement and be easier to maintain and perform better. NullPointerException: 28: unused import of Field Removed 64: The lazyComputeMessage boolean should be inverted so it does not require ?? initialization, false is the default, anything else adds overhead. ?? And it may not be needed. Peter Levart proposed to initialize the message with a sentinel instead. I'll implement this as a proposal. That's an extra overhead too, any assignment is. 91: Why do you think synchonization is necessary?? It is a performance hit. ?? It is highly unlikely to be called from multiple threads and the value will ?? be the same whether it is computed once or multiple times by different threads. I guess we can go without. It would be possible to construct a case where two threads do getMessage() on the same NPE Object but the string is not the same. Really!, if the bci is the same, the bytecode is the same, what could be different that would change the data used to create the exception? 99: extendedMessage will never be null (so says the javadoc of getExtendedNPEMessage) ? Bug: If it does return null, then null is returned from getMessage ? regardless of the value of super.getMessage(). Fixed. 121: Simplify getExtendedNPEMessage by making it only responsible for the detail ? and not concatenation with an existing message.? Put that in getMessage(). Fixed. You are right, I only call this when the message is NULL. ? Its not strictly necessary to change the updated message with setMessage(). ? Avoiding that will avoid complexity and a performance hit. ? The message will be computed each time it is needed, and that happens infrequently. ? (Even in the serialization case, it will be re-computed from the attached stack frames). No, you can not recompute it from the stacktrace because that does not contain the BCI. Also, after deserialization, the bytecode might look different or not available at all. It depends on the actual bytecode that has been running when the exception was thrown. Right, I realized this too when thinking about it over the weekend. If a suitable low impact mechanism can't be found, then just go back to not exposing the extended message and use only the original. Its a bad idea to twist and contort the local design and accessibility just for serialization. What remote or delayed client needs to know this? ? And it avoids adding setMessage() to Throwable, that's significant change since ? the current implementation only allows the message to be initialized not updated. ? Immutable is an important characteristic to maintain. Yes, I don't like I have to set this. But it follows the same pattern as with the stack trace which is only computed on demand. Thus, Throwable is not immutable anyways. Before, I implemented this by a JNI call hiding this in the Java code. I proposed implementing setting the field by reflection, Christoph proposed a shared secret. David favored the package private setter. Please advice what is best. All of them are bad. Private needs to mean private. And making it mutable, also means that synchronization or volatile is needed to ensure a consistent value for getMessage().? That turns into a performance issue for all throwables. None of the above. That makes the writeReplace() unnecessary too. No. I need this, see above. See above, but is not essential to the core feature. Additional command line arguments are an unnecessary complexity, documentation, and maintenance overhead.? If the feature is as valuable as you suggest, it should be enabled all the time. Removed. I'm assuming there are no tests broken by the modification of the message. It is likely that somewhere an application or test looks at the message itself. Has that been verified? Our nightly testing runs the headless jdk and hostspot jtreg tests, jck tests and some other applications. They are all unaffected by this change after adapting the message in jtreg/vmTestbase/jit/t/t104/t104.gold. (win-x86_64, linux: ppc64, ppc64le, s390, x86_64, aarch, aix, solaris-sparc, mac) Also, I modified quite some messages before which didn't cause any follow-up breakages to my knowledge. It does seem unlikely. I can't speak for the hotspot code, but that seems to add a lot of code to support only this convenience feature.? That's a maintenance overhead and burden. We uses this code since 2006, it needed only few changes. I would like to contribute a follow up for hidden frames of lambdas. Valhalla and evolution of the byte code needs to be considered. Just because its worked for years does not mean its the best approach today.? Dropping it in now means maintaining it in its current form or needing to re-write it later. The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a question about how useful the information is,? developers should not need to know about "slot 1". Developers should work with class files with debug information and then they would get the name printed. If exceptions are thrown in production code, any information is helpful. Should I just write "a local"? Go back to who you think is going to benefit from it, it seems targeted at a fairly novice developer, so exposing low level details may be more confusing that just giving a line number and NPE. The test output of NullPointerExceptionTest shows "java.lang.Object.hashCode(()I)". Why is the argument type for Integer shown as "()I";? that's not the conventional representation of a primitive int. I already discussed this with David Holmes: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058464.html Other exceptions use the same format. I don't know of an utility in hotspot to translate the format to Java source code syntax. We implemented such an utility in our internal VM, though, and I would like to contribute this, too, adapting all the exceptions. I would do this in a follow-up. There may be better tools for formatting if it was done in java at a more appropriate level of abstraction. Generally, the explanations are too verbose. Method names and field names would be easier to recognize if they were quoted, as is done with 'this'.? Fixed, although this is not common in exception messages. See the messages in http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, line 57ff. Only the String of the name field is quoted, not any entities declared in the code. Similar http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runtime/LoaderConstraints/vtableAME/Test.java line 60, also showing the internal signature, see above. Argument numbers should be digits, not English words (first, second, etc) to make them easier to pick out. Fixed. And has it limits that do not read easily, e.g. "nr. 9". Sorry, I don't understand src/hotspot/share/classfile/bytecodeUtils.cpp:566 test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerExceptionTest.java:612 I would not describe 'this' as a local variable. Fixed. Tests, especially new tests should compile without warnings. NullPointerExceptionTest.java:125 newInstance has been deprecated. Fixed. The messages can be easier to understand, e.g. 'field a1 is null, trying to invoke a1.hashCode...' instead of: "while trying to invoke the method java.lang.Object.hashCode(()I) on a null reference loaded from local variable 'a1'" The message is built along the structure of the bytecode. I'll try to change this and then will come up with a new webrev . It will easier to understand if it looks more like the code. BTW, what does this look like for fully optimized code? You mean whether the bytecode is jitted? It's independent of how the code is executed, interpreted or compiled. Does it bear any resemblance to the source code at all? Or does it have to be deoptimized to come up with a sensible source reference. No, jitted methods must not be deoptimized. How much of this can be done in Java code with StackWalker and other java APIs? It would be a shame to add this much native code if there was a more robust way to implement it using APIs with more leverage. StackWalker operates on the Java stack tracke, which does not contain the BCI to my knowledge. Also, I need to read the bytecodes. Are there APIs to access the bytecode as it resides in the metaspace, rewritten, constants resolved etc? The code relies on this. From the other thread, beware adding overhead to the constructor. The lazy computation is essential. There are a *lot* of NPEs whose messages will never be needed. Regards, Roger Best regards, Goetz. Regards, Roger On 02/08/2019 09:13 AM, Langer, Christoph wrote: Hi Goetz, ok, so here a new webrev just adding a setter for the field: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 ... and incorporating the other comments. Looks better ?? I have a few additions to src/java.base/share/classes/java/lang/NullPointerException.java: 28 import java.lang.reflect.Field; 29 -> can be removed now. 91 synchronized (this) { -> I think this is not needed here. The transient modifier for lazyComputeMessage already implies the lock on the Object, I think. 108 return extendedMessage; -> I guess it would be more correct if you returned super.getMessage() here. Thanks Christoph From javalists at cbfiddle.com Thu Feb 14 17:30:35 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 14 Feb 2019 09:30:35 -0800 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: <6636354e-99af-87d1-e80a-52f8e45f69f1@oracle.com> References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> <220EE759-20E8-429D-AA4B-CC5D4115CA7E@cbfiddle.com> <6636354e-99af-87d1-e80a-52f8e45f69f1@oracle.com> Message-ID: <143497CB-8EC0-4940-BBAF-4485BC6FC147@cbfiddle.com> Right, I see that now. Care must be exercised if this method is used on collections that do not comply with the general contract for {@code Collection}. So, what does this mean? Are we catering to incorrect implementations? > On Feb 13, 2019, at 9:07 PM, Stuart Marks wrote: > > On 2/13/19 7:22 PM, Alan Snyder wrote: >> If we take this route, how about changing the parameter type to Iterable? > > Won't work. Where I've ended up is that we need to iterate over "this" collection and, for each element, call contains() on the parameter. The AbstractCollection.removeAll() implementation does something like this: > > removeAll(Collection c) { > for (Iterator it = iterator(); it.hasNext();) { > if (c.contains(it.next())) { > it.remove(); > } > } > } > > Since we call contains() on the parameter, it has to be a Collection. > > s'marks > From daniel.fuchs at oracle.com Thu Feb 14 19:10:59 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 14 Feb 2019 19:10:59 +0000 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable Message-ID: Hi, Please find below a doc fix for: 8216363: NullPointerException in java.util.logging.Handler#isLoggable https://bugs.openjdk.java.net/browse/JDK-8216363 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.00/index.html java.util.logging.Handler specifies that Handler.isLoggable(null) returns false. Unfortunately, the implementation throws NPE instead. For the sake of backward compatibility - it might be more prudent to simply alter the API specification to document the behavior of the default implementation, while allowing subclasses to change that behavior. In fact, one already does: StreamHandler::isLoggable(LogRecord) already returns false and doesn't throw NPE. best regards, -- daniel From lance.andersen at oracle.com Thu Feb 14 19:18:32 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 14 Feb 2019 14:18:32 -0500 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: References: Message-ID: Hi Daniel > On Feb 14, 2019, at 2:10 PM, Daniel Fuchs wrote: > > Hi, > > Please find below a doc fix for: > > 8216363: NullPointerException in java.util.logging.Handler#isLoggable > https://bugs.openjdk.java.net/browse/JDK-8216363 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.00/index.html > > java.util.logging.Handler specifies that Handler.isLoggable(null) > returns false. Unfortunately, the implementation throws NPE instead. > > For the sake of backward compatibility - it might be more > prudent to simply alter the API specification to document > the behavior of the default implementation, while allowing > subclasses to change that behavior. In fact, one already > does: StreamHandler::isLoggable(LogRecord) already returns > false and doesn't throw NPE. Documenting the current behavior as it has been makes the most sense to me as well Have you created a CSR yet? if so I will add myself as a reviewer? > > > best regards, > > -- daniel 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 daniel.fuchs at oracle.com Thu Feb 14 19:22:58 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 14 Feb 2019 19:22:58 +0000 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: References: Message-ID: <2c8dbf85-83c6-0fe4-1b0a-375e2521393a@oracle.com> Hi Lance, On 14/02/2019 20:18, Lance Andersen wrote: > Documenting the current behavior as it has been makes the most sense to > me as well > > Have you created a CSR yet? if so I will add myself as a reviewer? > I haven't created a CSR yet. This is a small low-priority fix - so it seemed preferable to wait for review comments before starting the CSR process. Thanks for volunteering for the CSR review, I'll ping you when I have it ;-) best regards, -- daniel From lance.andersen at oracle.com Thu Feb 14 19:26:19 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 14 Feb 2019 14:26:19 -0500 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: <2c8dbf85-83c6-0fe4-1b0a-375e2521393a@oracle.com> References: <2c8dbf85-83c6-0fe4-1b0a-375e2521393a@oracle.com> Message-ID: <00A66DA4-39E3-444E-BF51-0D83FA4A33A7@oracle.com> Hi Daniel, > On Feb 14, 2019, at 2:22 PM, Daniel Fuchs wrote: > > Hi Lance, > > On 14/02/2019 20:18, Lance Andersen wrote: >> Documenting the current behavior as it has been makes the most sense to me as well >> Have you created a CSR yet? if so I will add myself as a reviewer? > > I haven't created a CSR yet. > > This is a small low-priority fix - so it seemed preferable > to wait for review comments before starting the CSR process. Gotcha, I think your proposed wording is fine. > > Thanks for volunteering for the CSR review, I'll ping you when > I have it ;-) You are very welcome! > > best regards, > > -- daniel > > Best Lance 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 martinrb at google.com Thu Feb 14 19:33:49 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 14 Feb 2019 11:33:49 -0800 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> Message-ID: On Wed, Feb 13, 2019 at 6:45 PM Stuart Marks wrote: > > If we all agree on this, I'll proceed with working up a changeset for > JDK-6394757.[3] It's time to fix this one. > Thanks for taking on the fixing of this unfixable problem. It's important to do lots of documentation/guidance work, esp. a release note. Doug and I will take care of anything that needs doing in jsr166. In the real world, if performance is important, one might want to sort both collections (or use collections that are naturally sorted), then do a two-finger walk through both collections, funneling the results into a target collection. Which is N*log(N) + M*log(M) + N + M With enough work, that might be library-fiable. Hmmmmm ... Imagine ConcurrentSkipListSet.removeAll(aNavigableSet) ... Then by two-finger through both collections, advancing using higher/ceiling, you should get something like O(min(N*log(N), M*log(M))) If the argument is not sorted, then it is likely to be worth the effort of copying it into a sorted set (TreeSet with same comparator?). Software is hard. From mandy.chung at oracle.com Thu Feb 14 20:20:12 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Feb 2019 12:20:12 -0800 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: References: Message-ID: <71aa15a5-ac75-ee7a-f84d-d7ea2ee9098d@oracle.com> Hi Daniel, I wonder how a null LogRecord can be passed to Handler::isLoggable in the code path during logging. The package summary specifies that NPE will be thrown for null argument unless it's explicitly specified. Handler.isLoggable does specify to return false if LogRecord is null. If you change the spec to throw NPE if record is null, this impacts all callers of isLoggable(record) if any of them assumes it returns false if not. In addition, logging tends to be gracious as it's a cross-cutting concern and not to disturb the application runtime until it's a runtime issue. So I think isLoggable accepting null may be by design. Handler.publish(LogRecord) specifies to ignore null record and the implementation calls Handler.isLoggable(record). If the spec is changed to throw NPE, Handler::publish will need to change too. This impacts all APIs that accept null LogRecord while assuming isLoggable(null) returns false. I think normal logging purpose would pass non-null records otherwise this issue should have been reported long ago. Fixing the implementation of Handler::isLoggable to return false if null to match the specification seems similar risk to changing the spec. What do you think? Mandy On 2/14/19 11:10 AM, Daniel Fuchs wrote: > Hi, > > Please find below a doc fix for: > > 8216363: NullPointerException in java.util.logging.Handler#isLoggable > https://bugs.openjdk.java.net/browse/JDK-8216363 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.00/index.html > > java.util.logging.Handler specifies that Handler.isLoggable(null) > returns false. Unfortunately, the implementation throws NPE instead. > > For the sake of backward compatibility - it might be more > prudent to simply alter the API specification to document > the behavior of the default implementation, while allowing > subclasses to change that behavior. In fact, one already > does: StreamHandler::isLoggable(LogRecord) already returns > false and doesn't throw NPE. > > > best regards, > > -- daniel From daniel.fuchs at oracle.com Thu Feb 14 20:39:17 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 14 Feb 2019 20:39:17 +0000 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: <71aa15a5-ac75-ee7a-f84d-d7ea2ee9098d@oracle.com> References: <71aa15a5-ac75-ee7a-f84d-d7ea2ee9098d@oracle.com> Message-ID: <054c2067-604a-d7b9-7569-1d4a647a9232@oracle.com> Hi Mandy, On 14/02/19 20:20, Mandy Chung wrote: > Fixing the implementation of Handler::isLoggable to return false > if null to match the specification seems similar risk to changing > the spec.? What do you think? How so? I mean - if no line of code is changed, then surely we can't break existing code? But on second thought I believe I may have made the wrong choice her. See below... > In addition, logging tends to be gracious as it's a > cross-cutting concern and not to disturb the application runtime > until it's a runtime issue. So I think isLoggable accepting null > may be by design. I agree that returning false would be a much better implementation than throwing NPE. StreamHandler already does that. The only concrete implementation (in the JDK) of Handler that doesn't return false is the memory handler. > Handler.publish(LogRecord) specifies to ignore null record and > the implementation calls Handler.isLoggable(record). If the spec > is changed to throw NPE, Handler::publish will need to change > too. This impacts all APIs that accept null LogRecord while > assuming isLoggable(null) returns false. That is a good point. > I think normal logging purpose would pass non-null records > otherwise this issue should have been reported long ago. Well... That and the fact that FileHandler, ConsoleHandler, and friends are all StreamHandler (and return false). Maybe you're right - and changing the implementation is the right thing to do. Let me redo my fix and see if the JCK complains. Thanks for the feedback! best regards, -- daniel From mandy.chung at oracle.com Thu Feb 14 20:44:49 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Feb 2019 12:44:49 -0800 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: <054c2067-604a-d7b9-7569-1d4a647a9232@oracle.com> References: <71aa15a5-ac75-ee7a-f84d-d7ea2ee9098d@oracle.com> <054c2067-604a-d7b9-7569-1d4a647a9232@oracle.com> Message-ID: On 2/14/19 12:39 PM, Daniel Fuchs wrote: > Let me redo my fix and see if the JCK complains. I'd be surprised if there is a JCK test expecting NPE. Will see. I suggest to update @param record to say "a LogRecord or null" to be explicit. Mandy From alexander.matveev at oracle.com Fri Feb 15 03:31:03 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 14 Feb 2019 19:31:03 -0800 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files Message-ID: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Moved native code under platform specific folder. - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp for Mac specific code to filter out some arguments. I decided to keep it as is for now, since Mac specific code is small. - Defines are used in Platform.cpp to initialize platform specific classes. - Removed all pragma warning and fixed all compilation warnings. - Removed unused code. [1] https://bugs.openjdk.java.net/browse/JDK-8212091 [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ Thanks, Alexander From magnus.ihse.bursie at oracle.com Fri Feb 15 07:44:16 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Feb 2019 08:44:16 +0100 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> Message-ID: <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> On 2019-02-15 04:31, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Moved native code under platform specific folder. > - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. > - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp > for Mac specific code to filter out some arguments. I decided to keep > it as is for now, since Mac specific code is small. > - Defines are used in Platform.cpp to initialize platform specific > classes. > - Removed all pragma warning and fixed all compilation warnings. > - Removed unused code. > > [1] https://bugs.openjdk.java.net/browse/JDK-8212091 > > [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ The JDK standard is to use "unix", not "posix", for the shared functionality between linux/solaris/macosx. You can keep the name "PosixPlatform.*" if you want, though; the important thing is the directory name. Also, if you do that, you do not need any changes to make/lib/Lib-jdk.jpackage.gmk, since that will be automatically understood by the build system. It looks from the webrev that you have "moved" the files by doing "hg add" and "hg remove". Please use "hg move" instead -- this will keep history intact, and it allows reviewers to see if you have also made changes to the moved files. (If you do have modified the moved file, reverting a "hg add+hg remove" process is a bit more tricky -- you need to do "hg forget" on the new file, rename it to something else (otherwise "hg move" will complain), "hg revert" the old file back in place, do a "hg move" from the old to the new, and then copy the modified, renamed file back over the target new file again.) /Magnus > > Thanks, > Alexander From andy.herrick at oracle.com Fri Feb 15 15:30:02 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 15 Feb 2019 10:30:02 -0500 Subject: RFR: JDK-8217802: Invalid Option warning message. Message-ID: <37e94a30-2ee6-6a06-c75c-bfa7c8d689b8@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This is a simple fix to the unsupported Option warning message, and also fixes a problem when the new "--installer-type" option is used when not in "create-installer" mode. [1] https://bugs.openjdk.java.net/browse/JDK-8217802 [2] http://cr.openjdk.java.net/~herrick/8217802/ /Andy From adinn at redhat.com Fri Feb 15 16:51:53 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 15 Feb 2019 16:51:53 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> Message-ID: <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> The latest round of changes to the JEP and draft implementation are now available for review: JEP: http://openjdk.java.net/jeps/8207851 webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.05/ Latest Changes: After a very helpful discussion with Alan at FOSDEM I borrowed some hints from him and adjusted the JEP and the latest implementation to address concerns about adding more cruft to the current JDK APIs. The latest solution removes the extra MapMode enum values for SYNC mappings. Instead it makes the enum constructor for MapMode public, allowing JDK-internal FileChannel code to add some extra, extended MapMode tags that are recognized by FileChannel.map. An API class in package jdk.unsupported makes these enum values available for clients that want to perform SYNC maps. This minimizes yet further the changes to JDK public APIs. Thanks are very much due to Alan for explaining how to tease out the dependencies here. I also followed up Vladimir's suggestion regarding the implementation and initialised static long field Unsafe.CACHE_LINE_FLUSH_SIZE by injecting a value during JVM initialization rather than haing Unsafe call out via a native at clinit. I actually added a separate package-public class UnsafeConstants to own the static field and ran the initialize_class call and the do_local_static_fields fixup of static values on that class rather than on Unsafe. This should make it easy to add a follow up patch which injects some of the other static constants in Unsafe that are currently being accessed via native callouts (e.g. the page size). I believe I have also cleaned up the last few remaining issues in previous reviews -- especially: all uses of Persistent have now been replaced with Sync (apart from one comment where I am describing the behaviour of the NVRAM memory) 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, Eric Shander From chris.hegarty at oracle.com Fri Feb 15 17:13:27 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 15 Feb 2019 17:13:27 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> Message-ID: Hi Andrew, > On 15 Feb 2019, at 16:51, Andrew Dinn wrote: > > The latest round of changes to the JEP and draft implementation are now > available for review: > > JEP: http://openjdk.java.net/jeps/8207851 > webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.05/ I'm only following this issue at a high-level, but I have one suggestion that I think would help clarify the scope of this feature. If I understand the changes correctly, then the feature is actually accessed through the JDK-specific ExtendedMapMode READ_ONLY_SYNC and READ_WRITE_SYNC map modes. This kinda implies that the JEP should be scoped at the JDK level ( rather than Java SE ). I see that there are changes to the Java SE Platform, namely to the MapMode constructor and an overload of MappedByteBuffer::force. I see these more as "enablers" in support of this feature ( rather than the core of the feature itself ). They can happen as part of the same changeset, or could possibly be pushed separately upfront. If you agree, then the only action needed is to change the `Scope` of the JEP from `SE` to `JDK`. -Chris. From peter.levart at gmail.com Fri Feb 15 17:37:56 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 15 Feb 2019 18:37:56 +0100 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> Message-ID: Hi Goetz, Just a couple of things if you go that route (of placeholder String): ? 56???? private static final String MESSAGE_PLACEHOLDER = "NPE_MESSAGE_PLACEHOLDER"; Here, the initializer of that constant should create a private instance of String: ??? private static final String MESSAGE_PLACEHOLDER = new String("NPE_MESSAGE_PLACEHOLDER"); or even (since the content of the placeholder string doesn't matter - the identity does): ??? private static final String MESSAGE_PLACEHOLDER = new String(); ...or else anybody calling new NullPointerException("NPE_MESSAGE_PLACEHOLDER") will also be the subject of replacement since the string literals are interned constants. I.e.: "NPE_MESSAGE_PLACEHOLDER" == "NPE_MESSAGE_PLACEHOLDER" ? 81???? public String getMessage() { ? 82???????? String message = super.getMessage(); ? 83???????? if (message == MESSAGE_PLACEHOLDER) { ? 84???????????? message = getExtendedNPEMessage(); ? 85???????????? setMessage(message); ? 86???????? } ? 87???????? return super.getMessage(); ? 88???? } Why not simply returning 'message' local variable here? Regards, Peter On 2/14/19 5:35 PM, Lindenmaier, Goetz wrote: > Hi Roger, > >> Maybe 10 years ago, when native was the only solution. >> Now there are tools to analyze bytecode in java. > I'm working on a Java implementation. > >>> Peter Levart proposed to initialize the message with a sentinel instead. >>> I'll implement this as a proposal. >> That's an extra overhead too, any assignment is. > Yes, any code requires some run time. But I think this really is negligible > in comparison to generating the backtrace, which happens on every > exception. But I'm fine with the 'always recompute, no serialization' > solution. If it turns out to be limited, it still can be changed easily. > >>> I guess we can go without. >>> It would be possible to construct a case where two threads >>> do getMessage() on the same NPE Object but the string is not >>> the same. >> Really!, if the bci is the same, the bytecode is the same, what could be different >> that would change the data used to create the exception? > e.getMessage().equals(e.getMessage()) will hold, but > e.getMessage() != e.getMessage(). > > I just implemented the two variants of computing the message, they > basically differ in NullPointerException.java: > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/03-PeterLevart/ > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/04-RogerRiggs/ > > I also cleaned up the parameters passed as proposed. > >>> We uses this code since 2006, it needed only few changes. I would like to >>> contribute a follow up for hidden frames of lambdas. >> Valhalla and evolution of the byte code needs to be considered. >> Just because its worked for years does not mean it's the best approach >> today. Dropping it in now means maintaining it in its current form >> or needing to re-write it later. > Well, yes, that is true. For any change. For any project. We have heard > this argument for many of our changes. I don't really think it's a good > argument. As I understand Valhalla is not targeted for jdk13, and > holding up changes for some future projects not really is the process > of OpenJDK, is it? > >>>> The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a >>>> question >>>> about how useful the information is, developers should not need to know >>>> about "slot 1". >>> Developers should work with class files with debug information and then >>> they would get the name printed. If exceptions are thrown in production >>> code, any information is helpful. Should I just write "a local"? >> Go back to who you think is going to benefit from it, it seems targeted >> at a fairly novice developer, so exposing low level details may be more >> confusing that just giving a line number and NPE. > Especially on our improved NPE messages we always got good feedback > from the developers within SAP. And there are quite some experienced > people. Any message requires some background to be helpful. And I > like to get any information I can have in first place. Attaching the > debugger often is a big overhead. E.g., I look at about 50 failing jtreg > tests every day, I don't want to get each into the debugger every time > in the setup where it was running to see what is wrong ... > > E.g., com/sun/java/swing/plaf/windows/AltFocusIssueTest.java > is failing in a headless environment with an NPE on this line: > SwingUtilities.invokeAndWait(() -> frame.dispose()); > With this change it said "while trying to invoke the method javax.swing.JFrame.dispose(()V) of a null object loaded from static field AltFocusIssueTest.frame" and I figured it's the fact we run headless that > makes the test fail without even looking at the code. > > Best regards, > Goetz > > > > > > > > > From: Roger Riggs > Sent: Dienstag, 12. Februar 2019 17:03 > To: Lindenmaier, Goetz ; Java Core Libs > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. > > Hi, > On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote: > Hi Roger, > > thanks for looking at my change! > > A few higher level issues should be considered, though the details of > the webrev captured my immediate attention. > > Is this the right feature > Yes!! > Maybe, that's what debuggers are for. > > > > and is this the right level of implementation (C++/native)? > See below. > Maybe 10 years ago, when native was the only solution. > Now there are tools to analyze bytecode in java. > > > > From a security perspective, adding field names to exceptions exposes > information to callers that they could not otherwise get and that breaks > encapsulation. > That needs to be evaluated. > I can not comment on that. How can I trigger an evaluation of this? > Who needs to evaluate this? > > I think there are ways to make this easier to implement and be easier to > maintain and perform better. > > NullPointerException: > 28: unused import of Field > Removed > > 64: The lazyComputeMessage boolean should be inverted so it does not > require > ?? initialization, false is the default, anything else adds overhead. > ?? And it may not be needed. > Peter Levart proposed to initialize the message with a sentinel instead. > I'll implement this as a proposal. > That's an extra overhead too, any assignment is. > > > > 91: Why do you think synchonization is necessary?? It is a performance hit. > ?? It is highly unlikely to be called from multiple threads and the > value will > ?? be the same whether it is computed once or multiple times by > different threads. > I guess we can go without. > It would be possible to construct a case where two threads > do getMessage() on the same NPE Object but the string is not > the same. > Really!, if the bci is the same, the bytecode is the same, what could be different > that would change the data used to create the exception? > > > > 99: extendedMessage will never be null (so says the javadoc of > getExtendedNPEMessage) > ? Bug: If it does return null, then null is returned from getMessage > ? regardless of the value of super.getMessage(). > Fixed. > > 121: Simplify getExtendedNPEMessage by making it only responsible for > the detail > ? and not concatenation with an existing message.? Put that in > getMessage(). > Fixed. You are right, I only call this when the message is NULL. > > ? Its not strictly necessary to change the updated message with > setMessage(). > ? Avoiding that will avoid complexity and a performance hit. > ? The message will be computed each time it is needed, and that happens > infrequently. > ? (Even in the serialization case, it will be re-computed from the > attached stack frames). > No, you can not recompute it from the stacktrace because that > does not contain the BCI. Also, after deserialization, the bytecode > might look different or not available at all. It depends on the actual > bytecode that has been running when the exception was thrown. > Right, I realized this too when thinking about it over the weekend. > > If a suitable low impact mechanism can't be found, then just > go back to not exposing the extended message and use only the original. > Its a bad idea to twist and contort the local design and accessibility > just for serialization. What remote or delayed client needs to know this? > > > > > ? And it avoids adding setMessage() to Throwable, that's significant > change since > ? the current implementation only allows the message to be initialized > not updated. > ? Immutable is an important characteristic to maintain. > Yes, I don't like I have to set this. But it follows the same pattern > as with the stack trace which is only computed on demand. Thus, > Throwable is not immutable anyways. Before, I implemented this by a > JNI call hiding this in the Java code. > I proposed implementing setting the field by reflection, Christoph > proposed a shared secret. David favored the package private setter. > Please advice what is best. > All of them are bad. Private needs to mean private. > > And making it mutable, also means that synchronization or volatile > is needed to ensure a consistent value for getMessage(). > That turns into a performance issue for all throwables. > None of the above. > > > > That makes the writeReplace() unnecessary too. > No. I need this, see above. > See above, but is not essential to the core feature. > > > > Additional command line arguments are an unnecessary complexity, > documentation, and maintenance overhead.? If the feature is as valuable as > you suggest, it should be enabled all the time. > Removed. > > I'm assuming there are no tests broken by the modification of the message. > It is likely that somewhere an application or test looks at the message > itself. > Has that been verified? > Our nightly testing runs the headless jdk and hostspot jtreg tests, jck tests and some > other applications. They are all unaffected by this change after adapting the > message in jtreg/vmTestbase/jit/t/t104/t104.gold. > (win-x86_64, linux: ppc64, ppc64le, s390, x86_64, aarch, aix, solaris-sparc, mac) > Also, I modified quite some messages before which didn't cause any follow-up > breakages to my knowledge. > It does seem unlikely. > > > > I can't speak for the hotspot code, but that seems to add a lot of code > to support > only this convenience feature.? That's a maintenance overhead and burden. > We uses this code since 2006, it needed only few changes. I would like to > contribute a follow up for hidden frames of lambdas. > Valhalla and evolution of the byte code needs to be considered. > Just because its worked for years does not mean its the best approach > today.? Dropping it in now means maintaining it in its current form > or needing to re-write it later. > > > > The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a > question > about how useful the information is,? developers should not need to know > about "slot 1". > Developers should work with class files with debug information and then > they would get the name printed. If exceptions are thrown in production > code, any information is helpful. Should I just write "a local"? > Go back to who you think is going to benefit from it, it seems targeted > at a fairly novice developer, so exposing low level details may be more > confusing that just giving a line number and NPE. > > > > The test output of NullPointerExceptionTest shows > "java.lang.Object.hashCode(()I)". > Why is the argument type for Integer shown as "()I";? that's not the > conventional > representation of a primitive int. > I already discussed this with David Holmes: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058464.html > Other exceptions use the same format. I don't know of an utility in > hotspot to translate the format to Java source code syntax. We > implemented such an utility in our internal VM, though, and I would > like to contribute this, too, adapting all the exceptions. I would do this > in a follow-up. > There may be better tools for formatting if it was done in java at a > more appropriate level of abstraction. > > > > Generally, the explanations are too verbose. > Method names and field names would be easier to recognize if they were > quoted, as is done with 'this'. > Fixed, although this is not common in exception messages. See the > messages in http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, > line 57ff. Only the String of the name field is quoted, not any entities > declared in the code. > Similar http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runtime/LoaderConstraints/vtableAME/Test.java > line 60, also showing the internal signature, see above. > > Argument numbers should be digits, > not English words (first, second, etc) to make them easier to pick out. > Fixed. > And has it limits that do not read easily, e.g. "nr. 9". > Sorry, I don't understand > src/hotspot/share/classfile/bytecodeUtils.cpp:566 > test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerExceptionTest.java:612 > > I would not describe 'this' as a local variable. > Fixed. > > Tests, especially new tests should compile without warnings. > NullPointerExceptionTest.java:125 newInstance has been deprecated. > Fixed. > > The messages can be easier to understand, e.g. > 'field a1 is null, trying to invoke a1.hashCode...' instead of: > "while trying to invoke the method java.lang.Object.hashCode(()I) on a > null reference loaded from local variable 'a1'" > The message is built along the structure of the bytecode. > I'll try to change this and then will come up with a new webrev . > > It will easier to understand if it looks more like the code. > BTW, what does this look like for fully optimized code? > You mean whether the bytecode is jitted? It's independent > of how the code is executed, interpreted or compiled. > > Does it bear any resemblance to the source code at all? > Or does it have to be deoptimized to come up with a sensible source > reference. > No, jitted methods must not be deoptimized. > > How much of this can be done in Java code with StackWalker and other > java APIs? > It would be a shame to add this much native code if there was a more robust > way to implement it using APIs with more leverage. > StackWalker operates on the Java stack tracke, which does not contain the BCI > to my knowledge. Also, I need to read the bytecodes. Are there APIs to access > the bytecode as it resides in the metaspace, rewritten, constants resolved etc? > The code relies on this. > > From the other thread, beware adding overhead to the constructor. > The lazy computation is essential. > There are a *lot* of NPEs whose messages will never be needed. > > Regards, Roger > > > > > Best regards, > Goetz. > > > > Regards, Roger > > > On 02/08/2019 09:13 AM, Langer, Christoph wrote: > Hi Goetz, > > ok, so here a new webrev just adding a setter for the field: > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 > > ... and incorporating the other comments. > Looks better ?? > > I have a few additions to > src/java.base/share/classes/java/lang/NullPointerException.java: > > 28 import java.lang.reflect.Field; > 29 > -> can be removed now. > > 91 synchronized (this) { > -> I think this is not needed here. The transient modifier for > lazyComputeMessage already implies the lock on the Object, I think. > > 108 return extendedMessage; > -> I guess it would be more correct if you returned super.getMessage() here. > > Thanks > Christoph > > From stuart.marks at oracle.com Fri Feb 15 18:44:30 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 15 Feb 2019 10:44:30 -0800 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: <143497CB-8EC0-4940-BBAF-4485BC6FC147@cbfiddle.com> References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> <220EE759-20E8-429D-AA4B-CC5D4115CA7E@cbfiddle.com> <6636354e-99af-87d1-e80a-52f8e45f69f1@oracle.com> <143497CB-8EC0-4940-BBAF-4485BC6FC147@cbfiddle.com> Message-ID: On 2/14/19 9:30 AM, Alan Snyder wrote: >> Care must be exercised if this method is used on collections that >> do not comply with the general contract for {@code Collection}. > > So, what does this mean? Are we catering to incorrect implementations? I think this is a quote from the specification of Collections.disjoint(): > *

Care must be exercised if this method is used on collections that > * do not comply with the general contract for {@code Collection}. > * Implementations may elect to iterate over either collection and test > * for containment in the other collection (or to perform any equivalent > * computation). If either collection uses a nonstandard equality test > * (as does a {@link SortedSet} whose ordering is not compatible with > * equals, or the key set of an {@link IdentityHashMap}), both > * collections must use the same nonstandard equality test, or the > * result of this method is undefined. (Collections.disjoint() has similar issues to removeAll/retainAll but I don't think it's as important to fix, nor do I think it necessarily must be made consistent with them. But that's kind of a separate discussion.) I dislike the phrase "general contract" because it's, well, too general. I think it mainly refers to what I've been referring to as "contains() semantics" or "membership semantics". The rest of the paragraph refers to cases where a "nonstandard equality test" is used. I prefer to say that the membership semantics of things like IdentityHashMap and SortedSet differ from the membership semantics specified in the Set interface. Specifically, Set says sets contain no pair of elements e1 and e2 such that e1.equals(e2) whereas IdentityHashMap implies that it cannot contain any two keys k1 and k2 such that k1 == k2, and SortedSet should say that it contains no pair of elements e1 and e2 such that compare(e1, e2) == 0. (This last is the subject that JDK-8190545 is intended to address.) The upshot is that Collections.disjoint might not work as expected if it's used on collections that have different membership semantics. s'marks From daniel.fuchs at oracle.com Fri Feb 15 18:46:48 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 15 Feb 2019 18:46:48 +0000 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: References: <71aa15a5-ac75-ee7a-f84d-d7ea2ee9098d@oracle.com> <054c2067-604a-d7b9-7569-1d4a647a9232@oracle.com> Message-ID: <22d39d10-1889-474e-b5e5-30be633915e4@oracle.com> Hi Mandy, Here is the new webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.01/ It is much nicer than the previous version [1], but unfortunately it makes the following JCK tests fail: api/java_util/logging/MemoryHandler/IsLoggable.html api/java_util/logging/MemoryHandler/Publish.html These test expect the NPE even though the spec says that false should be returned. I believe there was some disconnect between the spec and the implementation at some point (see my archeological finds [2] and [3] below). So what should we do? Keep webrev.0.1, write CSR and release notes, and fix the JCK in 13? best regards, -- daniel [1] http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.00/ Additional archeological finds: [2] https://bugs.openjdk.java.net/browse/JDK-4769466 [3] https://bugs.openjdk.java.net/browse/JDK-4935768 On 14/02/2019 21:44, Mandy Chung wrote: > > > On 2/14/19 12:39 PM, Daniel Fuchs wrote: >> Let me redo my fix and see if the JCK complains. > > I'd be surprised if there is a JCK test expecting NPE. Will see. > > I suggest to update @param record to say "a LogRecord or null" > to be explicit. > > Mandy From lance.andersen at oracle.com Fri Feb 15 19:07:12 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 15 Feb 2019 14:07:12 -0500 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: <22d39d10-1889-474e-b5e5-30be633915e4@oracle.com> References: <71aa15a5-ac75-ee7a-f84d-d7ea2ee9098d@oracle.com> <054c2067-604a-d7b9-7569-1d4a647a9232@oracle.com> <22d39d10-1889-474e-b5e5-30be633915e4@oracle.com> Message-ID: Hi Daniel so it looks like it was an intentional decision to support the NPE but looks like an oversight to update the javadoc? I think you could go either way with this as I gotta believe their is a very low compatibility impact either way? > On Feb 15, 2019, at 1:46 PM, Daniel Fuchs wrote: > > Hi Mandy, > > Here is the new webrev: > > http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.01/ > > It is much nicer than the previous version [1], but unfortunately > it makes the following JCK tests fail: > > api/java_util/logging/MemoryHandler/IsLoggable.html > api/java_util/logging/MemoryHandler/Publish.html > > These test expect the NPE even though the spec says that false > should be returned. I believe there was some disconnect between > the spec and the implementation at some point (see my > archeological finds [2] and [3] below). > > So what should we do? > > Keep webrev.0.1, write CSR and release notes, and fix the > JCK in 13? > > best regards, > > -- daniel > > [1] http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.00/ > > Additional archeological finds: > > [2] https://bugs.openjdk.java.net/browse/JDK-4769466 > [3] https://bugs.openjdk.java.net/browse/JDK-4935768 > > > On 14/02/2019 21:44, Mandy Chung wrote: >> On 2/14/19 12:39 PM, Daniel Fuchs wrote: >>> Let me redo my fix and see if the JCK complains. >> I'd be surprised if there is a JCK test expecting NPE. Will see. >> I suggest to update @param record to say "a LogRecord or null" >> to be explicit. >> Mandy > 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 kevin.rushforth at oracle.com Fri Feb 15 19:22:17 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Feb 2019 11:22:17 -0800 Subject: RFR: JDK-8217802: Invalid Option warning message. In-Reply-To: <37e94a30-2ee6-6a06-c75c-bfa7c8d689b8@oracle.com> References: <37e94a30-2ee6-6a06-c75c-bfa7c8d689b8@oracle.com> Message-ID: Looks good. -- Kevin On 2/15/2019 7:30 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > This is a simple fix to the unsupported Option warning message, and > also fixes a problem when the new "--installer-type" option is used > when not in "create-installer" mode. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217802 > > [2] http://cr.openjdk.java.net/~herrick/8217802/ > > /Andy > From daniel.fuchs at oracle.com Fri Feb 15 19:20:30 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 15 Feb 2019 19:20:30 +0000 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: References: <71aa15a5-ac75-ee7a-f84d-d7ea2ee9098d@oracle.com> <054c2067-604a-d7b9-7569-1d4a647a9232@oracle.com> <22d39d10-1889-474e-b5e5-30be633915e4@oracle.com> Message-ID: <4e4a805d-7733-a1c6-7b20-662cf7bea033@oracle.com> Hi Lance, On 15/02/2019 20:07, Lance Andersen wrote: > Hi Daniel > > so it looks like it was an intentional decision to ?support the NPE but > looks like an oversight to update the javadoc? Well I guess it was intentional to return false for null in StreamHandlers and FileHandlers, but the spec said nothing about it. So JCK tests were written to catch NPE, and these tests failed for StremHandler and FileHandler. So the spec was modified to explicitly say that false would be returned for null, in Handler.java and all its subclasses, without noticing that only StreamHandlers and FileHandlers actually implemented that behavior. Then only the JCK tests for StreamHandlers and FileHandlers were changed - since they were the only ones failing. At least that's what these old issues I found make me think :-) So the spec update fixed one bug but introduced a new one :-( > I think you could go either way with this as I gotta believe their is a > very low compatibility impact either way? I hope so too. best regards, -- daniel From javalists at cbfiddle.com Fri Feb 15 19:30:56 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 15 Feb 2019 11:30:56 -0800 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> <220EE759-20E8-429D-AA4B-CC5D4115CA7E@cbfiddle.com> <6636354e-99af-87d1-e80a-52f8e45f69f1@oracle.com> <143497CB-8EC0-4940-BBAF-4485BC6FC147@cbfiddle.com> Message-ID: I think this situation is a mess. The ?general contract? of a Collection, I believe, is that it contains zero or more identified member objects, as defined by appropriate equals() method. I know this is hard to specify precisely, but I presume we all ?know it when we see it?. There is value to ?collections? whose members are not objects but are equivalence classes of objects, as defined by a nonstandard equality test, but I think it is a mistake to call them Collections. If a method takes a parameter of type Collection, it should be free to assume that the parameter object supports the ?general contract? of Collection. Is there any plausible alternative? Changing one method in the JDK to support a non-standard Collection parameter does not solve the problem, because non-JDK methods with Collection (etc.) parameters could have similar ?misbehavior?. How would the developer know when a specific TreeSet can or cannot be passed to a method? Does every method that accepts a Collection (etc.) parameter require boilerplate (as in the disjoint example) explaining its exact requirements or how it can go wrong? Perhaps it would be useful to define specific behaviors that these nonstandard ?collections? might support. For example, a Membership interface (with method contains(e)) would be perfect for a removeAll(Membership) method on Collection, implemented as you propose. Alan > On Feb 15, 2019, at 10:44 AM, Stuart Marks wrote: > > > > On 2/14/19 9:30 AM, Alan Snyder wrote: >>> Care must be exercised if this method is used on collections that >>> do not comply with the general contract for {@code Collection}. >> So, what does this mean? Are we catering to incorrect implementations? > > I think this is a quote from the specification of Collections.disjoint(): > >> *

Care must be exercised if this method is used on collections that >> * do not comply with the general contract for {@code Collection}. >> * Implementations may elect to iterate over either collection and test >> * for containment in the other collection (or to perform any equivalent >> * computation). If either collection uses a nonstandard equality test >> * (as does a {@link SortedSet} whose ordering is not compatible with >> * equals, or the key set of an {@link IdentityHashMap}), both >> * collections must use the same nonstandard equality test, or the >> * result of this method is undefined. > > (Collections.disjoint() has similar issues to removeAll/retainAll but I don't think it's as important to fix, nor do I think it necessarily must be made consistent with them. But that's kind of a separate discussion.) > > I dislike the phrase "general contract" because it's, well, too general. I think it mainly refers to what I've been referring to as "contains() semantics" or "membership semantics". The rest of the paragraph refers to cases where a "nonstandard equality test" is used. I prefer to say that the membership semantics of things like IdentityHashMap and SortedSet differ from the membership semantics specified in the Set interface. > > Specifically, Set says > > sets contain no pair of elements e1 and e2 such that e1.equals(e2) > > whereas IdentityHashMap implies that it cannot contain any two keys k1 and k2 such that k1 == k2, and SortedSet should say that it contains no pair of elements e1 and e2 such that compare(e1, e2) == 0. > > (This last is the subject that JDK-8190545 is intended to address.) > > The upshot is that Collections.disjoint might not work as expected if it's used on collections that have different membership semantics. > > s'marks > From philipp.kunz at paratix.ch Fri Feb 15 21:30:10 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Fri, 15 Feb 2019 22:30:10 +0100 Subject: Manifest ignores last line if not terminated by line break Message-ID: <1550266210.2497.16.camel@paratix.ch> Hi, Manifest parsing an input stream given to the constructor or the read method ignores the contents of the last line unless terminated with a line break. In course of my attempt to fix 8217375, I found that Manifest ignores the last line when not terminated with a line break whereas ManifestDigester throws an exception. Without ManifestDigester's different behavior, I'd have opted for parsing the last line also without a line break (or the last line being empty). But ManifestDigester cannot easily be changed that way, too, because the line breaks are part of the digested manifest portions. I don't think Manifest should accept any manifests that cannot later as well be signed and should therefore raise an error when there is no line break at the end of a manifest. Adding a new error condition adds potential for compatibility issues. On the other hand, I don't think the last 'ill'-terminated line should really be ignored silently. A good example how things can go wrong this way is JavaClassPathTest.java. It uses a one-line manifest without a trailing line break and m1.jar does not contain the expected Class-Path entry. In the long term the best option would probably be to re-unite Manifest's and ManifestDigester's parsing-related code the biggest challenge of which is not to change digests and thereby break existing jar signatures. Attached is a patch with a proposed fix. The bug number in test/jdk/java/util/jar/Manifest/NoLineBreakAtEndOfManifestFile.java is from another bug that lead me to it. If someone creates another bug it can be replaced. I haven't found an existing issue that matches. In test/jdk/tools/launcher/modules/classpath/JavaClassPathTest.java is a test case testJARManifestClassPathAttribute/testClassPathAttribute which I have no clue how this should really work. As far as I can tell the test is and was wrong but nevertheless passes. Is there a chance to find a sponsor for fixing this? Regards, Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: NoLineBreakAtEndOfManifestFile.patch Type: text/x-patch Size: 10796 bytes Desc: not available URL: From philipp.kunz at paratix.ch Fri Feb 15 21:43:09 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Fri, 15 Feb 2019 22:43:09 +0100 Subject: Faulty Null-Check Suspected in ToolProvider Message-ID: <1550266989.2497.19.camel@paratix.ch> Hi, There has always been an implicit null-check for args by the for loop attempting to iterate but the check seems to be intended and wrong for the elements. See attached patch. >From the comment to args, "the command-line arguments for the tool", I guess it makes sense to conclude that these should not be allowed to be null, just like on a command line, but empty strings are be fine. Regards, Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: ToolProviderNullCheck.patch Type: text/x-patch Size: 671 bytes Desc: not available URL: From alexander.matveev at oracle.com Fri Feb 15 22:21:15 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 15 Feb 2019 14:21:15 -0800 Subject: RFR: JDK-8217802: Invalid Option warning message. In-Reply-To: <37e94a30-2ee6-6a06-c75c-bfa7c8d689b8@oracle.com> References: <37e94a30-2ee6-6a06-c75c-bfa7c8d689b8@oracle.com> Message-ID: <1cc626e4-9d3c-389c-d558-a9968f95ed1d@oracle.com> Looks good. On 2/15/2019 7:30 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > This is a simple fix to the unsupported Option warning message, and > also fixes a problem when the new "--installer-type" option is used > when not in "create-installer" mode. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217802 > > [2] http://cr.openjdk.java.net/~herrick/8217802/ > > /Andy > From naoto.sato at oracle.com Fri Feb 15 22:55:11 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 15 Feb 2019 14:55:11 -0800 Subject: [13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO Message-ID: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8218960 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ The CONFIG message was generated because CLDRCalendarDataProviderImpl was returning null for locales without region. Use "US" as the default region in such a case. Naoto From andy.herrick at oracle.com Fri Feb 15 22:57:43 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 15 Feb 2019 17:57:43 -0500 Subject: jpackage Packaging Tool Early Access Update 3 Message-ID: A third EA build (Build 17) of jpackage tool is available at https://jdk.java.net/jpackage/ This release contains fixes to the following: JDK-8217894: jpackage CLI syntax changes JDK-8217792: Investigate what modules are included JDK-8217793: Modular jars in jpackage are not working JDK-8217687: jpackage --help improvements JDK-8214564: --win-upgrade-uuid does not work as expected JDK-8217317: Create jpackage native library for windows JDK-8217751: jpackage messages and failures JDK-8217331: Problems when space in application name JDK-8208404: Multiple Application Launcher JDK-8217269: jpackage Makefile improvments please send feedback to core-libs-dev at openjdk.java.net /Andy Herrick From lance.andersen at oracle.com Fri Feb 15 23:10:57 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 15 Feb 2019 18:10:57 -0500 Subject: Faulty Null-Check Suspected in ToolProvider In-Reply-To: <1550266989.2497.19.camel@paratix.ch> References: <1550266989.2497.19.camel@paratix.ch> Message-ID: <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> Hi Philipp This probably makes sense to update. Can you also update the ToolProviderTest.java to add a test for the changes Thank you Best Lance > On Feb 15, 2019, at 4:43 PM, Philipp Kunz wrote: > > 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 philipp.kunz at paratix.ch Fri Feb 15 23:59:39 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sat, 16 Feb 2019 00:59:39 +0100 Subject: Faulty Null-Check Suspected in ToolProvider In-Reply-To: <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> References: <1550266989.2497.19.camel@paratix.ch> <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> Message-ID: <1550275179.2497.21.camel@paratix.ch> A non-text attachment was scrubbed... Name: ToolProviderNullCheck.patch Type: text/x-patch Size: 2993 bytes Desc: not available URL: From alexander.matveev at oracle.com Sat Feb 16 03:03:00 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 15 Feb 2019 19:03:00 -0800 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> Message-ID: <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> Hi Magnus, http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ Moved all files from "posix" to "unix" folder and reverted Lib-jdk.jpackage.gmk changes. Webrev updated with files moved, instead of add/remove. Thanks, Alexander On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: > > > On 2019-02-15 04:31, Alexander Matveev wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> - Moved native code under platform specific folder. >> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. >> - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp >> for Mac specific code to filter out some arguments. I decided to keep >> it as is for now, since Mac specific code is small. >> - Defines are used in Platform.cpp to initialize platform specific >> classes. >> - Removed all pragma warning and fixed all compilation warnings. >> - Removed unused code. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8212091 >> >> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ > The JDK standard is to use "unix", not "posix", for the shared > functionality between linux/solaris/macosx. You can keep the name > "PosixPlatform.*" if you want, though; the important thing is the > directory name. > > Also, if you do that, you do not need any changes to > make/lib/Lib-jdk.jpackage.gmk, since that will be automatically > understood by the build system. > > It looks from the webrev that you have "moved" the files by doing "hg > add" and "hg remove". Please use "hg move" instead -- this will keep > history intact, and it allows reviewers to see if you have also made > changes to the moved files. > > (If you do have modified the moved file, reverting a "hg add+hg > remove" process is a bit more tricky -- you need to do "hg forget" on > the new file, rename it to something else (otherwise "hg move" will > complain), "hg revert" the old file back in place, do a "hg move" from > the old to the new, and then copy the modified, renamed file back over > the target new file again.) > > /Magnus >> >> Thanks, >> Alexander > From philipp.kunz at paratix.ch Sat Feb 16 08:20:22 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sat, 16 Feb 2019 09:20:22 +0100 Subject: Faulty Null-Check Suspected in ToolProvider In-Reply-To: <1550275179.2497.21.camel@paratix.ch> References: <1550266989.2497.19.camel@paratix.ch> <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> <1550275179.2497.21.camel@paratix.ch> Message-ID: <1550305222.2497.24.camel@paratix.ch> Hi again, I figured out and err deserve a null-check test as well. See patch. I'm wondering, if or how a similar check could be applied as well to ToolProvider.run(PrintWriter, PrintWriter, String...) which currently is implemented (hopefully) by each tool having to repeat the null-checks. I'm also wondering about the call to flush in run(PrintStream out, PrintStream err, String... args). It looks like the intention was to flush the wrapping PrintWriter. That is not possible without also flushing the underlying PrintStream. BufferedWriter.flushBuffer would be a more sensible method to call but is not accessible. The effect is actually, that the call to PrintWriter.flush will also call flush of the underlying PrintStream. Should that be documented more explicitly, for example: diff -r 7c17199fa37d src/java.base/share/classes/java/util/spi/ToolProvider.java --- a/src/java.base/share/classes/java/util/spi/ToolProvider.java Fri Feb 15 08:21:08 2019 -0500 +++ b/src/java.base/share/classes/java/util/spi/ToolProvider.java Sat Feb 16 09:17:46 2019 +0100 @@ -107,6 +107,8 @@ ??????* @implNote This implementation wraps the {@code out} and {@code err} ??????* streams within {@link PrintWriter}s, and then calls ??????* {@link #run(PrintWriter, PrintWriter, String[])}. +?????* Both {@code out} and {@code err} streams are flushed before the method +?????* returns as a side-effect of flushing the wrapping {@link PrintWriter}s. ??????* ??????* @param out a stream to which "expected" output should be written ??????* Regards, Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: ToolProviderNullCheck.patch Type: text/x-patch Size: 3721 bytes Desc: not available URL: From openjdk at icemanx.nl Sat Feb 16 12:52:02 2019 From: openjdk at icemanx.nl (Rob Spoor) Date: Sat, 16 Feb 2019 13:52:02 +0100 Subject: RFE: add missing methods to Optional, OptionalInt, OptionalLong and OptionalDouble Message-ID: <21c52039-aa2c-a625-a855-4012bbb1766f@icemanx.nl> I noticed that, while Stream and its primitive equivalents have multiple map and flapMap methods, Optional and its primitive equivalents were missing those. Since these can still be very useful, I wrote a patch to add the following methods: * Optional: mapToInt, mapToLong, mapToDouble, flatMapToInt, flatMapToLong, flatMapToDouble * OptionalInt: map, mapToObj, mapToLong, mapToDouble, flatMap * OptionalLong: map, mapToObj, mapToInt, mapToDouble, flatMap * OptionalDouble: map, mapToObj, mapToInt, mapToLong, flatMap I did not add any more flatMap methods to OptionalInt, OptionalLong and OptionalDouble because these also don't exist on IntStream, LongStream and DoubleStream. In addition, I also added the missing or method to OptionalInt, OptionalLong and OptionalDouble based on that of Optional. My OCA has been processed on 2019-01-22. Rob -------------- next part -------------- diff --git a/src/java.base/share/classes/java/util/Optional.java b/src/java.base/share/classes/java/util/Optional.java --- a/src/java.base/share/classes/java/util/Optional.java +++ b/src/java.base/share/classes/java/util/Optional.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -28,6 +28,9 @@ import java.util.function.Function; import java.util.function.Predicate; import java.util.function.Supplier; +import java.util.function.ToDoubleFunction; +import java.util.function.ToIntFunction; +import java.util.function.ToLongFunction; import java.util.stream.Stream; /** @@ -267,6 +270,69 @@ } /** + * If a value is present, returns an {@code OptionalInt} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalInt}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalInt} describing the result of applying a + * mapping function to the value of this {@code Optional}, if a + * value is present, otherwise an empty {@code Optional} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalInt mapToInt(ToIntFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalInt.empty(); + } else { + return OptionalInt.of(mapper.applyAsInt(value)); + } + } + + /** + * If a value is present, returns an {@code OptionalLong} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalLong}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalLong} describing the result of applying a + * mapping function to the value of this {@code Optional}, if a + * value is present, otherwise an empty {@code Optional} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalLong mapToLong(ToLongFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalLong.empty(); + } else { + return OptionalLong.of(mapper.applyAsLong(value)); + } + } + + /** + * If a value is present, returns an {@code OptionalDouble} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalDouble}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalDouble} describing the result of applying a + * mapping function to the value of this {@code Optional}, if a + * value is present, otherwise an empty {@code Optional} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalDouble mapToDouble(ToDoubleFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalDouble.empty(); + } else { + return OptionalDouble.of(mapper.applyAsDouble(value)); + } + } + + /** * If a value is present, returns the result of applying the given * {@code Optional}-bearing mapping function to the value, otherwise returns * an empty {@code Optional}. @@ -297,6 +363,90 @@ } /** + * If a value is present, returns the result of applying the given + * {@code OptionalInt}-bearing mapping function to the value, otherwise + * returns an empty {@code OptionalInt}. + * + *

This method is similar to {@link #mapToInt(ToIntFunction)}, but the + * mapping function is one whose result is already an {@code OptionalInt}, + * and if invoked, {@code flatMapToInt} does not wrap it within an + * additional {@code OptionalInt}. + * + * @param mapper the mapping function to apply to a value, if present + * @return the result of applying an {@code OptionalInt}-bearing mapping + * function to the value of this {@code Optional}, if a value is + * present, otherwise an empty {@code OptionalInt} + * @throws NullPointerException if the mapping function is {@code null} or + * returns a {@code null} result + * @since 13 + */ + public OptionalInt flatMapToInt(Function mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalInt.empty(); + } else { + OptionalInt r = mapper.apply(value); + return Objects.requireNonNull(r); + } + } + + /** + * If a value is present, returns the result of applying the given + * {@code OptionalLong}-bearing mapping function to the value, otherwise + * returns an empty {@code OptionalLong}. + * + *

This method is similar to {@link #mapToLong(ToLongFunction)}, but the + * mapping function is one whose result is already an {@code OptionalLong}, + * and if invoked, {@code flatMapToLong} does not wrap it within an + * additional {@code OptionalLong}. + * + * @param mapper the mapping function to apply to a value, if present + * @return the result of applying an {@code OptionalLong}-bearing mapping + * function to the value of this {@code Optional}, if a value is + * present, otherwise an empty {@code OptionalLong} + * @throws NullPointerException if the mapping function is {@code null} or + * returns a {@code null} result + * @since 13 + */ + public OptionalLong flatMapToLong(Function mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalLong.empty(); + } else { + OptionalLong r = mapper.apply(value); + return Objects.requireNonNull(r); + } + } + + /** + * If a value is present, returns the result of applying the given + * {@code OptionalDouble}-bearing mapping function to the value, otherwise + * returns an empty {@code OptionalDouble}. + * + *

This method is similar to {@link #mapToDouble(ToDoubleFunction)}, but + * the mapping function is one whose result is already an + * {@code OptionalDouble}, and if invoked, {@code flatMapToDouble} does not + * wrap it within an additional {@code OptionalDouble}. + * + * @param mapper the mapping function to apply to a value, if present + * @return the result of applying an {@code OptionalDouble}-bearing mapping + * function to the value of this {@code Optional}, if a value is + * present, otherwise an empty {@code OptionalDouble} + * @throws NullPointerException if the mapping function is {@code null} or + * returns a {@code null} result + * @since 13 + */ + public OptionalDouble flatMapToDouble(Function mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalDouble.empty(); + } else { + OptionalDouble r = mapper.apply(value); + return Objects.requireNonNull(r); + } + } + + /** * If a value is present, returns an {@code Optional} describing the value, * otherwise returns an {@code Optional} produced by the supplying function. * diff --git a/src/java.base/share/classes/java/util/OptionalDouble.java b/src/java.base/share/classes/java/util/OptionalDouble.java --- a/src/java.base/share/classes/java/util/OptionalDouble.java +++ b/src/java.base/share/classes/java/util/OptionalDouble.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -25,7 +25,11 @@ package java.util; import java.util.function.DoubleConsumer; +import java.util.function.DoubleFunction; import java.util.function.DoubleSupplier; +import java.util.function.DoubleToIntFunction; +import java.util.function.DoubleToLongFunction; +import java.util.function.DoubleUnaryOperator; import java.util.function.Supplier; import java.util.stream.DoubleStream; @@ -185,6 +189,146 @@ } /** + * If a value is present, returns an {@code OptionalDouble} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalDouble}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalDouble} describing the result of applying a + * mapping function to the value of this {@code OptionalDouble}, if + * a value is present, otherwise an empty {@code OptionalDouble} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalDouble map(DoubleUnaryOperator mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalDouble.empty(); + } else { + return OptionalDouble.of(mapper.applyAsDouble(value)); + } + } + + /** + * If a value is present, returns an {@code Optional} describing (as if by + * {@link Optional#ofNullable}) the result of applying the given mapping + * function to the value, otherwise returns an empty {@code Optional}. + * + *

If the mapping function returns a {@code null} result then this method + * returns an empty {@code Optional}. + * + * @param mapper the mapping function to apply to a value, if present + * @param The type of the value returned from the mapping function + * @return an {@code Optional} describing the result of applying a mapping + * function to the value of this {@code OptionalDouble}, if a value + * is present, otherwise an empty {@code Optional} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public Optional mapToObj(DoubleFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return Optional.empty(); + } else { + return Optional.ofNullable(mapper.apply(value)); + } + } + + /** + * If a value is present, returns an {@code OptionalInt} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalInt}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalInt} describing the result of applying a + * mapping function to the value of this {@code OptionalDouble}, if + * a value is present, otherwise an empty {@code OptionalInt} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalInt mapToInt(DoubleToIntFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalInt.empty(); + } else { + return OptionalInt.of(mapper.applyAsInt(value)); + } + } + + /** + * If a value is present, returns an {@code OptionalLong} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalLong}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalLong} describing the result of applying a + * mapping function to the value of this {@code OptionalDouble}, if + * a value is present, otherwise an empty {@code OptionalLong} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalLong mapToLong(DoubleToLongFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalLong.empty(); + } else { + return OptionalLong.of(mapper.applyAsLong(value)); + } + } + + /** + * If a value is present, returns the result of applying the given + * {@code OptionalDouble}-bearing mapping function to the value, otherwise + * returns an empty {@code OptionalDouble}. + * + *

This method is similar to {@link #map(DoubleUnaryOperator)}, but the + * mapping function is one whose result is already an + * {@code OptionalDouble}, and if invoked, {@code flatMap} does not wrap it + * within an additional {@code OptionalDouble}. + * + * @param mapper the mapping function to apply to a value, if present + * @return the result of applying an {@code OptionalDouble}-bearing mapping + * function to the value of this {@code OptionalDouble}, if a value + * is present, otherwise an empty {@code OptionalDouble} + * @throws NullPointerException if the mapping function is {@code null} or + * returns a {@code null} result + * @since 13 + */ + public OptionalDouble flatMap(DoubleFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalDouble.empty(); + } else { + OptionalDouble r = mapper.apply(value); + return Objects.requireNonNull(r); + } + } + + /** + * If a value is present, returns an {@code OptionalDouble} describing the + * value, otherwise returns an {@code OptionalDouble} produced by the supplying + * function. + * + * @param supplier the supplying function that produces an + * {@code OptionalDouble} to be returned + * @return returns an {@code OptionalDouble} describing the value of this + * {@code OptionalDouble}, if a value is present, otherwise an + * {@code OptionalDouble} produced by the supplying function. + * @throws NullPointerException if the supplying function is {@code null} or + * produces a {@code null} result + * @since 13 + */ + public OptionalDouble or(Supplier supplier) { + Objects.requireNonNull(supplier); + if (isPresent()) { + return this; + } else { + OptionalDouble r = supplier.get(); + return Objects.requireNonNull(r); + } + } + + /** * If a value is present, returns a sequential {@link DoubleStream} * containing only that value, otherwise returns an empty * {@code DoubleStream}. diff --git a/src/java.base/share/classes/java/util/OptionalInt.java b/src/java.base/share/classes/java/util/OptionalInt.java --- a/src/java.base/share/classes/java/util/OptionalInt.java +++ b/src/java.base/share/classes/java/util/OptionalInt.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -25,7 +25,11 @@ package java.util; import java.util.function.IntConsumer; +import java.util.function.IntFunction; import java.util.function.IntSupplier; +import java.util.function.IntToDoubleFunction; +import java.util.function.IntToLongFunction; +import java.util.function.IntUnaryOperator; import java.util.function.Supplier; import java.util.stream.IntStream; @@ -185,6 +189,146 @@ } /** + * If a value is present, returns an {@code OptionalInt} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalInt}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalInt} describing the result of applying a + * mapping function to the value of this {@code OptionalInt}, if a + * value is present, otherwise an empty {@code OptionalInt} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalInt map(IntUnaryOperator mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalInt.empty(); + } else { + return OptionalInt.of(mapper.applyAsInt(value)); + } + } + + /** + * If a value is present, returns an {@code Optional} describing (as if by + * {@link Optional#ofNullable}) the result of applying the given mapping + * function to the value, otherwise returns an empty {@code Optional}. + * + *

If the mapping function returns a {@code null} result then this method + * returns an empty {@code Optional}. + * + * @param mapper the mapping function to apply to a value, if present + * @param The type of the value returned from the mapping function + * @return an {@code Optional} describing the result of applying a mapping + * function to the value of this {@code OptionalInt}, if a value is + * present, otherwise an empty {@code Optional} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public Optional mapToObj(IntFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return Optional.empty(); + } else { + return Optional.ofNullable(mapper.apply(value)); + } + } + + /** + * If a value is present, returns an {@code OptionalLong} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalLong}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalLong} describing the result of applying a + * mapping function to the value of this {@code OptionalInt}, if a + * value is present, otherwise an empty {@code OptionalLong} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalLong mapToLong(IntToLongFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalLong.empty(); + } else { + return OptionalLong.of(mapper.applyAsLong(value)); + } + } + + /** + * If a value is present, returns an {@code OptionalDouble} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalDouble}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalDouble} describing the result of applying a + * mapping function to the value of this {@code OptionalInt}, if a + * value is present, otherwise an empty {@code OptionalDouble} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalDouble mapToDouble(IntToDoubleFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalDouble.empty(); + } else { + return OptionalDouble.of(mapper.applyAsDouble(value)); + } + } + + /** + * If a value is present, returns the result of applying the given + * {@code OptionalInt}-bearing mapping function to the value, otherwise + * returns an empty {@code OptionalInt}. + * + *

This method is similar to {@link #map(IntUnaryOperator)}, but the + * mapping function is one whose result is already an {@code OptionalInt}, + * and if invoked, {@code flatMap} does not wrap it within an additional + * {@code OptionalInt}. + * + * @param mapper the mapping function to apply to a value, if present + * @return the result of applying an {@code OptionalInt}-bearing mapping + * function to the value of this {@code OptionalInt}, if a value is + * present, otherwise an empty {@code OptionalInt} + * @throws NullPointerException if the mapping function is {@code null} or + * returns a {@code null} result + * @since 13 + */ + public OptionalInt flatMap(IntFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalInt.empty(); + } else { + OptionalInt r = mapper.apply(value); + return Objects.requireNonNull(r); + } + } + + /** + * If a value is present, returns an {@code OptionalInt} describing the + * value, otherwise returns an {@code OptionalInt} produced by the supplying + * function. + * + * @param supplier the supplying function that produces an + * {@code OptionalInt} to be returned + * @return returns an {@code OptionalInt} describing the value of this + * {@code OptionalInt}, if a value is present, otherwise an + * {@code OptionalInt} produced by the supplying function. + * @throws NullPointerException if the supplying function is {@code null} or + * produces a {@code null} result + * @since 13 + */ + public OptionalInt or(Supplier supplier) { + Objects.requireNonNull(supplier); + if (isPresent()) { + return this; + } else { + OptionalInt r = supplier.get(); + return Objects.requireNonNull(r); + } + } + + /** * If a value is present, returns a sequential {@link IntStream} containing * only that value, otherwise returns an empty {@code IntStream}. * diff --git a/src/java.base/share/classes/java/util/OptionalLong.java b/src/java.base/share/classes/java/util/OptionalLong.java --- a/src/java.base/share/classes/java/util/OptionalLong.java +++ b/src/java.base/share/classes/java/util/OptionalLong.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -25,7 +25,11 @@ package java.util; import java.util.function.LongConsumer; +import java.util.function.LongFunction; import java.util.function.LongSupplier; +import java.util.function.LongToDoubleFunction; +import java.util.function.LongToIntFunction; +import java.util.function.LongUnaryOperator; import java.util.function.Supplier; import java.util.stream.LongStream; @@ -185,6 +189,146 @@ } /** + * If a value is present, returns an {@code OptionalLong} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalLong}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalLong} describing the result of applying a + * mapping function to the value of this {@code OptionalLong}, if a + * value is present, otherwise an empty {@code OptionalLong} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalLong map(LongUnaryOperator mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalLong.empty(); + } else { + return OptionalLong.of(mapper.applyAsLong(value)); + } + } + + /** + * If a value is present, returns an {@code Optional} describing (as if by + * {@link Optional#ofNullable}) the result of applying the given mapping + * function to the value, otherwise returns an empty {@code Optional}. + * + *

If the mapping function returns a {@code null} result then this method + * returns an empty {@code Optional}. + * + * @param mapper the mapping function to apply to a value, if present + * @param The type of the value returned from the mapping function + * @return an {@code Optional} describing the result of applying a mapping + * function to the value of this {@code OptionalLong}, if a value + * is present, otherwise an empty {@code Optional} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public Optional mapToObj(LongFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return Optional.empty(); + } else { + return Optional.ofNullable(mapper.apply(value)); + } + } + + /** + * If a value is present, returns an {@code OptionalInt} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalInt}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalInt} describing the result of applying a + * mapping function to the value of this {@code OptionalLong}, if a + * value is present, otherwise an empty {@code OptionalInt} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalInt mapToInt(LongToIntFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalInt.empty(); + } else { + return OptionalInt.of(mapper.applyAsInt(value)); + } + } + + /** + * If a value is present, returns an {@code OptionalDouble} describing the + * result of applying the given mapping function to the value, otherwise + * returns an empty {@code OptionalDouble}. + * + * @param mapper the mapping function to apply to a value, if present + * @return an {@code OptionalDouble} describing the result of applying a + * mapping function to the value of this {@code OptionalLong}, if a + * value is present, otherwise an empty {@code OptionalDouble} + * @throws NullPointerException if the mapping function is {@code null} + * @since 13 + */ + public OptionalDouble mapToDouble(LongToDoubleFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalDouble.empty(); + } else { + return OptionalDouble.of(mapper.applyAsDouble(value)); + } + } + + /** + * If a value is present, returns the result of applying the given + * {@code OptionalLong}-bearing mapping function to the value, otherwise + * returns an empty {@code OptionalLong}. + * + *

This method is similar to {@link #map(LongUnaryOperator)}, but the + * mapping function is one whose result is already an {@code OptionalLong}, + * and if invoked, {@code flatMap} does not wrap it within an additional + * {@code OptionalLong}. + * + * @param mapper the mapping function to apply to a value, if present + * @return the result of applying an {@code OptionalLong}-bearing mapping + * function to the value of this {@code OptionalLong}, if a value is + * present, otherwise an empty {@code OptionalLong} + * @throws NullPointerException if the mapping function is {@code null} or + * returns a {@code null} result + * @since 13 + */ + public OptionalLong flatMap(LongFunction mapper) { + Objects.requireNonNull(mapper); + if (!isPresent()) { + return OptionalLong.empty(); + } else { + OptionalLong r = mapper.apply(value); + return Objects.requireNonNull(r); + } + } + + /** + * If a value is present, returns an {@code OptionalLong} describing the + * value, otherwise returns an {@code OptionalLong} produced by the + * supplying function. + * + * @param supplier the supplying function that produces an + * {@code OptionalLong} to be returned + * @return returns an {@code OptionalLong} describing the value of this + * {@code OptionalLong}, if a value is present, otherwise an + * {@code OptionalLong} produced by the supplying function. + * @throws NullPointerException if the supplying function is {@code null} or + * produces a {@code null} result + * @since 13 + */ + public OptionalLong or(Supplier supplier) { + Objects.requireNonNull(supplier); + if (isPresent()) { + return this; + } else { + OptionalLong r = supplier.get(); + return Objects.requireNonNull(r); + } + } + + /** * If a value is present, returns a sequential {@link LongStream} containing * only that value, otherwise returns an empty {@code LongStream}. * diff --git a/test/jdk/java/util/Optional/Basic.java b/test/jdk/java/util/Optional/Basic.java --- a/test/jdk/java/util/Optional/Basic.java +++ b/test/jdk/java/util/Optional/Basic.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -32,6 +32,9 @@ import java.util.List; import java.util.NoSuchElementException; import java.util.Optional; +import java.util.OptionalDouble; +import java.util.OptionalInt; +import java.util.OptionalLong; import java.util.concurrent.atomic.AtomicBoolean; import static java.util.stream.Collectors.toList; @@ -44,7 +47,7 @@ /** * Checks a block of assertions over an empty Optional. */ - void checkEmpty(Optional empty) { + static void checkEmpty(Optional empty) { assertTrue(empty.equals(Optional.empty())); assertTrue(Optional.empty().equals(empty)); assertFalse(empty.equals(Optional.of("unexpected"))); @@ -78,7 +81,7 @@ * Checks a block of assertions over an Optional that is expected to * have a particular value present. */ - void checkPresent(Optional opt, String expected) { + static void checkPresent(Optional opt, String expected) { assertFalse(opt.equals(Optional.empty())); assertFalse(Optional.empty().equals(opt)); assertTrue(opt.equals(Optional.of(expected))); @@ -161,6 +164,36 @@ } @Test(groups = "unit") + public void testMapToIntEmpty() { + BasicInt.checkEmpty(Optional.empty().mapToInt(s -> { fail(); return 0; })); + } + + @Test(groups = "unit") + public void testMapToIntPresent() { + BasicInt.checkPresent(Optional.of("xyzzy").mapToInt(s -> BasicInt.INTVAL), BasicInt.INTVAL); + } + + @Test(groups = "unit") + public void testMapToLongEmpty() { + BasicLong.checkEmpty(Optional.empty().mapToLong(s -> { fail(); return 0L; })); + } + + @Test(groups = "unit") + public void testMapToLongPresent() { + BasicLong.checkPresent(Optional.of("xyzzy").mapToLong(s -> BasicLong.LONGVAL), BasicLong.LONGVAL); + } + + @Test(groups = "unit") + public void testMapToDoubleEmpty() { + BasicDouble.checkEmpty(Optional.empty().mapToDouble(s -> { fail(); return 0D; })); + } + + @Test(groups = "unit") + public void testMapToDoublePresent() { + BasicDouble.checkPresent(Optional.of("xyzzy").mapToDouble(s -> BasicDouble.DOUBLEVAL), BasicDouble.DOUBLEVAL); + } + + @Test(groups = "unit") public void testFlatMapEmpty() { checkEmpty(Optional.empty().flatMap(s -> { fail(); return Optional.of(""); })); } @@ -179,6 +212,60 @@ } @Test(groups = "unit") + public void testFlatMapToIntEmpty() { + BasicInt.checkEmpty(Optional.empty().flatMapToInt(s -> { fail(); return OptionalInt.of(0); })); + } + + @Test(groups = "unit") + public void testFlatMapToIntPresentReturnEmpty() { + BasicInt.checkEmpty(Optional.of("xyzzy") + .flatMapToInt(s -> { assertEquals(s, "xyzzy"); return OptionalInt.empty(); })); + } + + @Test(groups = "unit") + public void testFlatMapToIntPresentReturnPresent() { + BasicInt.checkPresent(Optional.of("xyzzy") + .flatMapToInt(s -> { assertEquals(s, "xyzzy"); return OptionalInt.of(BasicInt.INTVAL); }), + BasicInt.INTVAL); + } + + @Test(groups = "unit") + public void testFlatMapToLongEmpty() { + BasicLong.checkEmpty(Optional.empty().flatMapToLong(s -> { fail(); return OptionalLong.of(0L); })); + } + + @Test(groups = "unit") + public void testFlatMapToLongPresentReturnEmpty() { + BasicLong.checkEmpty(Optional.of("xyzzy") + .flatMapToLong(s -> { assertEquals(s, "xyzzy"); return OptionalLong.empty(); })); + } + + @Test(groups = "unit") + public void testFlatMapToLongPresentReturnPresent() { + BasicLong.checkPresent(Optional.of("xyzzy") + .flatMapToLong(s -> { assertEquals(s, "xyzzy"); return OptionalLong.of(BasicLong.LONGVAL); }), + BasicLong.LONGVAL); + } + + @Test(groups = "unit") + public void testFlatMapToDoubleEmpty() { + BasicDouble.checkEmpty(Optional.empty().flatMapToDouble(s -> { fail(); return OptionalDouble.of(0D); })); + } + + @Test(groups = "unit") + public void testFlatMapToDoublePresentReturnEmpty() { + BasicDouble.checkEmpty(Optional.of("xyzzy") + .flatMapToDouble(s -> { assertEquals(s, "xyzzy"); return OptionalDouble.empty(); })); + } + + @Test(groups = "unit") + public void testFlatMapToDoublePresentReturnPresent() { + BasicDouble.checkPresent(Optional.of("xyzzy") + .flatMapToDouble(s -> { assertEquals(s, "xyzzy"); return OptionalDouble.of(BasicDouble.DOUBLEVAL); }), + BasicDouble.DOUBLEVAL); + } + + @Test(groups = "unit") public void testOrEmptyEmpty() { checkEmpty(Optional.empty().or(() -> Optional.empty())); } diff --git a/test/jdk/java/util/Optional/BasicDouble.java b/test/jdk/java/util/Optional/BasicDouble.java --- a/test/jdk/java/util/Optional/BasicDouble.java +++ b/test/jdk/java/util/Optional/BasicDouble.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -43,7 +43,7 @@ /** * Checks a block of assertions over an empty OptionalDouble. */ - void checkEmpty(OptionalDouble empty) { + static void checkEmpty(OptionalDouble empty) { assertTrue(empty.equals(OptionalDouble.empty())); assertTrue(OptionalDouble.empty().equals(empty)); assertFalse(empty.equals(OptionalDouble.of(UNEXPECTED))); @@ -77,7 +77,7 @@ * Checks a block of assertions over an OptionalDouble that is expected to * have a particular value present. */ - void checkPresent(OptionalDouble opt, double expected) { + static void checkPresent(OptionalDouble opt, double expected) { assertFalse(opt.equals(OptionalDouble.empty())); assertFalse(OptionalDouble.empty().equals(opt)); assertTrue(opt.equals(OptionalDouble.of(expected))); @@ -128,4 +128,77 @@ public void testStreamPresent() { assertEquals(OptionalDouble.of(DOUBLEVAL).stream().toArray(), new double[] { DOUBLEVAL }); } + + @Test(groups = "unit") + public void testMapEmpty() { + checkEmpty(OptionalDouble.empty().map(s -> { fail(); return 0D; })); + } + + @Test(groups = "unit") + public void testMapPresent() { + checkPresent(OptionalDouble.of(DOUBLEVAL).map(d -> d * 2), 2 * DOUBLEVAL); + } + + @Test(groups = "unit") + public void testMapToObjEmpty() { + Basic.checkEmpty(OptionalDouble.empty().mapToObj(s -> { fail(); return ""; })); + } + + @Test(groups = "unit") + public void testMapToObjPresent() { + Basic.checkPresent(OptionalDouble.of(DOUBLEVAL).mapToObj(d -> "plugh"), "plugh"); + } + + @Test(groups = "unit") + public void testMapToIntEmpty() { + BasicInt.checkEmpty(OptionalDouble.empty().mapToInt(s -> { fail(); return 0; })); + } + + @Test(groups = "unit") + public void testMapToIntPresent() { + BasicInt.checkPresent(OptionalDouble.of(DOUBLEVAL).mapToInt(d -> BasicInt.INTVAL), BasicInt.INTVAL); + } + + @Test(groups = "unit") + public void testMapToLongEmpty() { + BasicLong.checkEmpty(OptionalDouble.empty().mapToLong(s -> { fail(); return 0L; })); + } + + @Test(groups = "unit") + public void testMapToLongPresent() { + BasicLong.checkPresent(OptionalDouble.of(DOUBLEVAL).mapToLong(d -> BasicLong.LONGVAL), BasicLong.LONGVAL); + } + + @Test(groups = "unit") + public void testFlatMapEmpty() { + checkEmpty(OptionalDouble.empty().flatMap(s -> { fail(); return OptionalDouble.of(0D); })); + } + + @Test(groups = "unit") + public void testFlatMapPresentReturnEmpty() { + checkEmpty(OptionalDouble.of(DOUBLEVAL) + .flatMap(d -> { assertEquals(d, DOUBLEVAL); return OptionalDouble.empty(); })); + } + + @Test(groups = "unit") + public void testFlatMapPresentReturnPresent() { + checkPresent(OptionalDouble.of(DOUBLEVAL) + .flatMap(d -> { assertEquals(d, DOUBLEVAL); return OptionalDouble.of(Math.E); }), + Math.E); + } + + @Test(groups = "unit") + public void testOrEmptyEmpty() { + checkEmpty(OptionalDouble.empty().or(() -> OptionalDouble.empty())); + } + + @Test(groups = "unit") + public void testOrEmptyPresent() { + checkPresent(OptionalDouble.empty().or(() -> OptionalDouble.of(DOUBLEVAL)), DOUBLEVAL); + } + + @Test(groups = "unit") + public void testOrPresentDontCare() { + checkPresent(OptionalDouble.of(DOUBLEVAL).or(() -> { fail(); return OptionalDouble.of(0D); }), DOUBLEVAL); + } } diff --git a/test/jdk/java/util/Optional/BasicInt.java b/test/jdk/java/util/Optional/BasicInt.java --- a/test/jdk/java/util/Optional/BasicInt.java +++ b/test/jdk/java/util/Optional/BasicInt.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -44,7 +44,7 @@ /** * Checks a block of assertions over an empty OptionalInt. */ - void checkEmpty(OptionalInt empty) { + static void checkEmpty(OptionalInt empty) { assertTrue(empty.equals(OptionalInt.empty())); assertTrue(OptionalInt.empty().equals(empty)); assertFalse(empty.equals(OptionalInt.of(UNEXPECTED))); @@ -78,7 +78,7 @@ * Checks a block of assertions over an OptionalInt that is expected to * have a particular value present. */ - void checkPresent(OptionalInt opt, int expected) { + static void checkPresent(OptionalInt opt, int expected) { assertFalse(opt.equals(OptionalInt.empty())); assertFalse(OptionalInt.empty().equals(opt)); assertTrue(opt.equals(OptionalInt.of(expected))); @@ -129,4 +129,77 @@ public void testStreamPresent() { assertEquals(OptionalInt.of(INTVAL).stream().toArray(), new int[] { INTVAL }); } + + @Test(groups = "unit") + public void testMapEmpty() { + checkEmpty(OptionalInt.empty().map(s -> { fail(); return 0; })); + } + + @Test(groups = "unit") + public void testMapPresent() { + checkPresent(OptionalInt.of(INTVAL).map(i -> i * 2), 2 * INTVAL); + } + + @Test(groups = "unit") + public void testMapToObjEmpty() { + Basic.checkEmpty(OptionalInt.empty().mapToObj(s -> { fail(); return ""; })); + } + + @Test(groups = "unit") + public void testMapToObjPresent() { + Basic.checkPresent(OptionalInt.of(INTVAL).mapToObj(i -> "plugh"), "plugh"); + } + + @Test(groups = "unit") + public void testMapToLongEmpty() { + BasicLong.checkEmpty(OptionalInt.empty().mapToLong(s -> { fail(); return 0L; })); + } + + @Test(groups = "unit") + public void testMapToLongPresent() { + BasicLong.checkPresent(OptionalInt.of(INTVAL).mapToLong(i -> BasicLong.LONGVAL), BasicLong.LONGVAL); + } + + @Test(groups = "unit") + public void testMapToDoubleEmpty() { + BasicDouble.checkEmpty(OptionalInt.empty().mapToDouble(s -> { fail(); return 0D; })); + } + + @Test(groups = "unit") + public void testMapToDoublePresent() { + BasicDouble.checkPresent(OptionalInt.of(INTVAL).mapToDouble(i -> BasicDouble.DOUBLEVAL), BasicDouble.DOUBLEVAL); + } + + @Test(groups = "unit") + public void testFlatMapEmpty() { + checkEmpty(OptionalInt.empty().flatMap(s -> { fail(); return OptionalInt.of(0); })); + } + + @Test(groups = "unit") + public void testFlatMapPresentReturnEmpty() { + checkEmpty(OptionalInt.of(INTVAL) + .flatMap(i -> { assertEquals(i, INTVAL); return OptionalInt.empty(); })); + } + + @Test(groups = "unit") + public void testFlatMapPresentReturnPresent() { + checkPresent(OptionalInt.of(INTVAL) + .flatMap(i -> { assertEquals(i, INTVAL); return OptionalInt.of(2 * INTVAL); }), + 2 * INTVAL); + } + + @Test(groups = "unit") + public void testOrEmptyEmpty() { + checkEmpty(OptionalInt.empty().or(() -> OptionalInt.empty())); + } + + @Test(groups = "unit") + public void testOrEmptyPresent() { + checkPresent(OptionalInt.empty().or(() -> OptionalInt.of(INTVAL)), INTVAL); + } + + @Test(groups = "unit") + public void testOrPresentDontCare() { + checkPresent(OptionalInt.of(INTVAL).or(() -> { fail(); return OptionalInt.of(0); }), INTVAL); + } } diff --git a/test/jdk/java/util/Optional/BasicLong.java b/test/jdk/java/util/Optional/BasicLong.java --- a/test/jdk/java/util/Optional/BasicLong.java +++ b/test/jdk/java/util/Optional/BasicLong.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -43,7 +43,7 @@ /** * Checks a block of assertions over an empty OptionalLong. */ - void checkEmpty(OptionalLong empty) { + static void checkEmpty(OptionalLong empty) { assertTrue(empty.equals(OptionalLong.empty())); assertTrue(OptionalLong.empty().equals(empty)); assertFalse(empty.equals(OptionalLong.of(UNEXPECTED))); @@ -77,7 +77,7 @@ * Checks a block of assertions over an OptionalLong that is expected to * have a particular value present. */ - void checkPresent(OptionalLong opt, long expected) { + static void checkPresent(OptionalLong opt, long expected) { assertFalse(opt.equals(OptionalLong.empty())); assertFalse(OptionalLong.empty().equals(opt)); assertTrue(opt.equals(OptionalLong.of(expected))); @@ -128,4 +128,77 @@ public void testStreamPresent() { assertEquals(OptionalLong.of(LONGVAL).stream().toArray(), new long[] { LONGVAL }); } + + @Test(groups = "unit") + public void testMapEmpty() { + checkEmpty(OptionalLong.empty().map(s -> { fail(); return 0L; })); + } + + @Test(groups = "unit") + public void testMapPresent() { + checkPresent(OptionalLong.of(LONGVAL).map(l -> l * 2), 2 * LONGVAL); + } + + @Test(groups = "unit") + public void testMapToObjEmpty() { + Basic.checkEmpty(OptionalLong.empty().mapToObj(s -> { fail(); return ""; })); + } + + @Test(groups = "unit") + public void testMapToObjPresent() { + Basic.checkPresent(OptionalLong.of(LONGVAL).mapToObj(l -> "plugh"), "plugh"); + } + + @Test(groups = "unit") + public void testMapToIntEmpty() { + BasicInt.checkEmpty(OptionalLong.empty().mapToInt(s -> { fail(); return 0; })); + } + + @Test(groups = "unit") + public void testMapToIntPresent() { + BasicInt.checkPresent(OptionalLong.of(LONGVAL).mapToInt(l -> BasicInt.INTVAL), BasicInt.INTVAL); + } + + @Test(groups = "unit") + public void testMapToDoubleEmpty() { + BasicDouble.checkEmpty(OptionalLong.empty().mapToDouble(s -> { fail(); return 0D; })); + } + + @Test(groups = "unit") + public void testMapToDoublePresent() { + BasicDouble.checkPresent(OptionalLong.of(LONGVAL).mapToDouble(l -> BasicDouble.DOUBLEVAL), BasicDouble.DOUBLEVAL); + } + + @Test(groups = "unit") + public void testFlatMapEmpty() { + checkEmpty(OptionalLong.empty().flatMap(s -> { fail(); return OptionalLong.of(0L); })); + } + + @Test(groups = "unit") + public void testFlatMapPresentReturnEmpty() { + checkEmpty(OptionalLong.of(LONGVAL) + .flatMap(d -> { assertEquals(d, LONGVAL); return OptionalLong.empty(); })); + } + + @Test(groups = "unit") + public void testFlatMapPresentReturnPresent() { + checkPresent(OptionalLong.of(LONGVAL) + .flatMap(d -> { assertEquals(d, LONGVAL); return OptionalLong.of(2 * LONGVAL); }), + 2 * LONGVAL); + } + + @Test(groups = "unit") + public void testOrEmptyEmpty() { + checkEmpty(OptionalLong.empty().or(() -> OptionalLong.empty())); + } + + @Test(groups = "unit") + public void testOrEmptyPresent() { + checkPresent(OptionalLong.empty().or(() -> OptionalLong.of(LONGVAL)), LONGVAL); + } + + @Test(groups = "unit") + public void testOrPresentDontCare() { + checkPresent(OptionalLong.of(LONGVAL).or(() -> { fail(); return OptionalLong.of(0L); }), LONGVAL); + } } From jonathan.gibbons at oracle.com Sat Feb 16 21:44:24 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 16 Feb 2019 13:44:24 -0800 Subject: Faulty Null-Check Suspected in ToolProvider In-Reply-To: <1550305222.2497.24.camel@paratix.ch> References: <1550266989.2497.19.camel@paratix.ch> <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> <1550275179.2497.21.camel@paratix.ch> <1550305222.2497.24.camel@paratix.ch> Message-ID: <4fe8ea57-e4dd-e48f-50da-6214fc479930@oracle.com> On 2/16/19 12:20 AM, Philipp Kunz wrote: > I'm also wondering about the call to flush in run(PrintStream out, > PrintStream err, String... args). It looks like the intention was to > flush the wrapping PrintWriter. > That is not possible without also flushing the underlying PrintStream. > BufferedWriter.flushBuffer would be a more sensible method to call but > is not accessible. > The effect is actually, that the call to PrintWriter.flush will also > call flush of the underlying PrintStream. Should that be documented > more explicitly, for example: Philipp, I don't see that it needs to be specified. It is a reasonable presumption that everything written by the tool is propagated to the streams passed into the run method. How that is achieved is an implementation detail. If you were to modify the spec, it would at most be an implementation detail, and should appear in an @implNote. -- Jon From philipp.kunz at paratix.ch Sun Feb 17 00:45:31 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sun, 17 Feb 2019 01:45:31 +0100 Subject: Faulty Null-Check Suspected in ToolProvider In-Reply-To: <4fe8ea57-e4dd-e48f-50da-6214fc479930@oracle.com> References: <1550266989.2497.19.camel@paratix.ch> <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> <1550275179.2497.21.camel@paratix.ch> <1550305222.2497.24.camel@paratix.ch> <4fe8ea57-e4dd-e48f-50da-6214fc479930@oracle.com> Message-ID: <1550364331.2497.28.camel@paratix.ch> Hi Jon, On Sat, 2019-02-16 at 13:44 -0800, Jonathan Gibbons wrote: > On 2/16/19 12:20 AM, Philipp Kunz wrote: > > I'm also wondering about the call to flush in run(PrintStream out, > > PrintStream err, String... args). It looks like the intention was > > to > > flush the wrapping PrintWriter. > > That is not possible without also flushing the underlying > > PrintStream. > > BufferedWriter.flushBuffer would be a more sensible method to call > > but > > is not accessible. > > The effect is actually, that the call to PrintWriter.flush will > > also > > call flush of the underlying PrintStream. Should that be documented > > more explicitly, for example: > > Philipp, > > I don't see that it needs to be specified. > It is a reasonable presumption that everything written by the tool > is propagated to the streams passed into the run method. How that > is achieved is an implementation detail. I absolutely agree so far. My point, however, was a different one. In addition to flushing the buffers created by run(PrintStream, PrintStream, String...)'s PrintWriters to the PrintStreams passed to that method, flushing the PrintWriters propagates to the underlying PrintStreams and flushes them as well. In other words, whatever PrintStreams passed into run(PrintStream, PrintStream, String...) are flushed. > If you were to modify the spec, it would at most be an implementation > detail, and should appear in an @implNote. I agree that it should go into an @implNote. I also suggested it that way, below an existing @implNote. > -- Jon > Additionally,?run(PrintStream, PrintStream, String...) is only a default method and may be replaced in ToolProvider implementations. Therefore we don't know if these buffers will actually be flushed and I replaced "are" with "may be" before "flushed" in the comment. The same consideration also applies to run(PrintWriter, PrintWriter, String...). diff -r 31e3aa9c0c71 src/java.base/share/classes/java/util/spi/ToolProvider.java --- a/src/java.base/share/classes/java/util/spi/ToolProvider.java Sat Feb 16 11:40:34 2019 +0900 +++ b/src/java.base/share/classes/java/util/spi/ToolProvider.java Sun Feb 17 01:30:30 2019 +0100 @@ -75,6 +75,8 @@ ??????* @apiNote The interpretation of the arguments will be specific to ??????* each tool. ??????* +?????* @implNote Both {@code out} and {@code err} streams may be flushed. +?????* ??????* @param out a stream to which "expected" output should be written ??????* ??????* @param err a stream to which any error messages should be written @@ -107,6 +109,8 @@ ??????* @implNote This implementation wraps the {@code out} and {@code err} ??????* streams within {@link PrintWriter}s, and then calls ??????* {@link #run(PrintWriter, PrintWriter, String[])}. +?????* Both {@code out} and {@code err} streams may be flushed before the method +?????* returns as a side-effect of flushing the wrapping {@link PrintWriter}s. ??????* ??????* @param out a stream to which "expected" output should be written ??????* Regards, Philipp From jonathan.gibbons at oracle.com Sun Feb 17 01:05:37 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 16 Feb 2019 17:05:37 -0800 Subject: Faulty Null-Check Suspected in ToolProvider In-Reply-To: <1550364331.2497.28.camel@paratix.ch> References: <1550266989.2497.19.camel@paratix.ch> <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> <1550275179.2497.21.camel@paratix.ch> <1550305222.2497.24.camel@paratix.ch> <4fe8ea57-e4dd-e48f-50da-6214fc479930@oracle.com> <1550364331.2497.28.camel@paratix.ch> Message-ID: I still don't see why it is necessary to specify this behavior. -- Jon On 2/16/19 4:45 PM, Philipp Kunz wrote: > Hi Jon, > > On Sat, 2019-02-16 at 13:44 -0800, Jonathan Gibbons wrote: >> On 2/16/19 12:20 AM, Philipp Kunz wrote: >>> I'm also wondering about the call to flush in run(PrintStream out, >>> PrintStream err, String... args). It looks like the intention was to >>> flush the wrapping PrintWriter. That is not possible without also >>> flushing the underlying PrintStream. BufferedWriter.flushBuffer >>> would be a more sensible method to call but is not accessible. The >>> effect is actually, that the call to PrintWriter.flush will also >>> call flush of the underlying PrintStream. Should that be documented >>> more explicitly, for example: >> >> >> Philipp, >> >> I don't see that it needs to be specified. >> It is a reasonable presumption that everything written by the tool >> is propagated to the streams passed into the run method. How that >> is achieved is an implementation detail. > > I absolutely agree so far. My point, however, was a different one. > In addition to flushing the buffers created by run(PrintStream, > PrintStream, String...)'s PrintWriters to the PrintStreams passed to > that method, flushing the PrintWriters propagates to the underlying > PrintStreams and flushes them as well. > In other words, whatever PrintStreams passed into run(PrintStream, > PrintStream, String...) are flushed. > >> If you were to modify the spec, it would at most be an implementation >> detail, and should appear in an @implNote. > > I agree that it should go into an @implNote. I also suggested it that > way, below an existing @implNote. > >> -- Jon >> > > Additionally,?run(PrintStream, PrintStream, String...) is only a > default method and may be replaced in ToolProvider implementations. > Therefore we don't know if these buffers will actually be flushed and > I replaced "are" with "may be" before "flushed" in the comment. > The same consideration also applies to run(PrintWriter, PrintWriter, > String...). > > > diff -r 31e3aa9c0c71 > src/java.base/share/classes/java/util/spi/ToolProvider.java > --- a/src/java.base/share/classes/java/util/spi/ToolProvider.java Sat > Feb 16 11:40:34 2019 +0900 > +++ b/src/java.base/share/classes/java/util/spi/ToolProvider.java Sun > Feb 17 01:30:30 2019 +0100 > @@ -75,6 +75,8 @@ > ??????* @apiNote The interpretation of the arguments will be specific to > ??????* each tool. > ??????* > +?????* @implNote Both {@code out} and {@code > err} streams may be flushed. > +?????* > ??????* @param out a stream to which "expected" output should be written > ??????* > ??????* @param err a stream to which any error messages should be written > @@ -107,6 +109,8 @@ > ??????* @implNote This implementation wraps the {@code > out} and {@code err} > ??????* streams within {@link PrintWriter}s, and then > calls > ??????* {@link #run(PrintWriter, PrintWriter, String[])}. > +?????* Both {@code out} and {@code > err} streams may be flushed before the method > +?????* returns as a side-effect of flushing the wrapping {@link > PrintWriter}s. > ??????* > ??????* @param out a stream to which "expected" output should be written > ??????* > > Regards, > Philipp From raffaello.giulietti at gmail.com Sun Feb 17 16:47:29 2019 From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com) Date: Sun, 17 Feb 2019 17:47:29 +0100 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: References: Message-ID: <744ac2b1-a7cb-a715-d53b-3a65f0fccc59@gmail.com> Hello, the bulk of this message is a new patch that replaces the one found at [1]. It appears both inline and as an attachment in the hope that at least one form makes it through. What did change in the meantime? * The most convoluted part of the implementation has been refactored to both reduce the SLOC count and enhance performance, which now reaches about 16x speedup wrt the current OpenJDK implementation. * The Javadoc for the toString() methods has a new definition of d_v, the decimal to format as a string. While slightly more abstract, it is far clearer than the former one, I hope. * A new test has been added to extensively check the consistency of class MathUtils, which is a vital component of the whole code. For the interested reader, there's now a document (subject to change at any time) devoted to the explanation of the underlying Schubfach algorithm and its high performance implementation [2]. For how to pronounce the German noun Schubfach (shoobfaX, the X as in LaTeX), click on the left speaker button in [3]. Beside lack of time until Christmas, one of the reasons it took me so long in writing the document is because I want it to be readable by anyone minimally interested in the subject. It does not require any previous knowledge or any math other than simple algebraic manipulations, love for logical reasoning and some maturity. It requires some willingness and some hours to go through, though. Not being tied to journal publishing, I exploited this luxury to ensure a rather relaxed reading pace. For the expert reader in a hurry, however, here's a suggested reading guide: * Take a look at figure 2 to make sure that the definition of the decimal d_v is well understood. * Review definition 4 about the shortest form and the length of a decimal and result 5 about the length of decimals in the proximity of another one. * Have a knowledge of result 8, which is key in avoiding an iterative search and which is exploited in the design of Schubfach. * Take a breath and delve into the discussion of Schubfach in section 8.1, leading to figure 3. * From section 9 onward the discussion is about an efficient implementation. This is essential reading to understand the rather concise Java implementation. There's no shortcut known to me, so have a clear mind and drop me a line, even in private, if you have troubles. Greetings Raffaello ---- [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055698.html [2] https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 [3] https://translate.google.com/?hl=&ie=UTF-8&sl=it&tl=en#view=home&op=translate&sl=de&tl=en&text=Schubfach ---- # HG changeset patch # Date 1550416868 -3600 # Sun Feb 17 16:21:08 2019 +0100 # Node ID 726d159731343a7120278def10482527123411e8 # Parent d230a040662314f69fe50620a68fae6634550b49 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/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 @@ -30,6 +30,7 @@ import java.lang.constant.ConstantDesc; import java.util.Optional; +import jdk.internal.math.DoubleToDecimal; import jdk.internal.math.FloatingDecimal; import jdk.internal.math.DoubleConsts; 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 10nm {@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-1d < 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 + * d1dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

        + *
      • Case -3 ≤ e < 0: + * dv is formatted as + * 0.00d1dn, + * 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 + * d1dn00.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 + * d1dn+i.dn+i+1dn. + * 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.d2dnEe. + * 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); + return DoubleToDecimal.toString(d); } /** 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 @@ -30,6 +30,7 @@ import java.lang.constant.ConstantDesc; import java.util.Optional; +import jdk.internal.math.FloatToDecimal; import jdk.internal.math.FloatingDecimal; 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-1d < 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 + * d1dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

          + *
        • Case -3 ≤ e < 0: + * dv is formatted as + * 0.00d1dn, + * 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 + * d1dn00.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 + * d1dn+i.dn+i+1dn. + * 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.d2dnEe. + * 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); + return FloatToDecimal.toString(f); } /** 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,508 @@ +/* + * Copyright 2018-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. + */ + +package jdk.internal.math; + +import static java.lang.Double.*; +import static java.lang.Long.numberOfLeadingZeros; +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=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + + [2] IEEE Computer Society, "IEEE Standard for Floating-Point Arithmetic" + + [3] Moeller & Granlund, "Improved division by invariant integers" + + [4] Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion" + */ + + // The precision in bits. + private 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. + private static final int Q_MIN = (-1 << W - 1) - P + 3; + + // 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; + + /* + H is the minimal number of decimal digits needed to ensure that + for all finite v, round-to-half-even(toString(v)) = v + */ + private static final int H = 17; + + // Used in rop(). + private static final long MASK_63 = (1L << 63) - 1; + + // Used for digit extraction in toChars() and its dependencies. + private static final int MASK_28 = (1 << 28) - 1; + + // 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 + */ + private final byte[] buf = new byte[H + 7]; + + // Index into buf 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-1d < 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 + * d1dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

          + *
        • Case -3 ≤ e < 0: + * dv is formatted as + * 0.00d1dn, + * 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 + * d1dn00.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 + * d1dn+i.dn+i+1dn. + * 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.d2dnEe. + * 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().toDecimal(v); + } + + private static DoubleToDecimal threadLocalInstance() { + return threadLocal.get(); + } + + private String toDecimal(double v) { + /* + For details not discussed here see reference [2]. + + Let + Q_MAX = 2^(W-1) - P + C_MAX = 2^P - 1 + For finite v != 0, determine integers c and q such that + |v| = c 2^q and + Q_MIN <= q <= Q_MAX and + either C_MIN <= c <= C_MAX (normal value) + or 0 < c < C_MIN and q = Q_MIN (subnormal value) + */ + 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 + return toDecimal(Q_MIN - 1 + bq, C_MIN | t); + } + if (t != 0) { + // subnormal value + return toDecimal(Q_MIN, t); + } + return bits == 0 ? "0.0" : "-0.0"; + } + if (t != 0) { + return "NaN"; + } + return bits > 0 ? "Infinity" : "-Infinity"; + } + + private String toDecimal(int q, long c) { + // For full details see reference [1]. + int out = (int) c & 0x1; + long cb; + long cbr; + long cbl; + int k; + int h; + if (c != C_MIN | q == Q_MIN) { + // regular spacing + cb = c << 1; + cbr = cb + 1; + k = flog10pow2(q); + h = q + flog2pow10(-k) + 3; + } else { + // irregular spacing + cb = c << 2; + cbr = cb + 2; + k = flog10threeQuartersPow2(q); + h = q + flog2pow10(-k) + 2; + } + cbl = cb - 1; + + 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) { + /* + sp10 = 10 s', tp10 = 10 t' = sp10 + 10 + This is the only place where a division (the %) is carried out. + */ + long sp10 = s - s % 10; + 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); + } + } else if (s < 10) { + switch ((int) s) { + case 4: + return toChars(49, -325); // 4.9 10^(-324) + case 9: + return toChars(99, -325); // 9.9 10^(-324) + } + } + long t = s + 1; + boolean uin = vbl + out <= s << 2; + boolean win = (t << 2) + out <= vbr; + if (uin != win) { + // Exactly one of s 10^k or t 10^k lies in Rv. + return toChars(uin ? s : t, k); + } + // Both s 10^k and t 10^k lie in Rv: determine the one closest to v. + long cmp = vb - (s + t << 1); + return toChars(cmp < 0 || cmp == 0 && (s & 0x1) == 0 ? s : t, k); + } + + private static long rop(long g1, long g0, long cp) { + // For full details see reference [1]. + 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 String toChars(long f, int e) { + /* + For details not discussed here see reference [3]. + + 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 + + To avoid divisions, it can be shown ([3]) that + floor(f / 10^8) = + floor(193'428'131'138'340'668 f / 2^84) = + floor(48'357'032'784'585'167 f / 2^82) = + floor(floor(48'357'032'784'585'167 f / 2^64) / 2^18) + and similarly + floor(hm / 10^8) = floor(1'441'151'881 hm / 2^57) + */ + long hm = multiplyHigh(f, 48_357_032_784_585_167L) >>> 18; + 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 String toChars1(int h, int m, int l, int e) { + /* + 0 < e <= 7: plain format without leading zeroes. + The left-to-right digits generation is inspired by [4]. + */ + 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 charsToString(); + } + + private String 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 charsToString(); + } + + private String 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 charsToString(); + } + + private void lowDigits(int l) { + if (l != 0) { + append8Digits(l); + } + removeTrailingZeroes(); + } + + private void append8Digits(int m) { + // The left-to-right digits generation is inspired by [4] + 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 (buf[index] == '0') { + --index; + } + if (buf[index] == '.') { + ++index; + } + } + + /* + Computes floor((m + 1) 2^28 / 10^8) - 1, needed by [4], as in [3] + */ + private int y(int m) { + return (int) (multiplyHigh( + (long) (m + 1) << 28, + 48_357_032_784_585_167L) >>> 18) - 1; + } + + private void exponent(int e) { + append('E'); + if (e < 0) { + append('-'); + e = -e; + } + if (e < 10) { + appendDigit(e); + return; + } + /* + It can be shown ([3]) that + floor(e / 10) = floor(205 e / 2^11) + floor(e / 100) = floor(1'311 e / 2^17) + */ + if (e < 100) { + int d = e * 205 >>> 11; + appendDigit(d); + appendDigit(e - 10 * d); + return; + } + int d = e * 1_311 >>> 17; + appendDigit(d); + e -= 100 * d; + d = e * 205 >>> 11; + appendDigit(d); + appendDigit(e - 10 * d); + } + + private void append(int c) { + buf[++index] = (byte) c; + } + + private void appendDigit(int d) { + buf[++index] = (byte) ('0' + d); + } + + /* + Using the deprecated, yet public constructor enhances performance. + */ + private String charsToString() { + return new String(buf, 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,482 @@ +/* + * Copyright 2018-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. + */ + +package jdk.internal.math; + +import static java.lang.Float.*; +import static java.lang.Integer.numberOfLeadingZeros; +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=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + + [2] IEEE Computer Society, "IEEE Standard for Floating-Point Arithmetic" + + [3] Moeller & Granlund, "Improved division by invariant integers" + + [4] Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion" + */ + + // The precision in bits. + private 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. + private static final int Q_MIN = (-1 << W - 1) - P + 3; + + // 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; + + /* + H is the minimal number of decimal digits needed to ensure that + for all finite v, round-to-half-even(toString(v)) = v + */ + private static final int H = 9; + + // Used in rop(). + private static final long MASK_31 = (1L << 31) - 1; + + // Used for digit extraction in toChars() and its dependencies. + private static final int MASK_28 = (1 << 28) - 1; + + // 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 + */ + private final byte[] buf = new byte[H + 6]; + + // 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-1d < 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 + * d1dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

          + *
        • Case -3 ≤ e < 0: + * dv is formatted as + * 0.00d1dn, + * 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 + * d1dn00.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 + * d1dn+i.dn+i+1dn. + * 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.d2dnEe. + * 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().toDecimal(v); + } + + private static FloatToDecimal threadLocalInstance() { + return threadLocal.get(); + } + + private String toDecimal(float v) { + /* + For details not discussed here see reference [2]. + + Let + Q_MAX = 2^(W-1) - P + C_MAX = 2^P - 1 + For finite v != 0, determine integers c and q such that + |v| = c 2^q and + Q_MIN <= q <= Q_MAX and + either C_MIN <= c <= C_MAX (normal value) + or 0 < c < C_MIN and q = Q_MIN (subnormal value) + */ + 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 + return toDecimal(Q_MIN - 1 + bq, C_MIN | t); + } + if (t != 0) { + // subnormal value + return toDecimal(Q_MIN, t); + } + return bits == 0 ? "0.0" : "-0.0"; + } + if (t != 0) { + return "NaN"; + } + return bits > 0 ? "Infinity" : "-Infinity"; + } + + private String toDecimal(int q, int c) { + // For full details see reference [1]. + int out = c & 0x1; + long cb; + long cbr; + long cbl; + int k; + int h; + if (c != C_MIN | q == Q_MIN) { + // regular spacing + cb = c << 1; + cbr = cb + 1; + k = flog10pow2(q); + h = q + flog2pow10(-k) + 34; + } else { + // irregular spacing + cb = c << 2; + cbr = cb + 2; + k = flog10threeQuartersPow2(q); + h = q + flog2pow10(-k) + 33; + } + cbl = cb - 1; + + 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) { + /* + sp10 = 10 s', tp10 = 10 t' = sp10 + 10 + This is the only place where a division (the %) is carried out. + */ + int sp10 = s - s % 10; + 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); + } + } else if (s < 10) { + switch (s) { + case 1: return toChars(14, -46); // 1.4 * 10^-45 + case 2: return toChars(28, -46); // 2.8 * 10^-45 + case 4: return toChars(42, -46); // 4.2 * 10^-45 + case 5: return toChars(56, -46); // 5.6 * 10^-45 + case 7: return toChars(70, -46); // 7.0 * 10^-45 + case 8: return toChars(84, -46); // 8.4 * 10^-45 + case 9: return toChars(98, -46); // 9.8 * 10^-45 + } + } + int t = s + 1; + boolean uin = vbl + out <= s << 2; + boolean win = (t << 2) + out <= vbr; + if (uin != win) { + // Exactly one of s 10^k or t 10^k lies in Rv. + return toChars(uin ? s : t, k); + } + // Both s 10^k and t 10^k lie in Rv: determine the one closest to v. + int cmp = vb - (s + t << 1); + return toChars(cmp < 0 || cmp == 0 && (s & 0x1) == 0 ? s : t, k); + } + + private static int rop(long g, long cp) { + // For full details see reference [1]. + long x1 = multiplyHigh(g, cp); + long vbp = x1 >> 31; + return (int) (vbp | (x1 & MASK_31) + MASK_31 >>> 31); + } + + /* + Formats the decimal f 10^e. + */ + private String toChars(int f, int e) { + /* + For details not discussed here see reference [3]. + + 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 + + To avoid divisions, it can be shown ([3]) that + 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 String toChars1(int h, int l, int e) { + /* + 0 < e <= 7: plain format without leading zeroes. + The left-to-right digits generation is inspired by [4]. + */ + 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 charsToString(); + } + + private String 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 charsToString(); + } + + private String toChars3(int h, int l, int e) { + // -3 >= e | e > 7: computerized scientific notation + appendDigit(h); + append('.'); + append8Digits(l); + removeTrailingZeroes(); + exponent(e - 1); + return charsToString(); + } + + private void append8Digits(int m) { + // The left-to-right digits generation is inspired by [4] + 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 (buf[index] == '0') { + --index; + } + if (buf[index] == '.') { + ++index; + } + } + + /* + Computes floor((m + 1) 2^28 / 10^8) - 1, needed by [4], as in [3] + */ + private int y(int m) { + return (int) (multiplyHigh( + (long) (m + 1) << 28, + 48_357_032_784_585_167L) >>> 18) - 1; + } + + private void exponent(int e) { + append('E'); + if (e < 0) { + append('-'); + e = -e; + } + if (e < 10) { + appendDigit(e); + return; + } + /* + It can be shown ([3]) that + floor(e / 10) = floor(205 e / 2^11) + */ + int d = e * 205 >>> 11; + appendDigit(d); + appendDigit(e - 10 * d); + } + + private void append(int c) { + buf[++index] = (byte) c; + } + + private void appendDigit(int d) { + buf[++index] = (byte) ('0' + d); + } + + /* + Using the deprecated, yet public constructor enhances performance. + */ + private String charsToString() { + return new String(buf, 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,794 @@ +/* + * Copyright 2018-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. + */ + +package jdk.internal.math; + +/** + * This class exposes package private utilities for other classes. + * + * All methods are assumed to be invoked with correct arguments, so they 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=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + */ + + // 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; + + // The minimum and maximum exponents for g1(int) + static final int MIN_EXP = -292; + static final int MAX_EXP = 324; + + private MathUtils() { + } + + // pow10[e] = 10^e, 0 <= e <= 17 + 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 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 e} = β 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(e)} - 125 (see {@link #flog2pow10(int)}). + * + * @param e The exponent of 10, + * which must meet {@link #MIN_EXP} ≤ {@code e} ≤ + * {@link #MAX_EXP}. + * @return g1 as described above. + */ + static long g1(int e) { + return g[e - MIN_EXP << 1]; + } + + /** + * Returns g0 as described in + * {@link #g1(int)}. + * + * @param e The exponent of 10, + * which must meet {@link #MIN_EXP} ≤ {@code e} ≤ + * {@link #MAX_EXP}. + * @return g0 as described in + * {@link #g1(int)}. + */ + static long g0(int e) { + return g[e - MIN_EXP << 1 | 1]; + } + + /** + * The precomputed values for {@link #g1(int)} and {@link #g0(int)}. + */ + private static final long[] g = { + /* -292 */ 0x7FBB_D8FE_5F5E_6E27L, 0x497A_3A27_04EE_C3DFL, + /* -291 */ 0x4FD5_679E_FB9B_04D8L, 0x5DEC_6458_6315_3A6CL, + /* -290 */ 0x63CA_C186_BA81_C60EL, 0x7567_7D6E_7BDA_8906L, + /* -289 */ 0x7CBD_71E8_6922_3792L, 0x52C1_5CCA_1AD1_2B48L, + /* -288 */ 0x4DF6_6731_41B5_62BBL, 0x53B8_D9FE_50C2_BB0DL, + /* -287 */ 0x6174_00FD_9222_BB6AL, 0x48A7_107D_E4F3_69D0L, + /* -286 */ 0x79D1_013C_F6AB_6A45L, 0x1AD0_D49D_5E30_4444L, + /* -285 */ 0x4C22_A0C6_1A2B_226BL, 0x20C2_84E2_5ADE_2AABL, + /* -284 */ 0x5F2B_48F7_A0B5_EB06L, 0x08F3_261A_F195_B555L, + /* -283 */ 0x76F6_1B35_88E3_65C7L, 0x4B2F_EFA1_ADFB_22ABL, + /* -282 */ 0x4A59_D101_758E_1F9CL, 0x5EFD_F5C5_0CBC_F5ABL, + /* -281 */ 0x5CF0_4541_D2F1_A783L, 0x76BD_7336_4FEC_3315L, + /* -280 */ 0x742C_5692_47AE_1164L, 0x746C_D003_E3E7_3FDBL, + /* -279 */ 0x489B_B61B_6CCC_CADFL, 0x08C4_0202_6E70_87E9L, + /* -278 */ 0x5AC2_A3A2_47FF_FD96L, 0x6AF5_0283_0A0C_A9E3L, + /* -277 */ 0x7173_4C8A_D9FF_FCFCL, 0x45B2_4323_CC8F_D45CL, + /* -276 */ 0x46E8_0FD6_C83F_FE1DL, 0x6B8F_69F6_5FD9_E4B9L, + /* -275 */ 0x58A2_13CC_7A4F_FDA5L, 0x2673_4473_F7D0_5DE8L, + /* -274 */ 0x6ECA_98BF_98E3_FD0EL, 0x5010_1590_F5C4_7561L, + /* -273 */ 0x453E_9F77_BF8E_7E29L, 0x120A_0D7A_999A_C95DL, + /* -272 */ 0x568E_4755_AF72_1DB3L, 0x368C_90D9_4001_7BB4L, + /* -271 */ 0x6C31_D92B_1B4E_A520L, 0x242F_B50F_9001_DAA1L, + /* -270 */ 0x439F_27BA_F111_2734L, 0x169D_D129_BA01_28A5L, + /* -269 */ 0x5486_F1A9_AD55_7101L, 0x1C45_4574_2881_72CEL, + /* -268 */ 0x69A8_AE14_18AA_CD41L, 0x4356_96D1_32A1_CF81L, + /* -267 */ 0x4209_6CCC_8F6A_C048L, 0x7A16_1E42_BFA5_21B1L, + /* -266 */ 0x528B_C7FF_B345_705BL, 0x189B_A5D3_6F8E_6A1DL, + /* -265 */ 0x672E_B9FF_A016_CC71L, 0x7EC2_8F48_4B72_04A4L, + /* -264 */ 0x407D_343F_C40E_3FC7L, 0x1F39_998D_2F27_42E7L, + /* -263 */ 0x509C_814F_B511_CFB9L, 0x0707_FFF0_7AF1_13A1L, + /* -262 */ 0x64C3_A1A3_A256_43A7L, 0x28C9_FFEC_99AD_5889L, + /* -261 */ 0x7DF4_8A0C_8AEB_D491L, 0x12FC_7FE7_C018_AEABL, + /* -260 */ 0x4EB8_D647_D6D3_64DAL, 0x5BDD_CFF0_D80F_6D2BL, + /* -259 */ 0x6267_0BD9_CC88_3E11L, 0x32D5_43ED_0E13_4875L, + /* -258 */ 0x7B00_CED0_3FAA_4D95L, 0x5F8A_94E8_5198_1A93L, + /* -257 */ 0x4CE0_8142_27CA_707DL, 0x4BB6_9D11_32FF_109CL, + /* -256 */ 0x6018_A192_B1BD_0C9CL, 0x7EA4_4455_7FBE_D4C3L, + /* -255 */ 0x781E_C9F7_5E2C_4FC4L, 0x1E4D_556A_DFAE_89F3L, + /* -254 */ 0x4B13_3E3A_9ADB_B1DAL, 0x52F0_5562_CBCD_1638L, + /* -253 */ 0x5DD8_0DC9_4192_9E51L, 0x27AC_6ABB_7EC0_5BC6L, + /* -252 */ 0x754E_113B_91F7_45E5L, 0x5197_856A_5E70_72B8L, + /* -251 */ 0x4950_CAC5_3B3A_8BAFL, 0x42FE_B362_7B06_47B3L, + /* -250 */ 0x5BA4_FD76_8A09_2E9BL, 0x33BE_603B_19C7_D99FL, + /* -249 */ 0x728E_3CD4_2C8B_7A42L, 0x20AD_F849_E039_D007L, + /* -248 */ 0x4798_E604_9BD7_2C69L, 0x346C_BB2E_2C24_2205L, + /* -247 */ 0x597F_1F85_C2CC_F783L, 0x6187_E9F9_B72D_2A86L, + /* -246 */ 0x6FDE_E767_3380_3564L, 0x59E9_E478_24F8_7527L, + /* -245 */ 0x45EB_50A0_8030_215EL, 0x7832_2ECB_171B_4939L, + /* -244 */ 0x5766_24C8_A03C_29B6L, 0x563E_BA7D_DCE2_1B87L, + /* -243 */ 0x6D3F_ADFA_C84B_3424L, 0x2BCE_691D_541A_A268L, + /* -242 */ 0x4447_CCBC_BD2F_0096L, 0x5B61_01B2_5490_A581L, + /* -241 */ 0x5559_BFEB_EC7A_C0BCL, 0x3239_421E_E9B4_CEE1L, + /* -240 */ 0x6AB0_2FE6_E799_70EBL, 0x3EC7_92A6_A422_029AL, + /* -239 */ 0x42AE_1DF0_50BF_E693L, 0x173C_BBA8_2695_41A0L, + /* -238 */ 0x5359_A56C_64EF_E037L, 0x7D0B_EA92_303A_9208L, + /* -237 */ 0x6830_0EC7_7E2B_D845L, 0x7C4E_E536_BC49_368AL, + /* -236 */ 0x411E_093C_AEDB_672BL, 0x5DB1_4F42_35AD_C217L, + /* -235 */ 0x5165_8B8B_DA92_40F6L, 0x551D_A312_C319_329CL, + /* -234 */ 0x65BE_EE6E_D136_D134L, 0x2A65_0BD7_73DF_7F43L, + /* -233 */ 0x7F2E_AA0A_8584_8581L, 0x34FE_4ECD_50D7_5F14L, + /* -232 */ 0x4F7D_2A46_9372_D370L, 0x711E_F140_5286_9B6CL, + /* -231 */ 0x635C_74D8_384F_884DL, 0x0D66_AD90_6728_4247L, + /* -230 */ 0x7C33_920E_4663_6A60L, 0x30C0_58F4_80F2_52D9L, + /* -229 */ 0x4DA0_3B48_EBFE_227CL, 0x1E78_3798_D097_73C8L, + /* -228 */ 0x6108_4A1B_26FD_AB1BL, 0x2616_457F_04BD_50BAL, + /* -227 */ 0x794A_5CA1_F0BD_15E2L, 0x0F9B_D6DE_C5EC_A4E8L, + /* -226 */ 0x4BCE_79E5_3676_2DADL, 0x29C1_664B_3BB3_E711L, + /* -225 */ 0x5EC2_185E_8413_B918L, 0x5431_BFDE_0AA0_E0D5L, + /* -224 */ 0x7672_9E76_2518_A75EL, 0x693E_2FD5_8D49_190BL, + /* -223 */ 0x4A07_A309_D72F_689BL, 0x21C6_DDE5_784D_AFA7L, + /* -222 */ 0x5C89_8BCC_4CFB_42C2L, 0x0A38_955E_D661_1B90L, + /* -221 */ 0x73AB_EEBF_603A_1372L, 0x4CC6_BAB6_8BF9_6274L, + /* -220 */ 0x484B_7537_9C24_4C27L, 0x4FFC_34B2_177B_DD89L, + /* -219 */ 0x5A5E_5285_832D_5F31L, 0x43FB_41DE_9D5A_D4EBL, + /* -218 */ 0x70F5_E726_E3F8_B6FDL, 0x74FA_1256_44B1_8A26L, + /* -217 */ 0x4699_B078_4E7B_725EL, 0x591C_4B75_EAEE_F658L, + /* -216 */ 0x5840_1C96_621A_4EF6L, 0x2F63_5E53_65AA_B3EDL, + /* -215 */ 0x6E50_23BB_FAA0_E2B3L, 0x7B3C_35E8_3F15_60E9L, + /* -214 */ 0x44F2_1655_7CA4_8DB0L, 0x3D05_A1B1_276D_5C92L, + /* -213 */ 0x562E_9BEA_DBCD_B11CL, 0x4C47_0A1D_7148_B3B6L, + /* -212 */ 0x6BBA_42E5_92C1_1D63L, 0x5F58_CCA4_CD9A_E0A3L, + /* -211 */ 0x4354_69CF_7BB8_B25EL, 0x2B97_7FE7_0080_CC66L, + /* -210 */ 0x5429_8443_5AA6_DEF5L, 0x767D_5FE0_C0A0_FF80L, + /* -209 */ 0x6933_E554_3150_96B3L, 0x341C_B7D8_F0C9_3F5FL, + /* -208 */ 0x41C0_6F54_9ED2_5E30L, 0x1091_F2E7_967D_C79CL, + /* -207 */ 0x5230_8B29_C686_F5BCL, 0x14B6_6FA1_7C1D_3983L, + /* -206 */ 0x66BC_ADF4_3828_B32BL, 0x19E4_0B89_DB24_87E3L, + /* -205 */ 0x4035_ECB8_A319_6FFBL, 0x002E_8736_28F6_D4EEL, + /* -204 */ 0x5043_67E6_CBDF_CBF9L, 0x603A_2903_B334_8A2AL, + /* -203 */ 0x6454_41E0_7ED7_BEF8L, 0x1848_B344_A001_ACB4L, + /* -202 */ 0x7D69_5258_9E8D_AEB6L, 0x1E5A_E015_C802_17E1L, + /* -201 */ 0x4E61_D377_6318_8D31L, 0x72F8_CC0D_9D01_4EEDL, + /* -200 */ 0x61FA_4855_3BDE_B07EL, 0x2FB6_FF11_0441_A2A8L, + /* -199 */ 0x7A78_DA6A_8AD6_5C9DL, 0x7BA4_BED5_4552_0B52L, + /* -198 */ 0x4C8B_8882_96C5_F9E2L, 0x5D46_F745_4B53_4713L, + /* -197 */ 0x5FAE_6AA3_3C77_785BL, 0x3498_B516_9E28_18D8L, + /* -196 */ 0x779A_054C_0B95_5672L, 0x21BE_E25C_45B2_1F0EL, + /* -195 */ 0x4AC0_434F_873D_5607L, 0x3517_4D79_AB8F_5369L, + /* -194 */ 0x5D70_5423_690C_AB89L, 0x225D_20D8_1673_2843L, + /* -193 */ 0x74CC_692C_434F_D66BL, 0x4AF4_690E_1C0F_F253L, + /* -192 */ 0x48FF_C1BB_AA11_E603L, 0x1ED8_C1A8_D189_F774L, + /* -191 */ 0x5B3F_B22A_9496_5F84L, 0x068E_F213_05EC_7551L, + /* -190 */ 0x720F_9EB5_39BB_F765L, 0x0832_AE97_C767_92A5L, + /* -189 */ 0x4749_C331_4415_7A9FL, 0x151F_AD1E_DCA0_BBA8L, + /* -188 */ 0x591C_33FD_951A_D946L, 0x7A67_9866_93C8_EA91L, + /* -187 */ 0x6F63_40FC_FA61_8F98L, 0x5901_7E80_38BB_2536L, + /* -186 */ 0x459E_089E_1C7C_F9BFL, 0x37A0_EF10_2374_F742L, + /* -185 */ 0x5705_8AC5_A39C_382FL, 0x2589_2AD4_2C52_3512L, + /* -184 */ 0x6CC6_ED77_0C83_463BL, 0x0EEB_7589_3766_C256L, + /* -183 */ 0x43FC_546A_67D2_0BE4L, 0x7953_2975_C2A0_3976L, + /* -182 */ 0x54FB_6985_01C6_8EDEL, 0x17A7_F3D3_3348_47D4L, + /* -181 */ 0x6A3A_43E6_4238_3295L, 0x5D91_F0C8_001A_59C8L, + /* -180 */ 0x4264_6A6F_E963_1F9DL, 0x4A7B_367D_0010_781DL, + /* -179 */ 0x52FD_850B_E3BB_E784L, 0x7D1A_041C_4014_9625L, + /* -178 */ 0x67BC_E64E_DCAA_E166L, 0x1C60_8523_5019_BBAEL, + /* -177 */ 0x40D6_0FF1_49EA_CCDFL, 0x71BC_5336_1210_154DL, + /* -176 */ 0x510B_93ED_9C65_8017L, 0x6E2B_6803_9694_1AA0L, + /* -175 */ 0x654E_78E9_037E_E01DL, 0x69B6_4204_7C39_2148L, + /* -174 */ 0x7EA2_1723_445E_9825L, 0x2423_D285_9B47_6999L, + /* -173 */ 0x4F25_4E76_0ABB_1F17L, 0x2696_6393_810C_A200L, + /* -172 */ 0x62EE_A213_8D69_E6DDL, 0x103B_FC78_614F_CA80L, + /* -171 */ 0x7BAA_4A98_70C4_6094L, 0x344A_FB96_79A3_BD20L, + /* -170 */ 0x4D4A_6E9F_467A_BC5CL, 0x60AE_DD3E_0C06_5634L, + /* -169 */ 0x609D_0A47_1819_6B73L, 0x78DA_948D_8F07_EBC1L, + /* -168 */ 0x78C4_4CD8_DE1F_C650L, 0x7711_39B0_F2C9_E6B1L, + /* -167 */ 0x4B7A_B007_8AD3_DBF2L, 0x4A6A_C40E_97BE_302FL, + /* -166 */ 0x5E59_5C09_6D88_D2EFL, 0x1D05_7512_3DAD_BC3AL, + /* -165 */ 0x75EF_B30B_C8EB_07ABL, 0x0446_D256_CD19_2B49L, + /* -164 */ 0x49B5_CFE7_5D92_E4CAL, 0x72AC_4376_402F_BB0EL, + /* -163 */ 0x5C23_43E1_34F7_9DFDL, 0x4F57_5453_D03B_A9D1L, + /* -162 */ 0x732C_14D9_8235_857DL, 0x032D_2968_C44A_9445L, + /* -161 */ 0x47FB_8D07_F161_736EL, 0x11FC_39E1_7AAE_9CABL, + /* -160 */ 0x59FA_7049_EDB9_D049L, 0x567B_4859_D95A_43D6L, + /* -159 */ 0x7079_0C5C_6928_445CL, 0x0C1A_1A70_4FB0_D4CCL, + /* -158 */ 0x464B_A7B9_C1B9_2AB9L, 0x4790_5086_31CE_84FFL, + /* -157 */ 0x57DE_91A8_3227_7567L, 0x7974_64A7_BE42_263FL, + /* -156 */ 0x6DD6_3612_3EB1_52C1L, 0x77D1_7DD1_ADD2_AFCFL, + /* -155 */ 0x44A5_E1CB_672E_D3B9L, 0x1AE2_EEA3_0CA3_ADE1L, + /* -154 */ 0x55CF_5A3E_40FA_88A7L, 0x419B_AA4B_CFCC_995AL, + /* -153 */ 0x6B43_30CD_D139_2AD1L, 0x3202_94DE_C3BF_BFB0L, + /* -152 */ 0x4309_FE80_A2C3_BAC2L, 0x6F41_9D0B_3A57_D7CEL, + /* -151 */ 0x53CC_7E20_CB74_A973L, 0x4B12_044E_08ED_CDC2L, + /* -150 */ 0x68BF_9DA8_FE51_D3D0L, 0x3DD6_8561_8B29_4132L, + /* -149 */ 0x4177_C289_9EF3_2462L, 0x26A6_135C_F6F9_C8BFL, + /* -148 */ 0x51D5_B32C_06AF_ED7AL, 0x704F_9834_34B8_3AEFL, + /* -147 */ 0x664B_1FF7_085B_E8D9L, 0x4C63_7E41_41E6_49ABL, + /* -146 */ 0x7FDD_E7F4_CA72_E30FL, 0x7F7C_5DD1_925F_DC15L, + /* -145 */ 0x4FEA_B0F8_FE87_CDE9L, 0x7FAD_BAA2_FB7B_E98DL, + /* -144 */ 0x63E5_5D37_3E29_C164L, 0x3F99_294B_BA5A_E3F1L, + /* -143 */ 0x7CDE_B485_0DB4_31BDL, 0x4F7F_739E_A8F1_9CEDL, + /* -142 */ 0x4E0B_30D3_2890_9F16L, 0x41AF_A843_2997_0214L, + /* -141 */ 0x618D_FD07_F2B4_C6DCL, 0x121B_9253_F3FC_C299L, + /* -140 */ 0x79F1_7C49_EF61_F893L, 0x16A2_76E8_F0FB_F33FL, + /* -139 */ 0x4C36_EDAE_359D_3B5BL, 0x7E25_8A51_969D_7808L, + /* -138 */ 0x5F44_A919_C304_8A32L, 0x7DAE_ECE5_FC44_D609L, + /* -137 */ 0x7715_D360_33C5_ACBFL, 0x5D1A_A81F_7B56_0B8CL, + /* -136 */ 0x4A6D_A41C_205B_8BF7L, 0x6A30_A913_AD15_C738L, + /* -135 */ 0x5D09_0D23_2872_6EF5L, 0x64BC_D358_985B_3905L, + /* -134 */ 0x744B_506B_F28F_0AB3L, 0x1DEC_082E_BE72_0746L, + /* -133 */ 0x48AF_1243_7799_66B0L, 0x02B3_851D_3707_448CL, + /* -132 */ 0x5ADA_D6D4_557F_C05CL, 0x0360_6664_84C9_15AFL, + /* -131 */ 0x7191_8C89_6ADF_B073L, 0x0438_7FFD_A5FB_5B1BL, + /* -130 */ 0x46FA_F7D5_E2CB_CE47L, 0x72A3_4FFE_87BD_18F1L, + /* -129 */ 0x58B9_B5CB_5B7E_C1D9L, 0x6F4C_23FE_29AC_5F2DL, + /* -128 */ 0x6EE8_233E_325E_7250L, 0x2B1F_2CFD_B417_76F8L, + /* -127 */ 0x4551_1606_DF7B_0772L, 0x1AF3_7C1E_908E_AA5BL, + /* -126 */ 0x56A5_5B88_9759_C94EL, 0x61B0_5B26_34B2_54F2L, + /* -125 */ 0x6C4E_B26A_BD30_3BA2L, 0x3A1C_71EF_C1DE_EA2EL, + /* -124 */ 0x43B1_2F82_B63E_2545L, 0x4451_C735_D92B_525DL, + /* -123 */ 0x549D_7B63_63CD_AE96L, 0x7566_3903_4F76_26F4L, + /* -122 */ 0x69C4_DA3C_3CC1_1A3CL, 0x52BF_C744_2353_B0B1L, + /* -121 */ 0x421B_0865_A5F8_B065L, 0x73B7_DC8A_9614_4E6FL, + /* -120 */ 0x52A1_CA7F_0F76_DC7FL, 0x30A5_D3AD_3B99_620BL, + /* -119 */ 0x674A_3D1E_D354_939FL, 0x1CCF_4898_8A7F_BA8DL, + /* -118 */ 0x408E_6633_4414_DC43L, 0x4201_8D5F_568F_D498L, + /* -117 */ 0x50B1_FFC0_151A_1354L, 0x3281_F0B7_2C33_C9BEL, + /* -116 */ 0x64DE_7FB0_1A60_9829L, 0x3F22_6CE4_F740_BC2EL, + /* -115 */ 0x7E16_1F9C_20F8_BE33L, 0x6EEB_081E_3510_EB39L, + /* -114 */ 0x4ECD_D3C1_949B_76E0L, 0x3552_E512_E12A_9304L, + /* -113 */ 0x6281_48B1_F9C2_5498L, 0x42A7_9E57_9975_37C5L, + /* -112 */ 0x7B21_9ADE_7832_E9BEL, 0x5351_85ED_7FD2_85B6L, + /* -111 */ 0x4CF5_00CB_0B1F_D217L, 0x1412_F3B4_6FE3_9392L, + /* -110 */ 0x6032_40FD_CDE7_C69CL, 0x7917_B0A1_8BDC_7876L, + /* -109 */ 0x783E_D13D_4161_B844L, 0x175D_9CC9_EED3_9694L, + /* -108 */ 0x4B27_42C6_48DD_132AL, 0x4E9A_81FE_3544_3E1CL, + /* -107 */ 0x5DF1_1377_DB14_57F5L, 0x2241_227D_C295_4DA3L, + /* -106 */ 0x756D_5855_D1D9_6DF2L, 0x4AD1_6B1D_333A_A10CL, + /* -105 */ 0x4964_5735_A327_E4B7L, 0x4EC2_E2F2_4004_A4A8L, + /* -104 */ 0x5BBD_6D03_0BF1_DDE5L, 0x4273_9BAE_D005_CDD2L, + /* -103 */ 0x72AC_C843_CEEE_555EL, 0x7310_829A_8407_4146L, + /* -102 */ 0x47AB_FD2A_6154_F55BL, 0x27EA_51A0_9284_88CCL, + /* -101 */ 0x5996_FC74_F9AA_32B2L, 0x11E4_E608_B725_AAFFL, + /* -100 */ 0x6FFC_BB92_3814_BF5EL, 0x565E_1F8A_E4EF_15BEL, + /* -99 */ 0x45FD_F53B_630C_F79BL, 0x15FA_D3B6_CF15_6D97L, + /* -98 */ 0x577D_728A_3BD0_3581L, 0x7B79_88A4_82DA_C8FDL, + /* -97 */ 0x6D5C_CF2C_CAC4_42E2L, 0x3A57_EACD_A391_7B3CL, + /* -96 */ 0x445A_017B_FEBA_A9CDL, 0x4476_F2C0_863A_ED06L, + /* -95 */ 0x5570_81DA_FE69_5440L, 0x7594_AF70_A7C9_A847L, + /* -94 */ 0x6ACC_A251_BE03_A951L, 0x12F9_DB4C_D1BC_1258L, + /* -93 */ 0x42BF_E573_16C2_49D2L, 0x5BDC_2910_0315_8B77L, + /* -92 */ 0x536F_DECF_DC72_DC47L, 0x32D3_3354_03DA_EE55L, + /* -91 */ 0x684B_D683_D38F_9359L, 0x1F88_0029_04D1_A9EAL, + /* -90 */ 0x412F_6612_6439_BC17L, 0x63B5_0019_A303_0A33L, + /* -89 */ 0x517B_3F96_FD48_2B1DL, 0x5CA2_4020_0BC3_CCBFL, + /* -88 */ 0x65DA_0F7C_BC9A_35E5L, 0x13CA_D028_0EB4_BFEFL, + /* -87 */ 0x7F50_935B_EBC0_C35EL, 0x38BD_8432_1261_EFEBL, + /* -86 */ 0x4F92_5C19_7358_7A1BL, 0x0376_729F_4B7D_35F3L, + /* -85 */ 0x6376_F31F_D02E_98A1L, 0x6454_0F47_1E5C_836FL, + /* -84 */ 0x7C54_AFE7_C43A_3ECAL, 0x1D69_1318_E5F3_A44BL, + /* -83 */ 0x4DB4_EDF0_DAA4_673EL, 0x3261_ABEF_8FB8_46AFL, + /* -82 */ 0x6122_296D_114D_810DL, 0x7EFA_16EB_73A6_585BL, + /* -81 */ 0x796A_B3C8_55A0_E151L, 0x3EB8_9CA6_508F_EE71L, + /* -80 */ 0x4BE2_B05D_3584_8CD2L, 0x7733_61E7_F259_F507L, + /* -79 */ 0x5EDB_5C74_82E5_B007L, 0x5500_3A61_EEF0_7249L, + /* -78 */ 0x7692_3391_A39F_1C09L, 0x4A40_48FA_6AAC_8EDBL, + /* -77 */ 0x4A1B_603B_0643_7185L, 0x7E68_2D9C_82AB_D949L, + /* -76 */ 0x5CA2_3849_C7D4_4DE7L, 0x3E02_3903_A356_CF9BL, + /* -75 */ 0x73CA_C65C_39C9_6161L, 0x2D82_C744_8C2C_8382L, + /* -74 */ 0x485E_BBF9_A41D_DCDCL, 0x6C71_BC8A_D79B_D231L, + /* -73 */ 0x5A76_6AF8_0D25_5414L, 0x078E_2BAD_8D82_C6BDL, + /* -72 */ 0x7114_05B6_106E_A919L, 0x0971_B698_F0E3_786DL, + /* -71 */ 0x46AC_8391_CA45_29AFL, 0x55E7_121F_968E_2B44L, + /* -70 */ 0x5857_A476_3CD6_741BL, 0x4B60_D6A7_7C31_B615L, + /* -69 */ 0x6E6D_8D93_CC0C_1122L, 0x3E39_0C51_5B3E_239AL, + /* -68 */ 0x4504_787C_5F87_8AB5L, 0x46E3_A7B2_D906_D640L, + /* -67 */ 0x5645_969B_7769_6D62L, 0x789C_919F_8F48_8BD0L, + /* -66 */ 0x6BD6_FC42_5543_C8BBL, 0x56C3_B607_731A_AEC4L, + /* -65 */ 0x4366_5DA9_754A_5D75L, 0x263A_51C4_A7F0_AD3BL, + /* -64 */ 0x543F_F513_D29C_F4D2L, 0x4FC8_E635_D1EC_D88AL, + /* -63 */ 0x694F_F258_C744_3207L, 0x23BB_1FC3_4668_0EACL, + /* -62 */ 0x41D1_F777_7C8A_9F44L, 0x4654_F3DA_0C01_092CL, + /* -61 */ 0x5246_7555_5BAD_4715L, 0x57EA_30D0_8F01_4B76L, + /* -60 */ 0x66D8_12AA_B298_98DBL, 0x0DE4_BD04_B2C1_9E54L, + /* -59 */ 0x4047_0BAA_AF9F_5F88L, 0x78AE_F622_EFB9_02F5L, + /* -58 */ 0x5058_CE95_5B87_376BL, 0x16DA_B3AB_ABA7_43B2L, + /* -57 */ 0x646F_023A_B269_0545L, 0x7C91_6096_9691_149EL, + /* -56 */ 0x7D8A_C2C9_5F03_4697L, 0x3BB5_B8BC_3C35_59C5L, + /* -55 */ 0x4E76_B9BD_DB62_0C1EL, 0x5551_9375_A5A1_581BL, + /* -54 */ 0x6214_682D_523A_8F26L, 0x2AA5_F853_0F09_AE22L, + /* -53 */ 0x7A99_8238_A6C9_32EFL, 0x754F_7667_D2CC_19ABL, + /* -52 */ 0x4C9F_F163_683D_BFD5L, 0x7951_AA00_E3BF_900BL, + /* -51 */ 0x5FC7_EDBC_424D_2FCBL, 0x37A6_1481_1CAF_740DL, + /* -50 */ 0x77B9_E92B_52E0_7BBEL, 0x258F_99A1_63DB_5111L, + /* -49 */ 0x4AD4_31BB_13CC_4D56L, 0x7779_C004_DE69_12ABL, + /* -48 */ 0x5D89_3E29_D8BF_60ACL, 0x5558_3006_1603_5755L, + /* -47 */ 0x74EB_8DB4_4EEF_38D7L, 0x6AAE_3C07_9B84_2D2AL, + /* -46 */ 0x4913_3890_B155_8386L, 0x72AC_E584_C132_9C3BL, + /* -45 */ 0x5B58_06B4_DDAA_E468L, 0x4F58_1EE5_F17F_4349L, + /* -44 */ 0x722E_0862_1515_9D82L, 0x632E_269F_6DDF_141BL, + /* -43 */ 0x475C_C53D_4D2D_8271L, 0x5DFC_D823_A4AB_6C91L, + /* -42 */ 0x5933_F68C_A078_E30EL, 0x157C_0E2C_8DD6_47B5L, + /* -41 */ 0x6F80_F42F_C897_1BD1L, 0x5ADB_11B7_B14B_D9A3L, + /* -40 */ 0x45B0_989D_DD5E_7163L, 0x08C8_EB12_CECF_6806L, + /* -39 */ 0x571C_BEC5_54B6_0DBBL, 0x6AFB_25D7_8283_4207L, + /* -38 */ 0x6CE3_EE76_A9E3_912AL, 0x65B9_EF4D_6324_1289L, + /* -37 */ 0x440E_750A_2A2E_3ABAL, 0x5F94_3590_5DF6_8B96L, + /* -36 */ 0x5512_124C_B4B9_C969L, 0x3779_42F4_7574_2E7BL, + /* -35 */ 0x6A56_96DF_E1E8_3BC3L, 0x6557_93B1_92D1_3A1AL, + /* -34 */ 0x4276_1E4B_ED31_255AL, 0x2F56_BC4E_FBC2_C450L, + /* -33 */ 0x5313_A5DE_E87D_6EB0L, 0x7B2C_6B62_BAB3_7564L, + /* -32 */ 0x67D8_8F56_A29C_CA5DL, 0x19F7_863B_6960_52BDL, + /* -31 */ 0x40E7_5996_25A1_FE7AL, 0x203A_B3E5_21DC_33B6L, + /* -30 */ 0x5121_2FFB_AF0A_7E18L, 0x6849_60DE_6A53_40A4L, + /* -29 */ 0x6569_7BFA_9ACD_1D9FL, 0x025B_B916_04E8_10CDL, + /* -28 */ 0x7EC3_DAF9_4180_6506L, 0x62F2_A75B_8622_1500L, + /* -27 */ 0x4F3A_68DB_C8F0_3F24L, 0x1DD7_A899_33D5_4D20L, + /* -26 */ 0x6309_0312_BB2C_4EEDL, 0x254D_92BF_80CA_A068L, + /* -25 */ 0x7BCB_43D7_69F7_62A8L, 0x4EA0_F76F_60FD_4882L, + /* -24 */ 0x4D5F_0A66_A23A_9DA9L, 0x3124_9AA5_9C9E_4D51L, + /* -23 */ 0x60B6_CD00_4AC9_4513L, 0x5D6D_C14F_03C5_E0A5L, + /* -22 */ 0x78E4_8040_5D7B_9658L, 0x54C9_31A2_C4B7_58CFL, + /* -21 */ 0x4B8E_D028_3A6D_3DF7L, 0x34FD_BF05_BAF2_9781L, + /* -20 */ 0x5E72_8432_4908_8D75L, 0x223D_2EC7_29AF_3D62L, + /* -19 */ 0x760F_253E_DB4A_B0D2L, 0x4ACC_7A78_F41B_0CBAL, + /* -18 */ 0x49C9_7747_490E_AE83L, 0x4EBF_CC8B_9890_E7F4L, + /* -17 */ 0x5C3B_D519_1B52_5A24L, 0x426F_BFAE_7EB5_21F1L, + /* -16 */ 0x734A_CA5F_6226_F0ADL, 0x530B_AF9A_1E62_6A6DL, + /* -15 */ 0x480E_BE7B_9D58_566CL, 0x43E7_4DC0_52FD_8285L, + /* -14 */ 0x5A12_6E1A_84AE_6C07L, 0x54E1_2130_67BC_E326L, + /* -13 */ 0x7097_09A1_25DA_0709L, 0x4A19_697C_81AC_1BEFL, + /* -12 */ 0x465E_6604_B7A8_4465L, 0x7E4F_E1ED_D10B_9175L, + /* -11 */ 0x57F5_FF85_E592_557FL, 0x3DE3_DA69_454E_75D3L, + /* -10 */ 0x6DF3_7F67_5EF6_EADFL, 0x2D5C_D103_96A2_1347L, + /* -9 */ 0x44B8_2FA0_9B5A_52CBL, 0x4C5A_02A2_3E25_4C0DL, + /* -8 */ 0x55E6_3B88_C230_E77EL, 0x3F70_834A_CDAE_9F10L, + /* -7 */ 0x6B5F_CA6A_F2BD_215EL, 0x0F4C_A41D_811A_46D4L, + /* -6 */ 0x431B_DE82_D7B6_34DAL, 0x698F_E692_70B0_6C44L, + /* -5 */ 0x53E2_D623_8DA3_C211L, 0x43F3_E037_0CDC_8755L, + /* -4 */ 0x68DB_8BAC_710C_B295L, 0x74F0_D844_D013_A92BL, + /* -3 */ 0x4189_374B_C6A7_EF9DL, 0x5916_872B_020C_49BBL, + /* -2 */ 0x51EB_851E_B851_EB85L, 0x0F5C_28F5_C28F_5C29L, + /* -1 */ 0x6666_6666_6666_6666L, 0x3333_3333_3333_3334L, + /* 0 */ 0x4000_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 1 */ 0x5000_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 2 */ 0x6400_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 3 */ 0x7D00_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 4 */ 0x4E20_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 5 */ 0x61A8_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 6 */ 0x7A12_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 7 */ 0x4C4B_4000_0000_0000L, 0x0000_0000_0000_0001L, + /* 8 */ 0x5F5E_1000_0000_0000L, 0x0000_0000_0000_0001L, + /* 9 */ 0x7735_9400_0000_0000L, 0x0000_0000_0000_0001L, + /* 10 */ 0x4A81_7C80_0000_0000L, 0x0000_0000_0000_0001L, + /* 11 */ 0x5D21_DBA0_0000_0000L, 0x0000_0000_0000_0001L, + /* 12 */ 0x746A_5288_0000_0000L, 0x0000_0000_0000_0001L, + /* 13 */ 0x48C2_7395_0000_0000L, 0x0000_0000_0000_0001L, + /* 14 */ 0x5AF3_107A_4000_0000L, 0x0000_0000_0000_0001L, + /* 15 */ 0x71AF_D498_D000_0000L, 0x0000_0000_0000_0001L, + /* 16 */ 0x470D_E4DF_8200_0000L, 0x0000_0000_0000_0001L, + /* 17 */ 0x58D1_5E17_6280_0000L, 0x0000_0000_0000_0001L, + /* 18 */ 0x6F05_B59D_3B20_0000L, 0x0000_0000_0000_0001L, + /* 19 */ 0x4563_9182_44F4_0000L, 0x0000_0000_0000_0001L, + /* 20 */ 0x56BC_75E2_D631_0000L, 0x0000_0000_0000_0001L, + /* 21 */ 0x6C6B_935B_8BBD_4000L, 0x0000_0000_0000_0001L, + /* 22 */ 0x43C3_3C19_3756_4800L, 0x0000_0000_0000_0001L, + /* 23 */ 0x54B4_0B1F_852B_DA00L, 0x0000_0000_0000_0001L, + /* 24 */ 0x69E1_0DE7_6676_D080L, 0x0000_0000_0000_0001L, + /* 25 */ 0x422C_A8B0_A00A_4250L, 0x0000_0000_0000_0001L, + /* 26 */ 0x52B7_D2DC_C80C_D2E4L, 0x0000_0000_0000_0001L, + /* 27 */ 0x6765_C793_FA10_079DL, 0x0000_0000_0000_0001L, + /* 28 */ 0x409F_9CBC_7C4A_04C2L, 0x1000_0000_0000_0001L, + /* 29 */ 0x50C7_83EB_9B5C_85F2L, 0x5400_0000_0000_0001L, + /* 30 */ 0x64F9_64E6_8233_A76FL, 0x2900_0000_0000_0001L, + /* 31 */ 0x7E37_BE20_22C0_914BL, 0x1340_0000_0000_0001L, + /* 32 */ 0x4EE2_D6D4_15B8_5ACEL, 0x7C08_0000_0000_0001L, + /* 33 */ 0x629B_8C89_1B26_7182L, 0x5B0A_0000_0000_0001L, + /* 34 */ 0x7B42_6FAB_61F0_0DE3L, 0x31CC_8000_0000_0001L, + /* 35 */ 0x4D09_85CB_1D36_08AEL, 0x0F1F_D000_0000_0001L, + /* 36 */ 0x604B_E73D_E483_8AD9L, 0x52E7_C400_0000_0001L, + /* 37 */ 0x785E_E10D_5DA4_6D90L, 0x07A1_B500_0000_0001L, + /* 38 */ 0x4B3B_4CA8_5A86_C47AL, 0x04C5_1120_0000_0001L, + /* 39 */ 0x5E0A_1FD2_7128_7598L, 0x45F6_5568_0000_0001L, + /* 40 */ 0x758C_A7C7_0D72_92FEL, 0x5773_EAC2_0000_0001L, + /* 41 */ 0x4977_E8DC_6867_9BDFL, 0x16A8_72B9_4000_0001L, + /* 42 */ 0x5BD5_E313_8281_82D6L, 0x7C52_8F67_9000_0001L, + /* 43 */ 0x72CB_5BD8_6321_E38CL, 0x5B67_3341_7400_0001L, + /* 44 */ 0x47BF_1967_3DF5_2E37L, 0x7920_8008_E880_0001L, + /* 45 */ 0x59AE_DFC1_0D72_79C5L, 0x7768_A00B_22A0_0001L, + /* 46 */ 0x701A_97B1_50CF_1837L, 0x3542_C80D_EB48_0001L, + /* 47 */ 0x4610_9ECE_D281_6F22L, 0x5149_BD08_B30D_0001L, + /* 48 */ 0x5794_C682_8721_CAEBL, 0x259C_2C4A_DFD0_4001L, + /* 49 */ 0x6D79_F823_28EA_3DA6L, 0x0F03_375D_97C4_5001L, + /* 50 */ 0x446C_3B15_F992_6687L, 0x6962_029A_7EDA_B201L, + /* 51 */ 0x5587_49DB_77F7_0029L, 0x63BA_8341_1E91_5E81L, + /* 52 */ 0x6AE9_1C52_55F4_C034L, 0x1CA9_2411_6635_B621L, + /* 53 */ 0x42D1_B1B3_75B8_F820L, 0x51E9_B68A_DFE1_91D5L, + /* 54 */ 0x5386_1E20_5327_3628L, 0x6664_242D_97D9_F64AL, + /* 55 */ 0x6867_A5A8_67F1_03B2L, 0x7FFD_2D38_FDD0_73DCL, + /* 56 */ 0x4140_C789_40F6_A24FL, 0x6FFE_3C43_9EA2_486AL, + /* 57 */ 0x5190_F96B_9134_4AE3L, 0x6BFD_CB54_864A_DA84L, + /* 58 */ 0x65F5_37C6_7581_5D9CL, 0x66FD_3E29_A7DD_9125L, + /* 59 */ 0x7F72_85B8_12E1_B504L, 0x00BC_8DB4_11D4_F56EL, + /* 60 */ 0x4FA7_9393_0BCD_1122L, 0x4075_D890_8B25_1965L, + /* 61 */ 0x6391_7877_CEC0_556BL, 0x1093_4EB4_ADEE_5FBEL, + /* 62 */ 0x7C75_D695_C270_6AC5L, 0x74B8_2261_D969_F7ADL, + /* 63 */ 0x4DC9_A61D_9986_42BBL, 0x58F3_157D_27E2_3ACCL, + /* 64 */ 0x613C_0FA4_FFE7_D36AL, 0x4F2F_DADC_71DA_C97FL, + /* 65 */ 0x798B_138E_3FE1_C845L, 0x22FB_D193_8E51_7BDFL, + /* 66 */ 0x4BF6_EC38_E7ED_1D2BL, 0x25DD_62FC_38F2_ED6CL, + /* 67 */ 0x5EF4_A747_21E8_6476L, 0x0F54_BBBB_472F_A8C6L, + /* 68 */ 0x76B1_D118_EA62_7D93L, 0x5329_EAAA_18FB_92F8L, + /* 69 */ 0x4A2F_22AF_927D_8E7CL, 0x23FA_32AA_4F9D_3BDBL, + /* 70 */ 0x5CBA_EB5B_771C_F21BL, 0x2CF8_BF54_E384_8AD2L, + /* 71 */ 0x73E9_A632_54E4_2EA2L, 0x1836_EF2A_1C65_AD86L, + /* 72 */ 0x4872_07DF_750E_9D25L, 0x2F22_557A_51BF_8C74L, + /* 73 */ 0x5A8E_89D7_5252_446EL, 0x5AEA_EAD8_E62F_6F91L, + /* 74 */ 0x7132_2C4D_26E6_D58AL, 0x31A5_A58F_1FBB_4B75L, + /* 75 */ 0x46BF_5BB0_3850_4576L, 0x3F07_8779_73D5_0F29L, + /* 76 */ 0x586F_329C_4664_56D4L, 0x0EC9_6957_D0CA_52F3L, + /* 77 */ 0x6E8A_FF43_57FD_6C89L, 0x127B_C3AD_C4FC_E7B0L, + /* 78 */ 0x4516_DF8A_16FE_63D5L, 0x5B8D_5A4C_9B1E_10CEL, + /* 79 */ 0x565C_976C_9CBD_FCCBL, 0x1270_B0DF_C1E5_9502L, + /* 80 */ 0x6BF3_BD47_C3ED_7BFDL, 0x770C_DD17_B25E_FA42L, + /* 81 */ 0x4378_564C_DA74_6D7EL, 0x5A68_0A2E_CF7B_5C69L, + /* 82 */ 0x5456_6BE0_1111_88DEL, 0x3102_0CBA_835A_3384L, + /* 83 */ 0x696C_06D8_1555_EB15L, 0x7D42_8FE9_2430_C065L, + /* 84 */ 0x41E3_8447_0D55_B2EDL, 0x5E49_99F1_B69E_783FL, + /* 85 */ 0x525C_6558_D0AB_1FA9L, 0x15DC_006E_2446_164FL, + /* 86 */ 0x66F3_7EAF_04D5_E793L, 0x3B53_0089_AD57_9BE2L, + /* 87 */ 0x4058_2F2D_6305_B0BCL, 0x1513_E056_0C56_C16EL, + /* 88 */ 0x506E_3AF8_BBC7_1CEBL, 0x1A58_D86B_8F6C_71C9L, + /* 89 */ 0x6489_C9B6_EAB8_E426L, 0x00EF_0E86_7347_8E3BL, + /* 90 */ 0x7DAC_3C24_A567_1D2FL, 0x412A_D228_1019_71C9L, + /* 91 */ 0x4E8B_A596_E760_723DL, 0x58BA_C359_0A0F_E71EL, + /* 92 */ 0x622E_8EFC_A138_8ECDL, 0x0EE9_742F_4C93_E0E6L, + /* 93 */ 0x7ABA_32BB_C986_B280L, 0x32A3_D13B_1FB8_D91FL, + /* 94 */ 0x4CB4_5FB5_5DF4_2F90L, 0x1FA6_62C4_F3D3_87B3L, + /* 95 */ 0x5FE1_77A2_B571_3B74L, 0x278F_FB76_30C8_69A0L, + /* 96 */ 0x77D9_D58B_62CD_8A51L, 0x3173_FA53_BCFA_8408L, + /* 97 */ 0x4AE8_2577_1DC0_7672L, 0x6EE8_7C74_561C_9285L, + /* 98 */ 0x5DA2_2ED4_E530_940FL, 0x4AA2_9B91_6BA3_B726L, + /* 99 */ 0x750A_BA8A_1E7C_B913L, 0x3D4B_4275_C68C_A4F0L, + /* 100 */ 0x4926_B496_530D_F3ACL, 0x164F_0989_9C17_E716L, + /* 101 */ 0x5B70_61BB_E7D1_7097L, 0x1BE2_CBEC_031D_E0DCL, + /* 102 */ 0x724C_7A2A_E1C5_CCBDL, 0x02DB_7EE7_03E5_5912L, + /* 103 */ 0x476F_CC5A_CD1B_9FF6L, 0x11C9_2F50_626F_57ACL, + /* 104 */ 0x594B_BF71_8062_87F3L, 0x563B_7B24_7B0B_2D96L, + /* 105 */ 0x6F9E_AF4D_E07B_29F0L, 0x4BCA_59ED_99CD_F8FCL, + /* 106 */ 0x45C3_2D90_AC4C_FA36L, 0x2F5E_7834_8020_BB9EL, + /* 107 */ 0x5733_F8F4_D760_38C3L, 0x7B36_1641_A028_EA85L, + /* 108 */ 0x6D00_F732_0D38_46F4L, 0x7A03_9BD2_0833_2526L, + /* 109 */ 0x4420_9A7F_4843_2C59L, 0x0C42_4163_451F_F738L, + /* 110 */ 0x5528_C11F_1A53_F76FL, 0x2F52_D1BC_1667_F506L, + /* 111 */ 0x6A72_F166_E0E8_F54BL, 0x1B27_862B_1C01_F247L, + /* 112 */ 0x4287_D6E0_4C91_994FL, 0x00F8_B3DA_F181_376DL, + /* 113 */ 0x5329_CC98_5FB5_FFA2L, 0x6136_E0D1_ADE1_8548L, + /* 114 */ 0x67F4_3FBE_77A3_7F8BL, 0x3984_9906_1959_E699L, + /* 115 */ 0x40F8_A7D7_0AC6_2FB7L, 0x13F2_DFA3_CFD8_3020L, + /* 116 */ 0x5136_D1CC_CD77_BBA4L, 0x78EF_978C_C3CE_3C28L, + /* 117 */ 0x6584_8640_00D5_AA8EL, 0x172B_7D6F_F4C1_CB32L, + /* 118 */ 0x7EE5_A7D0_010B_1531L, 0x5CF6_5CCB_F1F2_3DFEL, + /* 119 */ 0x4F4F_88E2_00A6_ED3FL, 0x0A19_F9FF_7737_66BFL, + /* 120 */ 0x6323_6B1A_80D0_A88EL, 0x6CA0_787F_5505_406FL, + /* 121 */ 0x7BEC_45E1_2104_D2B2L, 0x47C8_969F_2A46_908AL, + /* 122 */ 0x4D73_ABAC_B4A3_03AFL, 0x4CDD_5E23_7A6C_1A57L, + /* 123 */ 0x60D0_9697_E1CB_C49BL, 0x4014_B5AC_5907_20ECL, + /* 124 */ 0x7904_BC3D_DA3E_B5C2L, 0x3019_E317_6F48_E927L, + /* 125 */ 0x4BA2_F5A6_A867_3199L, 0x3E10_2DEE_A58D_91B9L, + /* 126 */ 0x5E8B_B310_5280_FDFFL, 0x6D94_396A_4EF0_F627L, + /* 127 */ 0x762E_9FD4_6721_3D7FL, 0x68F9_47C4_E2AD_33B0L, + /* 128 */ 0x49DD_23E4_C074_C66FL, 0x719B_CCDB_0DAC_404EL, + /* 129 */ 0x5C54_6CDD_F091_F80BL, 0x6E02_C011_D117_5062L, + /* 130 */ 0x7369_8815_6CB6_760EL, 0x6983_7016_455D_247AL, + /* 131 */ 0x4821_F50D_63F2_09C9L, 0x21F2_260D_EB5A_36CCL, + /* 132 */ 0x5A2A_7250_BCEE_8C3BL, 0x4A6E_AF91_6630_C47FL, + /* 133 */ 0x70B5_0EE4_EC2A_2F4AL, 0x3D0A_5B75_BFBC_F59FL, + /* 134 */ 0x4671_294F_139A_5D8EL, 0x4626_7929_97D6_1984L, + /* 135 */ 0x580D_73A2_D880_F4F2L, 0x17B0_1773_FDCB_9FE4L, + /* 136 */ 0x6E10_D08B_8EA1_322EL, 0x5D9C_1D50_FD3E_87DDL, + /* 137 */ 0x44CA_8257_3924_BF5DL, 0x1A81_9252_9E47_14EBL, + /* 138 */ 0x55FD_22ED_076D_EF34L, 0x4121_F6E7_45D8_DA25L, + /* 139 */ 0x6B7C_6BA8_4949_6B01L, 0x516A_74A1_174F_10AEL, + /* 140 */ 0x432D_C349_2DCD_E2E1L, 0x02E2_88E4_AE91_6A6DL, + /* 141 */ 0x53F9_341B_7941_5B99L, 0x239B_2B1D_DA35_C508L, + /* 142 */ 0x68F7_8122_5791_B27FL, 0x4C81_F5E5_50C3_364AL, + /* 143 */ 0x419A_B0B5_76BB_0F8FL, 0x5FD1_39AF_527A_01EFL, + /* 144 */ 0x5201_5CE2_D469_D373L, 0x57C5_881B_2718_826AL, + /* 145 */ 0x6681_B41B_8984_4850L, 0x4DB6_EA21_F0DE_A304L, + /* 146 */ 0x4011_1091_35F2_AD32L, 0x3092_5255_368B_25E3L, + /* 147 */ 0x5015_54B5_836F_587EL, 0x7CB6_E6EA_842D_EF5CL, + /* 148 */ 0x641A_A9E2_E44B_2E9EL, 0x5BE4_A0A5_2539_6B32L, + /* 149 */ 0x7D21_545B_9D5D_FA46L, 0x32DD_C8CE_6E87_C5FFL, + /* 150 */ 0x4E34_D4B9_425A_BC6BL, 0x7FCA_9D81_0514_DBBFL, + /* 151 */ 0x61C2_09E7_92F1_6B86L, 0x7FBD_44E1_465A_12AFL, + /* 152 */ 0x7A32_8C61_77AD_C668L, 0x5FAC_9619_97F0_975BL, + /* 153 */ 0x4C5F_97BC_EACC_9C01L, 0x3BCB_DDCF_FEF6_5E99L, + /* 154 */ 0x5F77_7DAC_257F_C301L, 0x6ABE_D543_FEB3_F63FL, + /* 155 */ 0x7755_5D17_2EDF_B3C2L, 0x256E_8A94_FE60_F3CFL, + /* 156 */ 0x4A95_5A2E_7D4B_D059L, 0x3765_169D_1EFC_9861L, + /* 157 */ 0x5D3A_B0BA_1C9E_C46FL, 0x653E_5C44_66BB_BE7AL, + /* 158 */ 0x7489_5CE8_A3C6_758BL, 0x5E8D_F355_806A_AE18L, + /* 159 */ 0x48D5_DA11_665C_0977L, 0x2B18_B815_7042_ACCFL, + /* 160 */ 0x5B0B_5095_BFF3_0BD5L, 0x15DE_E61A_CC53_5803L, + /* 161 */ 0x71CE_24BB_2FEF_CECAL, 0x3B56_9FA1_7F68_2E03L, + /* 162 */ 0x4720_D6F4_FDF5_E13EL, 0x4516_23C4_EFA1_1CC2L, + /* 163 */ 0x58E9_0CB2_3D73_598EL, 0x165B_ACB6_2B89_63F3L, + /* 164 */ 0x6F23_4FDE_CCD0_2FF1L, 0x5BF2_97E3_B66B_BCEFL, + /* 165 */ 0x4576_11EB_4002_1DF7L, 0x0977_9EEE_5203_5616L, + /* 166 */ 0x56D3_9666_1002_A574L, 0x6BD5_86A9_E684_2B9BL, + /* 167 */ 0x6C88_7BFF_9403_4ED2L, 0x06CA_E854_6025_3682L, + /* 168 */ 0x43D5_4D7F_BC82_1143L, 0x243E_D134_BC17_4211L, + /* 169 */ 0x54CA_A0DF_ABA2_9594L, 0x0D4E_8581_EB1D_1295L, + /* 170 */ 0x69FD_4917_968B_3AF9L, 0x10A2_26E2_65E4_573BL, + /* 171 */ 0x423E_4DAE_BE17_04DBL, 0x5A65_584D_7FAE_B685L, + /* 172 */ 0x52CD_E11A_6D9C_C612L, 0x50FE_AE60_DF9A_6426L, + /* 173 */ 0x6781_5961_0903_F797L, 0x253E_59F9_1780_FD2FL, + /* 174 */ 0x40B0_D7DC_A5A2_7ABEL, 0x4746_F83B_AEB0_9E3EL, + /* 175 */ 0x50DD_0DD3_CF0B_196EL, 0x1918_B64A_9A5C_C5CDL, + /* 176 */ 0x6514_5148_C2CD_DFC9L, 0x5F5E_E3DD_40F3_F740L, + /* 177 */ 0x7E59_659A_F381_57BCL, 0x1736_9CD4_9130_F510L, + /* 178 */ 0x4EF7_DF80_D830_D6D5L, 0x4E82_2204_DABE_992AL, + /* 179 */ 0x62B5_D761_0E3D_0C8BL, 0x0222_AA86_116E_3F75L, + /* 180 */ 0x7B63_4D39_51CC_4FADL, 0x62AB_5527_95C9_CF52L, + /* 181 */ 0x4D1E_1043_D31F_B1CCL, 0x4DAB_1538_BD9E_2193L, + /* 182 */ 0x6065_9454_C7E7_9E3FL, 0x6115_DA86_ED05_A9F8L, + /* 183 */ 0x787E_F969_F9E1_85CFL, 0x595B_5128_A847_1476L, + /* 184 */ 0x4B4F_5BE2_3C2C_F3A1L, 0x67D9_12B9_692C_6CCAL, + /* 185 */ 0x5E23_32DA_CB38_308AL, 0x21CF_5767_C377_87FCL, + /* 186 */ 0x75AB_FF91_7E06_3CACL, 0x6A43_2D41_B455_69FBL, + /* 187 */ 0x498B_7FBA_EEC3_E5ECL, 0x0269_FC49_10B5_623DL, + /* 188 */ 0x5BEE_5FA9_AA74_DF67L, 0x0304_7B5B_54E2_BACCL, + /* 189 */ 0x72E9_F794_1512_1740L, 0x63C5_9A32_2A1B_697FL, + /* 190 */ 0x47D2_3ABC_8D2B_4E88L, 0x3E5B_805F_5A51_21F0L, + /* 191 */ 0x59C6_C96B_B076_222AL, 0x4DF2_6077_30E5_6A6CL, + /* 192 */ 0x7038_7BC6_9C93_AAB5L, 0x216E_F894_FD1E_C506L, + /* 193 */ 0x4623_4D5C_21DC_4AB1L, 0x24E5_5B5D_1E33_3B24L, + /* 194 */ 0x57AC_20B3_2A53_5D5DL, 0x4E1E_B234_65C0_09EDL, + /* 195 */ 0x6D97_28DF_F4E8_34B5L, 0x01A6_5EC1_7F30_0C68L, + /* 196 */ 0x447E_798B_F911_20F1L, 0x1107_FB38_EF7E_07C1L, + /* 197 */ 0x559E_17EE_F755_692DL, 0x3549_FA07_2B5D_89B1L, + /* 198 */ 0x6B05_9DEA_B52A_C378L, 0x629C_7888_F634_EC1EL, + /* 199 */ 0x42E3_82B2_B13A_BA2BL, 0x3DA1_CB55_99E1_1393L, + /* 200 */ 0x539C_635F_5D89_68B6L, 0x2D0A_3E2B_0059_5877L, + /* 201 */ 0x6883_7C37_34EB_C2E3L, 0x784C_CDB5_C06F_AE95L, + /* 202 */ 0x4152_2DA2_8113_59CEL, 0x3B30_0091_9845_CD1DL, + /* 203 */ 0x51A6_B90B_2158_3042L, 0x09FC_00B5_FE57_4065L, + /* 204 */ 0x6610_674D_E9AE_3C52L, 0x4C7B_00E3_7DED_107EL, + /* 205 */ 0x7F94_8121_6419_CB67L, 0x1F99_C11C_5D68_549DL, + /* 206 */ 0x4FBC_D0B4_DE90_1F20L, 0x43C0_18B1_BA61_34E2L, + /* 207 */ 0x63AC_04E2_1634_26E8L, 0x54B0_1EDE_28F9_821BL, + /* 208 */ 0x7C97_061A_9BC1_30A2L, 0x69DC_2695_B337_E2A1L, + /* 209 */ 0x4DDE_63D0_A158_BE65L, 0x6229_981D_9002_EDA5L, + /* 210 */ 0x6155_FCC4_C9AE_EDFFL, 0x1AB3_FE24_F403_A90EL, + /* 211 */ 0x79AB_7BF5_FC1A_A97FL, 0x0160_FDAE_3104_9351L, + /* 212 */ 0x4C0B_2D79_BD90_A9EFL, 0x30DC_9E8C_DEA2_DC13L, + /* 213 */ 0x5F0D_F8D8_2CF4_D46BL, 0x1D13_C630_164B_9318L, + /* 214 */ 0x76D1_770E_3832_0986L, 0x0458_B7BC_1BDE_77DDL, + /* 215 */ 0x4A42_EA68_E31F_45F3L, 0x62B7_72D5_916B_0AEBL, + /* 216 */ 0x5CD3_A503_1BE7_1770L, 0x5B65_4F8A_F5C5_CDA5L, + /* 217 */ 0x7408_8E43_E2E0_DD4CL, 0x723E_A36D_B337_410EL, + /* 218 */ 0x4885_58EA_6DCC_8A50L, 0x0767_2624_9002_88A9L, + /* 219 */ 0x5AA6_AF25_093F_ACE4L, 0x0940_EFAD_B403_2AD3L, + /* 220 */ 0x7150_5AEE_4B8F_981DL, 0x0B91_2B99_2103_F588L, + /* 221 */ 0x46D2_38D4_EF39_BF12L, 0x173A_BB3F_B4A2_7975L, + /* 222 */ 0x5886_C70A_2B08_2ED6L, 0x5D09_6A0F_A1CB_17D2L, + /* 223 */ 0x6EA8_78CC_B5CA_3A8CL, 0x344B_C493_8A3D_DDC7L, + /* 224 */ 0x4529_4B7F_F19E_6497L, 0x60AF_5ADC_3666_AA9CL, + /* 225 */ 0x5673_9E5F_EE05_FDBDL, 0x58DB_3193_4400_5543L, + /* 226 */ 0x6C10_85F7_E987_7D2DL, 0x0F11_FDF8_1500_6A94L, + /* 227 */ 0x438A_53BA_F1F4_AE3CL, 0x196B_3EBB_0D20_429DL, + /* 228 */ 0x546C_E8A9_AE71_D9CBL, 0x1FC6_0E69_D068_5344L, + /* 229 */ 0x6988_22D4_1A0E_503EL, 0x07B7_9204_4482_6815L, + /* 230 */ 0x41F5_15C4_9048_F226L, 0x64D2_BB42_AAD1_810DL, + /* 231 */ 0x5272_5B35_B45B_2EB0L, 0x3E07_6A13_5585_E150L, + /* 232 */ 0x670E_F203_2171_FA5CL, 0x4D89_4498_2AE7_59A4L, + /* 233 */ 0x4069_5741_F4E7_3C79L, 0x7075_CADF_1AD0_9807L, + /* 234 */ 0x5083_AD12_7221_0B98L, 0x2C93_3D96_E184_BE08L, + /* 235 */ 0x64A4_9857_0EA9_4E7EL, 0x37B8_0CFC_99E5_ED8AL, + /* 236 */ 0x7DCD_BE6C_D253_A21EL, 0x05A6_103B_C05F_68EDL, + /* 237 */ 0x4EA0_9704_0374_4552L, 0x6387_CA25_583B_A194L, + /* 238 */ 0x6248_BCC5_0451_56A7L, 0x3C69_BCAE_AE4A_89F9L, + /* 239 */ 0x7ADA_EBF6_4565_AC51L, 0x2B84_2BDA_59DD_2C77L, + /* 240 */ 0x4CC8_D379_EB5F_8BB2L, 0x6B32_9B68_782A_3BCBL, + /* 241 */ 0x5FFB_0858_6637_6E9FL, 0x45FF_4242_9634_CABDL, + /* 242 */ 0x77F9_CA6E_7FC5_4A47L, 0x377F_12D3_3BC1_FD6DL, + /* 243 */ 0x4AFC_1E85_0FDB_4E6CL, 0x52AF_6BC4_0559_3E64L, + /* 244 */ 0x5DBB_2626_53D2_2207L, 0x675B_46B5_06AF_8DFDL, + /* 245 */ 0x7529_EFAF_E8C6_AA89L, 0x6132_1862_485B_717CL, + /* 246 */ 0x493A_35CD_F17C_2A96L, 0x0CBF_4F3D_6D39_26EEL, + /* 247 */ 0x5B88_C341_6DDB_353BL, 0x4FEF_230C_C887_70A9L, + /* 248 */ 0x726A_F411_C952_028AL, 0x43EA_EBCF_FAA9_4CD3L, + /* 249 */ 0x4782_D88B_1DD3_4196L, 0x4A72_D361_FCA9_D004L, + /* 250 */ 0x5963_8EAD_E548_11FCL, 0x1D0F_883A_7BD4_4405L, + /* 251 */ 0x6FBC_7259_5E9A_167BL, 0x2453_6A49_1AC9_5506L, + /* 252 */ 0x45D5_C777_DB20_4E0DL, 0x06B4_226D_B0BD_D524L, + /* 253 */ 0x574B_3955_D1E8_6190L, 0x2861_2B09_1CED_4A6DL, + /* 254 */ 0x6D1E_07AB_4662_79F4L, 0x3279_75CB_6428_9D08L, + /* 255 */ 0x4432_C4CB_0BFD_8C38L, 0x5F8B_E99F_1E99_6225L, + /* 256 */ 0x553F_75FD_CEFC_EF46L, 0x776E_E406_E63F_BAAEL, + /* 257 */ 0x6A8F_537D_42BC_2B18L, 0x554A_9D08_9FCF_A95AL, + /* 258 */ 0x4299_942E_49B5_9AEFL, 0x354E_A225_63E1_C9D8L, + /* 259 */ 0x533F_F939_DC23_01ABL, 0x22A2_4AAE_BCDA_3C4EL, + /* 260 */ 0x680F_F788_532B_C216L, 0x0B4A_DD5A_6C10_CB62L, + /* 261 */ 0x4109_FAB5_33FB_594DL, 0x670E_CA58_838A_7F1DL, + /* 262 */ 0x514C_7962_80FA_2FA1L, 0x20D2_7CEE_A46D_1EE4L, + /* 263 */ 0x659F_97BB_2138_BB89L, 0x4907_1C2A_4D88_669DL, + /* 264 */ 0x7F07_7DA9_E986_EA6BL, 0x7B48_E334_E0EA_8045L, + /* 265 */ 0x4F64_AE8A_31F4_5283L, 0x3D0D_8E01_0C92_902BL, + /* 266 */ 0x633D_DA2C_BE71_6724L, 0x2C50_F181_4FB7_3436L, + /* 267 */ 0x7C0D_50B7_EE0D_C0EDL, 0x3765_2DE1_A3A5_0143L, + /* 268 */ 0x4D88_5272_F4C8_9894L, 0x329F_3CAD_0647_20CAL, + /* 269 */ 0x60EA_670F_B1FA_BEB9L, 0x3F47_0BD8_47D8_E8FDL, + /* 270 */ 0x7925_00D3_9E79_6E67L, 0x6F18_CECE_59CF_233CL, + /* 271 */ 0x4BB7_2084_430B_E500L, 0x756F_8140_F821_7605L, + /* 272 */ 0x5EA4_E8A5_53CE_DE41L, 0x12CB_6191_3629_D387L, + /* 273 */ 0x764E_22CE_A8C2_95D1L, 0x377E_39F5_83B4_4868L, + /* 274 */ 0x49F0_D5C1_2979_9DA2L, 0x72AE_E439_7250_AD41L, + /* 275 */ 0x5C6D_0B31_73D8_050BL, 0x4F5A_9D47_CEE4_D891L, + /* 276 */ 0x7388_4DFD_D0CE_064EL, 0x4331_4499_C29E_0EB6L, + /* 277 */ 0x4835_30BE_A280_C3F1L, 0x09FE_CAE0_19A2_C932L, + /* 278 */ 0x5A42_7CEE_4B20_F4EDL, 0x2C7E_7D98_200B_7B7EL, + /* 279 */ 0x70D3_1C29_DDE9_3228L, 0x579E_1CFE_280E_5A5DL, + /* 280 */ 0x4683_F19A_2AB1_BF59L, 0x36C2_D21E_D908_F87BL, + /* 281 */ 0x5824_EE00_B55E_2F2FL, 0x6473_86A6_8F4B_3699L, + /* 282 */ 0x6E2E_2980_E2B5_BAFBL, 0x5D90_6850_331E_043FL, + /* 283 */ 0x44DC_D9F0_8DB1_94DDL, 0x2A7A_4132_1FF2_C2A8L, + /* 284 */ 0x5614_106C_B11D_FA14L, 0x5518_D17E_A7EF_7352L, + /* 285 */ 0x6B99_1487_DD65_7899L, 0x6A5F_05DE_51EB_5026L, + /* 286 */ 0x433F_ACD4_EA5F_6B60L, 0x127B_63AA_F333_1218L, + /* 287 */ 0x540F_980A_24F7_4638L, 0x171A_3C95_AFFF_D69EL, + /* 288 */ 0x6913_7E0C_AE35_17C6L, 0x1CE0_CBBB_1BFF_CC45L, + /* 289 */ 0x41AC_2EC7_ECE1_2EDBL, 0x720C_7F54_F17F_DFABL, + /* 290 */ 0x5217_3A79_E819_7A92L, 0x6E8F_9F2A_2DDF_D796L, + /* 291 */ 0x669D_0918_621F_D937L, 0x4A33_86F4_B957_CD7BL, + /* 292 */ 0x4022_25AF_3D53_E7C2L, 0x5E60_3458_F3D6_E06DL, + /* 293 */ 0x502A_AF1B_0CA8_E1B3L, 0x35F8_416F_30CC_9888L, + /* 294 */ 0x6435_5AE1_CFD3_1A20L, 0x2376_51CA_FCFF_BEAAL, + /* 295 */ 0x7D42_B19A_43C7_E0A8L, 0x2C53_E63D_BC3F_AE55L, + /* 296 */ 0x4E49_AF00_6A5C_EC69L, 0x1BB4_6FE6_95A7_CCF5L, + /* 297 */ 0x61DC_1AC0_84F4_2783L, 0x42A1_8BE0_3B11_C033L, + /* 298 */ 0x7A53_2170_A631_3164L, 0x3349_EED8_49D6_303FL, + /* 299 */ 0x4C73_F4E6_67DE_BEDEL, 0x600E_3547_2E25_DE28L, + /* 300 */ 0x5F90_F220_01D6_6E96L, 0x3811_C298_F9AF_55B1L, + /* 301 */ 0x7775_2EA8_024C_0A3CL, 0x0616_333F_381B_2B1EL, + /* 302 */ 0x4AA9_3D29_016F_8665L, 0x43CD_E007_8310_FAF3L, + /* 303 */ 0x5D53_8C73_41CB_67FEL, 0x74C1_5809_63D5_39AFL, + /* 304 */ 0x74A8_6F90_123E_41FEL, 0x51F1_AE0B_BCCA_881BL, + /* 305 */ 0x48E9_45BA_0B66_E93FL, 0x1337_0CC7_55FE_9511L, + /* 306 */ 0x5B23_9728_8E40_A38EL, 0x7804_CFF9_2B7E_3A55L, + /* 307 */ 0x71EC_7CF2_B1D0_CC72L, 0x5606_03F7_765D_C8EAL, + /* 308 */ 0x4733_CE17_AF22_7FC7L, 0x55C3_C27A_A9FA_9D93L, + /* 309 */ 0x5900_C19D_9AEB_1FB9L, 0x4B34_B319_5479_44F7L, + /* 310 */ 0x6F40_F205_01A5_E7A7L, 0x7E01_DFDF_A997_9635L, + /* 311 */ 0x4588_9743_2107_B0C8L, 0x7EC1_2BEB_C9FE_BDE1L, + /* 312 */ 0x56EA_BD13_E949_9CFBL, 0x1E71_76E6_BC7E_6D59L, + /* 313 */ 0x6CA5_6C58_E39C_043AL, 0x060D_D4A0_6B9E_08B0L, + /* 314 */ 0x43E7_63B7_8E41_82A4L, 0x23C8_A4E4_4342_C56EL, + /* 315 */ 0x54E1_3CA5_71D1_E34DL, 0x2CBA_CE1D_5413_76C9L, + /* 316 */ 0x6A19_8BCE_CE46_5C20L, 0x57E9_81A4_A918_547BL, + /* 317 */ 0x424F_F761_40EB_F994L, 0x36F1_F106_E9AF_34CDL, + /* 318 */ 0x52E3_F539_9126_F7F9L, 0x44AE_6D48_A41B_0201L, + /* 319 */ 0x679C_F287_F570_B5F7L, 0x75DA_089A_CD21_C281L, + /* 320 */ 0x40C2_1794_F966_71BAL, 0x79A8_4560_C035_1991L, + /* 321 */ 0x50F2_9D7A_37C0_0E29L, 0x5812_56B8_F042_5FF5L, + /* 322 */ 0x652F_44D8_C5B0_11B4L, 0x0E16_EC67_2C52_F7F2L, + /* 323 */ 0x7E7B_160E_F71C_1621L, 0x119C_A780_F767_B5EEL, + /* 324 */ 0x4F0C_EDC9_5A71_8DD4L, 0x5B01_E8B0_9AA0_D1B5L, + }; + +} diff --git a/test/jdk/java/lang/FPToDecimal/DoubleToDecString.java b/test/jdk/java/lang/FPToDecimal/DoubleToDecString.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/DoubleToDecString.java @@ -0,0 +1,320 @@ +/* + * Copyright 2018-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 java.util.Random; + +import static java.lang.Math.*; +import static java.lang.Double.*; + +/* + * @test + * @bug 8202555 + * @author Raffaello Giulietti + */ +public class DoubleToDecString { + + private static final boolean FAILURE_THROWS_EXCEPTION = true; + + private static void assertTrue(boolean ok, double v, String s) { + if (ok) { + return; + } + String message = "Double::toString applied to " + + "Double.longBitsToDouble(" + + "0x" + Long.toHexString(doubleToRawLongBits(v)) + "L" + + ")" + + " returns " + + "\"" + s + "\"" + + ", which is not correct according to the specification."; + if (FAILURE_THROWS_EXCEPTION) { + throw new RuntimeException(message); + } + System.err.println(message); + } + + private static void toDec(double v) { +// String s = Double.toString(v); + String s = DoubleToDecimal.toString(v); + assertTrue(new DoubleToStringChecker(v, s).isOK(), v, s); + } + + 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 + */ + toDec(4.9E-324); + toDec(9.9E-324); + } + + /* + 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 = -323; e <= 309; ++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.0) { + 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" + */ + 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 100_000. + These are all exact doubles. + */ + 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() { + Random r = new Random(); + for (int i = 0; i < 1_000_000; ++i) { + toDec(longBitsToDouble(r.nextLong())); + } + } + + /* + Random doubles over the integer range [0, 10^15). + These integers are all exact doubles. + */ + private static void testRandomUnit() { + Random r = new Random(); + for (int i = 0; i < 100_000; ++i) { + toDec(r.nextLong() % 1_000_000_000_000_000L); + } + } + + /* + Random doubles over the range [0, 10^15) as "multiples" of 1e-3 + */ + private static void testRandomMilli() { + Random r = new Random(); + for (int i = 0; i < 100_000; ++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() { + Random r = new Random(); + for (int i = 0; i < 100_000; ++i) { + toDec((r.nextLong() & 0x7FFF_FFFF_FFFF_FFFFL) / 1e6); + } + } + + public static void main(String[] args) { + testExtremeValues(); + testSomeAnomalies(); + testPowersOf2(); + testPowersOf10(); + testPaxson(); + testInts(); + testLongs(); + testRandom(); + testRandomUnit(); + testRandomMilli(); + testRandomMicro(); + } + +} diff --git a/test/jdk/java/lang/FPToDecimal/DoubleToStringChecker.java b/test/jdk/java/lang/FPToDecimal/DoubleToStringChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/DoubleToStringChecker.java @@ -0,0 +1,92 @@ +/* + * Copyright 2018-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 java.math.BigDecimal; + +/** + * @author Raffaello Giulietti + */ +class DoubleToStringChecker extends StringChecker { + + private double v; + + DoubleToStringChecker(double v, String s) { + super(s); + this.v = v; + } + + @Override + BigDecimal toBigDecimal() { + return new BigDecimal(v); + } + + @Override + boolean recovers(BigDecimal b) { + return b.doubleValue() == v; + } + + @Override + boolean recovers(String s) { + return Double.parseDouble(s) == v; + } + + @Override + int maxExp() { + return 309; + } + + @Override + int minExp() { + return -323; + } + + @Override + int maxLen10() { + return 17; + } + + @Override + boolean isZero() { + return v == 0; + } + + @Override + boolean isInfinity() { + return v == Double.POSITIVE_INFINITY; + } + + @Override + void invert() { + v = -v; + } + + @Override + boolean isNegative() { + return Double.doubleToRawLongBits(v) < 0; + } + + @Override + boolean isNaN() { + return Double.isNaN(v); + } + +} diff --git a/test/jdk/java/lang/FPToDecimal/FloatToDecString.java b/test/jdk/java/lang/FPToDecimal/FloatToDecString.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/FloatToDecString.java @@ -0,0 +1,157 @@ +/* + * Copyright 2018-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 java.util.Random; + +import static java.lang.Float.*; + +/* + * @test + * @author Raffaello Giulietti + */ +public class FloatToDecString { + + private static final boolean FAILURE_THROWS_EXCEPTION = true; + + private static void assertTrue(boolean ok, float v, String s) { + if (ok) { + return; + } + String message = "Float::toString applied to " + + "Float.intBitsToFloat(" + + "0x" + Integer.toHexString(floatToRawIntBits(v)) + + ")" + + " returns " + + "\"" + s + "\"" + + ", which is not correct according to the specification."; + if (FAILURE_THROWS_EXCEPTION) { + throw new RuntimeException(message); + } + System.err.println(message); + } + + private static void toDec(float v) { +// String s = Float.toString(v); + String s = FloatToDecimal.toString(v); + assertTrue(new FloatToStringChecker(v, s).isOK(), v, s); + } + + /* + 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 + */ + toDec(1.4E-45F); + toDec(2.8E-45F); + toDec(4.2E-45F); + toDec(5.6E-45F); + toDec(7.0E-45F); + toDec(8.4E-45F); + toDec(9.8E-45F); + } + + /* + Many "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 = -44; e <= 39; ++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.0) { + toDec(v); + } + } + + /* + Tests all integers up to 1_000_000. + These are all exact floats. + */ + private static void testInts() { + for (int i = 0; i <= 1_000_000; ++i) { + toDec(i); + } + } + + /* + Random floats over the whole range. + */ + private static void testRandom() { + Random r = new Random(); + for (int i = 0; i < 1_000_000; ++i) { + toDec(intBitsToFloat(r.nextInt())); + } + } + + /* + All, really all, possible floats. Takes between 90 and 120 minutes. + */ + private static void testAll() { + int bits = Integer.MIN_VALUE; + for (; bits < Integer.MAX_VALUE; ++bits) { + toDec(Float.intBitsToFloat(bits)); + } + toDec(Float.intBitsToFloat(bits)); + } + + public static void main(String[] args) { +// testAll(); + testExtremeValues(); + testPowersOf2(); + testPowersOf10(); + testInts(); + testRandom(); + } + +} diff --git a/test/jdk/java/lang/FPToDecimal/FloatToStringChecker.java b/test/jdk/java/lang/FPToDecimal/FloatToStringChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/FloatToStringChecker.java @@ -0,0 +1,92 @@ +/* + * Copyright 2018-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 java.math.BigDecimal; + +/** + * @author Raffaello Giulietti + */ +class FloatToStringChecker extends StringChecker { + + private float v; + + FloatToStringChecker(float v, String s) { + super(s); + this.v = v; + } + + @Override + BigDecimal toBigDecimal() { + return new BigDecimal(v); + } + + @Override + boolean recovers(BigDecimal b) { + return b.floatValue() == v; + } + + @Override + boolean recovers(String s) { + return Float.parseFloat(s) == v; + } + + @Override + int maxExp() { + return 39; + } + + @Override + int minExp() { + return -44; + } + + @Override + int maxLen10() { + return 9; + } + + @Override + boolean isZero() { + return v == 0; + } + + @Override + boolean isInfinity() { + return v == Float.POSITIVE_INFINITY; + } + + @Override + void invert() { + v = -v; + } + + @Override + boolean isNegative() { + return Float.floatToRawIntBits(v) < 0; + } + + @Override + boolean isNaN() { + return Float.isNaN(v); + } + +} diff --git a/test/jdk/java/lang/FPToDecimal/MathUtilsChecks.java b/test/jdk/java/lang/FPToDecimal/MathUtilsChecks.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/MathUtilsChecks.java @@ -0,0 +1,438 @@ +/* + * Copyright 2018-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 java.math.BigInteger; + +import static java.math.BigInteger.*; + +import static jdk.internal.math.MathUtils.*; + +/* + * @test + * @author Raffaello Giulietti + */ +public class MathUtilsChecks { + + private static final BigInteger THREE = BigInteger.valueOf(3); + + private static void check(boolean claim) { + if (!claim) { + throw new RuntimeException(); + } + } + + /* + Let + 10^e = 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^e <= g 2^r + This is the predicate that will be checked in various forms. + + Throws an exception iff the check fails. + */ + private static void checkPow10(int e, long g1, long g0) { + // 2^62 <= g1 < 2^63, 0 <= g0 < 2^63 + check(g1 << 1 < 0 && g1 >= 0 && g0 >= 0); + + BigInteger g = valueOf(g1).shiftLeft(63).or(valueOf(g0)); + // double check that 2^125 <= g < 2^126 + check(g.signum() > 0 && g.bitLength() == 126); + + // see javadoc of MathUtils.g1(int) + int r = flog2pow10(e) - 125; + + /* + The predicate + (g - 1) 2^r <= 10^e < g 2^r + is equivalent to + g - 1 <= 10^e 2^(-r) < g + When + e >= 0 & r < 0 + all numerical subexpressions are integer-valued. This is the same as + g - 1 = 10^e 2^(-r) + */ + if (e >= 0 && r < 0) { + check(g.subtract(ONE).compareTo(TEN.pow(e).shiftLeft(-r)) == 0); + return; + } + + /* + The predicate + (g - 1) 2^r <= 10^e < g 2^r + is equivalent to + g 10^(-e) - 10^(-e) <= 2^(-r) < g 10^(-e) + When + e < 0 & r < 0 + all numerical subexpressions are integer-valued. + */ + if (e < 0 && r < 0) { + BigInteger pow5 = TEN.pow(-e); + BigInteger mhs = ONE.shiftLeft(-r); + BigInteger rhs = g.multiply(pow5); + check(rhs.subtract(pow5).compareTo(mhs) <= 0 && + mhs.compareTo(rhs) < 0); + return; + } + + /* + Finally, when + e >= 0 & r >= 0 + the predicate + (g - 1) 2^r < 10^e <= g 2^r + can be used straightforwardly as all numerical subexpressions are + already integer-valued. + */ + if (e >= 0) { + BigInteger mhs = TEN.pow(e); + check(g.subtract(ONE).shiftLeft(r).compareTo(mhs) <= 0 && + mhs.compareTo(g.shiftLeft(r)) < 0); + return; + } + + /* + For combinatorial reasons, the only remaining case is + e < 0 & r >= 0 + which, however, cannot arise. Indeed, the predicate + (g - 1) 2^r <= 10^e < g 2^r + implies + (g - 1) 2^r 10^(-e) <= 1 + which cannot hold, as the left-hand side is greater than 1. + */ + check(false); + } + + /* + Verifies the soundness of the values returned by + g1() and g0(). + */ + private static void testPow10Table() { + for (int e = MIN_EXP; e <= MAX_EXP; ++e) { + checkPow10(e, g1(e), g0(e)); + } + } + + /* + Let + k = floor(log10(3/4 2^e)) + The method verifies that + k = flog10threeQuartersPow2(e), |e| <= 300_000 + This range amply covers all binary exponents of IEEE 754 binary formats up + to binary256 (octuple precision), so also suffices for 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 + */ + check(flog10threeQuartersPow2(1) == 0); + + /* + Now check the range -300_000 <= 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); + check(k0 < 0); + BigInteger l = THREE.multiply(TEN.pow(-k0 - 1)); + BigInteger u = l.multiply(TEN); + for (;;) { + check(l.bitLength() <= 2 - e && 2 - e < u.bitLength()); + if (e == -300_000) { + break; + } + --e; + int kp = flog10threeQuartersPow2(e); + check(kp <= k0); + if (kp < k0) { + // k changes at most by 1 at each iteration, hence: + check(k0 - kp == 1); + k0 = kp; + l = u; + u = u.multiply(TEN); + } + } + + /* + Finally, check the range 2 <= e <= 300_000. + 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 integer-valued. + 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); + check(k0 >= 0); + BigInteger l10 = TEN.pow(k0); + BigInteger u10 = l10.multiply(TEN); + l = l10.divide(THREE); + u = u10.divide(THREE); + for (;;) { + check(l.bitLength() <= e - 2 && e - 2 < u.bitLength()); + if (e == 300_000) { + break; + } + ++e; + int kp = flog10threeQuartersPow2(e); + check(kp >= k0); + if (kp > k0) { + // k changes at most by 1 at each iteration, hence: + check(kp - k0 == 1); + 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), |e| <= 300_000 + This range amply covers all binary exponents of IEEE 754 binary formats up + to binary256 (octuple precision), so also suffices for doubles and floats. + + The first equation above is equivalent to + 10^k <= 2^e < 10^(k+1) + Equality holds iff e = 0, implying 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 + */ + check(flog10pow2(0) == 0); + + /* + Now check the range -300_000 <= 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 integer-valued 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); + check(k < 0); + BigInteger l = TEN.pow(-k - 1); + BigInteger u = l.multiply(TEN); + for (;;) { + check(l.bitLength() <= -e && -e < u.bitLength()); + if (e == -300_000) { + break; + } + --e; + int kp = flog10pow2(e); + check(kp <= k); + if (kp < k) { + // k changes at most by 1 at each iteration, hence: + check(k - kp == 1); + k = kp; + l = u; + u = u.multiply(TEN); + } + } + + /* + Finally, in a similar vein, check the range 0 <= e <= 300_000. + 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 integer-valued. + */ + e = 1; + k = flog10pow2(e); + check(k >= 0); + l = TEN.pow(k); + u = l.multiply(TEN); + for (;;) { + check(l.bitLength() <= e && e < u.bitLength()); + if (e == 300_000) { + break; + } + ++e; + int kp = flog10pow2(e); + check(kp >= k); + if (kp > k) { + // k changes at most by 1 at each iteration, hence: + check(kp - k == 1); + k = kp; + l = u; + u = u.multiply(TEN); + } + } + } + + /* + Let + k = floor(log2(10^e)) + The method verifies that + k = flog2pow10(e), |e| <= 100_000 + This range amply covers all decimal exponents of IEEE 754 binary formats up + to binary256 (octuple precision), so also suffices for 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 + */ + check(flog2pow10(0) == 0); + + /* + Now check the range -100_000 <= 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); + check(k0 <= -4); + BigInteger l = TEN; + for (;;) { + check(l.bitLength() == -k0); + if (e == -100_000) { + break; + } + --e; + k0 = flog2pow10(e); + l = l.multiply(TEN); + } + + /* + Finally check the range 0 < e <= 100_000. + 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); + check(k0 >= 3); + l = TEN; + for (;;) { + check(l.bitLength() == k0 + 1); + if (e == 100_000) { + break; + } + ++e; + k0 = flog2pow10(e); + l = l.multiply(TEN); + } + } + + public static void main(String[] args) { + testPow10Table(); + testFlog10pow2(); + testFlog10threeQuartersPow2(); + testFlog2pow10(); + } + +} diff --git a/test/jdk/java/lang/FPToDecimal/StringChecker.java b/test/jdk/java/lang/FPToDecimal/StringChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/StringChecker.java @@ -0,0 +1,354 @@ +/* + * Copyright 2018-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 java.io.IOException; +import java.io.StringReader; +import java.math.BigDecimal; + +/** + * @author Raffaello Giulietti + */ +abstract class StringChecker { + /* + A checker for the Javadoc specification. + It just relies on straightforward use of (expensive) BigDecimal arithmetic, + not optimized at all. + */ + + private String s; + private long c; + private int q; + private int len10; + + StringChecker(String s) { + this.s = s; + } + + /* + Returns whether s syntactically meets the expected output of + Double::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() { + try { + // first determine interesting boundaries in the string + StringReader r = new StringReader(s); + 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 != s.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; + } + } + + boolean isOK() { + if (isNaN()) { + return s.equals("NaN"); + } + if (isNegative()) { + if (s.isEmpty() || s.charAt(0) != '-') { + return false; + } + invert(); + s = s.substring(1); + } + if (isInfinity()) { + return s.equals("Infinity"); + } + if (isZero()) { + return s.equals("0.0"); + } + if (!parse()) { + 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(s)) { + 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 int maxExp(); + + abstract int minExp(); + + abstract int maxLen10(); + + abstract boolean isZero(); + + abstract boolean isInfinity(); + + abstract void invert(); + + abstract boolean isNegative(); + + abstract boolean isNaN(); + +} -------------- next part -------------- # HG changeset patch # Date 1550416868 -3600 # Sun Feb 17 16:21:08 2019 +0100 # Node ID 726d159731343a7120278def10482527123411e8 # Parent d230a040662314f69fe50620a68fae6634550b49 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/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 @@ -30,6 +30,7 @@ import java.lang.constant.ConstantDesc; import java.util.Optional; +import jdk.internal.math.DoubleToDecimal; import jdk.internal.math.FloatingDecimal; import jdk.internal.math.DoubleConsts; 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 10nm {@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-1d < 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 + * d1dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

              + *
            • Case -3 ≤ e < 0: + * dv is formatted as + * 0.00d1dn, + * 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 + * d1dn00.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 + * d1dn+i.dn+i+1dn. + * 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.d2dnEe. + * 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); + return DoubleToDecimal.toString(d); } /** 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 @@ -30,6 +30,7 @@ import java.lang.constant.ConstantDesc; import java.util.Optional; +import jdk.internal.math.FloatToDecimal; import jdk.internal.math.FloatingDecimal; 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-1d < 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 + * d1dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

                + *
              • Case -3 ≤ e < 0: + * dv is formatted as + * 0.00d1dn, + * 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 + * d1dn00.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 + * d1dn+i.dn+i+1dn. + * 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.d2dnEe. + * 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); + return FloatToDecimal.toString(f); } /** 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,508 @@ +/* + * Copyright 2018-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. + */ + +package jdk.internal.math; + +import static java.lang.Double.*; +import static java.lang.Long.numberOfLeadingZeros; +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=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + + [2] IEEE Computer Society, "IEEE Standard for Floating-Point Arithmetic" + + [3] Moeller & Granlund, "Improved division by invariant integers" + + [4] Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion" + */ + + // The precision in bits. + private 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. + private static final int Q_MIN = (-1 << W - 1) - P + 3; + + // 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; + + /* + H is the minimal number of decimal digits needed to ensure that + for all finite v, round-to-half-even(toString(v)) = v + */ + private static final int H = 17; + + // Used in rop(). + private static final long MASK_63 = (1L << 63) - 1; + + // Used for digit extraction in toChars() and its dependencies. + private static final int MASK_28 = (1 << 28) - 1; + + // 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 + */ + private final byte[] buf = new byte[H + 7]; + + // Index into buf 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-1d < 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 + * d1dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

                + *
              • Case -3 ≤ e < 0: + * dv is formatted as + * 0.00d1dn, + * 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 + * d1dn00.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 + * d1dn+i.dn+i+1dn. + * 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.d2dnEe. + * 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().toDecimal(v); + } + + private static DoubleToDecimal threadLocalInstance() { + return threadLocal.get(); + } + + private String toDecimal(double v) { + /* + For details not discussed here see reference [2]. + + Let + Q_MAX = 2^(W-1) - P + C_MAX = 2^P - 1 + For finite v != 0, determine integers c and q such that + |v| = c 2^q and + Q_MIN <= q <= Q_MAX and + either C_MIN <= c <= C_MAX (normal value) + or 0 < c < C_MIN and q = Q_MIN (subnormal value) + */ + 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 + return toDecimal(Q_MIN - 1 + bq, C_MIN | t); + } + if (t != 0) { + // subnormal value + return toDecimal(Q_MIN, t); + } + return bits == 0 ? "0.0" : "-0.0"; + } + if (t != 0) { + return "NaN"; + } + return bits > 0 ? "Infinity" : "-Infinity"; + } + + private String toDecimal(int q, long c) { + // For full details see reference [1]. + int out = (int) c & 0x1; + long cb; + long cbr; + long cbl; + int k; + int h; + if (c != C_MIN | q == Q_MIN) { + // regular spacing + cb = c << 1; + cbr = cb + 1; + k = flog10pow2(q); + h = q + flog2pow10(-k) + 3; + } else { + // irregular spacing + cb = c << 2; + cbr = cb + 2; + k = flog10threeQuartersPow2(q); + h = q + flog2pow10(-k) + 2; + } + cbl = cb - 1; + + 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) { + /* + sp10 = 10 s', tp10 = 10 t' = sp10 + 10 + This is the only place where a division (the %) is carried out. + */ + long sp10 = s - s % 10; + 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); + } + } else if (s < 10) { + switch ((int) s) { + case 4: + return toChars(49, -325); // 4.9 10^(-324) + case 9: + return toChars(99, -325); // 9.9 10^(-324) + } + } + long t = s + 1; + boolean uin = vbl + out <= s << 2; + boolean win = (t << 2) + out <= vbr; + if (uin != win) { + // Exactly one of s 10^k or t 10^k lies in Rv. + return toChars(uin ? s : t, k); + } + // Both s 10^k and t 10^k lie in Rv: determine the one closest to v. + long cmp = vb - (s + t << 1); + return toChars(cmp < 0 || cmp == 0 && (s & 0x1) == 0 ? s : t, k); + } + + private static long rop(long g1, long g0, long cp) { + // For full details see reference [1]. + 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 String toChars(long f, int e) { + /* + For details not discussed here see reference [3]. + + 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 + + To avoid divisions, it can be shown ([3]) that + floor(f / 10^8) = + floor(193'428'131'138'340'668 f / 2^84) = + floor(48'357'032'784'585'167 f / 2^82) = + floor(floor(48'357'032'784'585'167 f / 2^64) / 2^18) + and similarly + floor(hm / 10^8) = floor(1'441'151'881 hm / 2^57) + */ + long hm = multiplyHigh(f, 48_357_032_784_585_167L) >>> 18; + 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 String toChars1(int h, int m, int l, int e) { + /* + 0 < e <= 7: plain format without leading zeroes. + The left-to-right digits generation is inspired by [4]. + */ + 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 charsToString(); + } + + private String 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 charsToString(); + } + + private String 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 charsToString(); + } + + private void lowDigits(int l) { + if (l != 0) { + append8Digits(l); + } + removeTrailingZeroes(); + } + + private void append8Digits(int m) { + // The left-to-right digits generation is inspired by [4] + 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 (buf[index] == '0') { + --index; + } + if (buf[index] == '.') { + ++index; + } + } + + /* + Computes floor((m + 1) 2^28 / 10^8) - 1, needed by [4], as in [3] + */ + private int y(int m) { + return (int) (multiplyHigh( + (long) (m + 1) << 28, + 48_357_032_784_585_167L) >>> 18) - 1; + } + + private void exponent(int e) { + append('E'); + if (e < 0) { + append('-'); + e = -e; + } + if (e < 10) { + appendDigit(e); + return; + } + /* + It can be shown ([3]) that + floor(e / 10) = floor(205 e / 2^11) + floor(e / 100) = floor(1'311 e / 2^17) + */ + if (e < 100) { + int d = e * 205 >>> 11; + appendDigit(d); + appendDigit(e - 10 * d); + return; + } + int d = e * 1_311 >>> 17; + appendDigit(d); + e -= 100 * d; + d = e * 205 >>> 11; + appendDigit(d); + appendDigit(e - 10 * d); + } + + private void append(int c) { + buf[++index] = (byte) c; + } + + private void appendDigit(int d) { + buf[++index] = (byte) ('0' + d); + } + + /* + Using the deprecated, yet public constructor enhances performance. + */ + private String charsToString() { + return new String(buf, 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,482 @@ +/* + * Copyright 2018-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. + */ + +package jdk.internal.math; + +import static java.lang.Float.*; +import static java.lang.Integer.numberOfLeadingZeros; +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=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + + [2] IEEE Computer Society, "IEEE Standard for Floating-Point Arithmetic" + + [3] Moeller & Granlund, "Improved division by invariant integers" + + [4] Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion" + */ + + // The precision in bits. + private 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. + private static final int Q_MIN = (-1 << W - 1) - P + 3; + + // 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; + + /* + H is the minimal number of decimal digits needed to ensure that + for all finite v, round-to-half-even(toString(v)) = v + */ + private static final int H = 9; + + // Used in rop(). + private static final long MASK_31 = (1L << 31) - 1; + + // Used for digit extraction in toChars() and its dependencies. + private static final int MASK_28 = (1 << 28) - 1; + + // 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 + */ + private final byte[] buf = new byte[H + 6]; + + // 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-1d < 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 + * d1dn + * be the usual decimal expansion of the significand. + * Note that d1 ≠ 0 ≠ dn. + *

                + *
              • Case -3 ≤ e < 0: + * dv is formatted as + * 0.00d1dn, + * 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 + * d1dn00.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 + * d1dn+i.dn+i+1dn. + * 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.d2dnEe. + * 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().toDecimal(v); + } + + private static FloatToDecimal threadLocalInstance() { + return threadLocal.get(); + } + + private String toDecimal(float v) { + /* + For details not discussed here see reference [2]. + + Let + Q_MAX = 2^(W-1) - P + C_MAX = 2^P - 1 + For finite v != 0, determine integers c and q such that + |v| = c 2^q and + Q_MIN <= q <= Q_MAX and + either C_MIN <= c <= C_MAX (normal value) + or 0 < c < C_MIN and q = Q_MIN (subnormal value) + */ + 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 + return toDecimal(Q_MIN - 1 + bq, C_MIN | t); + } + if (t != 0) { + // subnormal value + return toDecimal(Q_MIN, t); + } + return bits == 0 ? "0.0" : "-0.0"; + } + if (t != 0) { + return "NaN"; + } + return bits > 0 ? "Infinity" : "-Infinity"; + } + + private String toDecimal(int q, int c) { + // For full details see reference [1]. + int out = c & 0x1; + long cb; + long cbr; + long cbl; + int k; + int h; + if (c != C_MIN | q == Q_MIN) { + // regular spacing + cb = c << 1; + cbr = cb + 1; + k = flog10pow2(q); + h = q + flog2pow10(-k) + 34; + } else { + // irregular spacing + cb = c << 2; + cbr = cb + 2; + k = flog10threeQuartersPow2(q); + h = q + flog2pow10(-k) + 33; + } + cbl = cb - 1; + + 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) { + /* + sp10 = 10 s', tp10 = 10 t' = sp10 + 10 + This is the only place where a division (the %) is carried out. + */ + int sp10 = s - s % 10; + 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); + } + } else if (s < 10) { + switch (s) { + case 1: return toChars(14, -46); // 1.4 * 10^-45 + case 2: return toChars(28, -46); // 2.8 * 10^-45 + case 4: return toChars(42, -46); // 4.2 * 10^-45 + case 5: return toChars(56, -46); // 5.6 * 10^-45 + case 7: return toChars(70, -46); // 7.0 * 10^-45 + case 8: return toChars(84, -46); // 8.4 * 10^-45 + case 9: return toChars(98, -46); // 9.8 * 10^-45 + } + } + int t = s + 1; + boolean uin = vbl + out <= s << 2; + boolean win = (t << 2) + out <= vbr; + if (uin != win) { + // Exactly one of s 10^k or t 10^k lies in Rv. + return toChars(uin ? s : t, k); + } + // Both s 10^k and t 10^k lie in Rv: determine the one closest to v. + int cmp = vb - (s + t << 1); + return toChars(cmp < 0 || cmp == 0 && (s & 0x1) == 0 ? s : t, k); + } + + private static int rop(long g, long cp) { + // For full details see reference [1]. + long x1 = multiplyHigh(g, cp); + long vbp = x1 >> 31; + return (int) (vbp | (x1 & MASK_31) + MASK_31 >>> 31); + } + + /* + Formats the decimal f 10^e. + */ + private String toChars(int f, int e) { + /* + For details not discussed here see reference [3]. + + 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 + + To avoid divisions, it can be shown ([3]) that + 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 String toChars1(int h, int l, int e) { + /* + 0 < e <= 7: plain format without leading zeroes. + The left-to-right digits generation is inspired by [4]. + */ + 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 charsToString(); + } + + private String 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 charsToString(); + } + + private String toChars3(int h, int l, int e) { + // -3 >= e | e > 7: computerized scientific notation + appendDigit(h); + append('.'); + append8Digits(l); + removeTrailingZeroes(); + exponent(e - 1); + return charsToString(); + } + + private void append8Digits(int m) { + // The left-to-right digits generation is inspired by [4] + 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 (buf[index] == '0') { + --index; + } + if (buf[index] == '.') { + ++index; + } + } + + /* + Computes floor((m + 1) 2^28 / 10^8) - 1, needed by [4], as in [3] + */ + private int y(int m) { + return (int) (multiplyHigh( + (long) (m + 1) << 28, + 48_357_032_784_585_167L) >>> 18) - 1; + } + + private void exponent(int e) { + append('E'); + if (e < 0) { + append('-'); + e = -e; + } + if (e < 10) { + appendDigit(e); + return; + } + /* + It can be shown ([3]) that + floor(e / 10) = floor(205 e / 2^11) + */ + int d = e * 205 >>> 11; + appendDigit(d); + appendDigit(e - 10 * d); + } + + private void append(int c) { + buf[++index] = (byte) c; + } + + private void appendDigit(int d) { + buf[++index] = (byte) ('0' + d); + } + + /* + Using the deprecated, yet public constructor enhances performance. + */ + private String charsToString() { + return new String(buf, 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,794 @@ +/* + * Copyright 2018-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. + */ + +package jdk.internal.math; + +/** + * This class exposes package private utilities for other classes. + * + * All methods are assumed to be invoked with correct arguments, so they 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=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 + */ + + // 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; + + // The minimum and maximum exponents for g1(int) + static final int MIN_EXP = -292; + static final int MAX_EXP = 324; + + private MathUtils() { + } + + // pow10[e] = 10^e, 0 <= e <= 17 + 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 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 e} = β 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(e)} - 125 (see {@link #flog2pow10(int)}). + * + * @param e The exponent of 10, + * which must meet {@link #MIN_EXP} ≤ {@code e} ≤ + * {@link #MAX_EXP}. + * @return g1 as described above. + */ + static long g1(int e) { + return g[e - MIN_EXP << 1]; + } + + /** + * Returns g0 as described in + * {@link #g1(int)}. + * + * @param e The exponent of 10, + * which must meet {@link #MIN_EXP} ≤ {@code e} ≤ + * {@link #MAX_EXP}. + * @return g0 as described in + * {@link #g1(int)}. + */ + static long g0(int e) { + return g[e - MIN_EXP << 1 | 1]; + } + + /** + * The precomputed values for {@link #g1(int)} and {@link #g0(int)}. + */ + private static final long[] g = { + /* -292 */ 0x7FBB_D8FE_5F5E_6E27L, 0x497A_3A27_04EE_C3DFL, + /* -291 */ 0x4FD5_679E_FB9B_04D8L, 0x5DEC_6458_6315_3A6CL, + /* -290 */ 0x63CA_C186_BA81_C60EL, 0x7567_7D6E_7BDA_8906L, + /* -289 */ 0x7CBD_71E8_6922_3792L, 0x52C1_5CCA_1AD1_2B48L, + /* -288 */ 0x4DF6_6731_41B5_62BBL, 0x53B8_D9FE_50C2_BB0DL, + /* -287 */ 0x6174_00FD_9222_BB6AL, 0x48A7_107D_E4F3_69D0L, + /* -286 */ 0x79D1_013C_F6AB_6A45L, 0x1AD0_D49D_5E30_4444L, + /* -285 */ 0x4C22_A0C6_1A2B_226BL, 0x20C2_84E2_5ADE_2AABL, + /* -284 */ 0x5F2B_48F7_A0B5_EB06L, 0x08F3_261A_F195_B555L, + /* -283 */ 0x76F6_1B35_88E3_65C7L, 0x4B2F_EFA1_ADFB_22ABL, + /* -282 */ 0x4A59_D101_758E_1F9CL, 0x5EFD_F5C5_0CBC_F5ABL, + /* -281 */ 0x5CF0_4541_D2F1_A783L, 0x76BD_7336_4FEC_3315L, + /* -280 */ 0x742C_5692_47AE_1164L, 0x746C_D003_E3E7_3FDBL, + /* -279 */ 0x489B_B61B_6CCC_CADFL, 0x08C4_0202_6E70_87E9L, + /* -278 */ 0x5AC2_A3A2_47FF_FD96L, 0x6AF5_0283_0A0C_A9E3L, + /* -277 */ 0x7173_4C8A_D9FF_FCFCL, 0x45B2_4323_CC8F_D45CL, + /* -276 */ 0x46E8_0FD6_C83F_FE1DL, 0x6B8F_69F6_5FD9_E4B9L, + /* -275 */ 0x58A2_13CC_7A4F_FDA5L, 0x2673_4473_F7D0_5DE8L, + /* -274 */ 0x6ECA_98BF_98E3_FD0EL, 0x5010_1590_F5C4_7561L, + /* -273 */ 0x453E_9F77_BF8E_7E29L, 0x120A_0D7A_999A_C95DL, + /* -272 */ 0x568E_4755_AF72_1DB3L, 0x368C_90D9_4001_7BB4L, + /* -271 */ 0x6C31_D92B_1B4E_A520L, 0x242F_B50F_9001_DAA1L, + /* -270 */ 0x439F_27BA_F111_2734L, 0x169D_D129_BA01_28A5L, + /* -269 */ 0x5486_F1A9_AD55_7101L, 0x1C45_4574_2881_72CEL, + /* -268 */ 0x69A8_AE14_18AA_CD41L, 0x4356_96D1_32A1_CF81L, + /* -267 */ 0x4209_6CCC_8F6A_C048L, 0x7A16_1E42_BFA5_21B1L, + /* -266 */ 0x528B_C7FF_B345_705BL, 0x189B_A5D3_6F8E_6A1DL, + /* -265 */ 0x672E_B9FF_A016_CC71L, 0x7EC2_8F48_4B72_04A4L, + /* -264 */ 0x407D_343F_C40E_3FC7L, 0x1F39_998D_2F27_42E7L, + /* -263 */ 0x509C_814F_B511_CFB9L, 0x0707_FFF0_7AF1_13A1L, + /* -262 */ 0x64C3_A1A3_A256_43A7L, 0x28C9_FFEC_99AD_5889L, + /* -261 */ 0x7DF4_8A0C_8AEB_D491L, 0x12FC_7FE7_C018_AEABL, + /* -260 */ 0x4EB8_D647_D6D3_64DAL, 0x5BDD_CFF0_D80F_6D2BL, + /* -259 */ 0x6267_0BD9_CC88_3E11L, 0x32D5_43ED_0E13_4875L, + /* -258 */ 0x7B00_CED0_3FAA_4D95L, 0x5F8A_94E8_5198_1A93L, + /* -257 */ 0x4CE0_8142_27CA_707DL, 0x4BB6_9D11_32FF_109CL, + /* -256 */ 0x6018_A192_B1BD_0C9CL, 0x7EA4_4455_7FBE_D4C3L, + /* -255 */ 0x781E_C9F7_5E2C_4FC4L, 0x1E4D_556A_DFAE_89F3L, + /* -254 */ 0x4B13_3E3A_9ADB_B1DAL, 0x52F0_5562_CBCD_1638L, + /* -253 */ 0x5DD8_0DC9_4192_9E51L, 0x27AC_6ABB_7EC0_5BC6L, + /* -252 */ 0x754E_113B_91F7_45E5L, 0x5197_856A_5E70_72B8L, + /* -251 */ 0x4950_CAC5_3B3A_8BAFL, 0x42FE_B362_7B06_47B3L, + /* -250 */ 0x5BA4_FD76_8A09_2E9BL, 0x33BE_603B_19C7_D99FL, + /* -249 */ 0x728E_3CD4_2C8B_7A42L, 0x20AD_F849_E039_D007L, + /* -248 */ 0x4798_E604_9BD7_2C69L, 0x346C_BB2E_2C24_2205L, + /* -247 */ 0x597F_1F85_C2CC_F783L, 0x6187_E9F9_B72D_2A86L, + /* -246 */ 0x6FDE_E767_3380_3564L, 0x59E9_E478_24F8_7527L, + /* -245 */ 0x45EB_50A0_8030_215EL, 0x7832_2ECB_171B_4939L, + /* -244 */ 0x5766_24C8_A03C_29B6L, 0x563E_BA7D_DCE2_1B87L, + /* -243 */ 0x6D3F_ADFA_C84B_3424L, 0x2BCE_691D_541A_A268L, + /* -242 */ 0x4447_CCBC_BD2F_0096L, 0x5B61_01B2_5490_A581L, + /* -241 */ 0x5559_BFEB_EC7A_C0BCL, 0x3239_421E_E9B4_CEE1L, + /* -240 */ 0x6AB0_2FE6_E799_70EBL, 0x3EC7_92A6_A422_029AL, + /* -239 */ 0x42AE_1DF0_50BF_E693L, 0x173C_BBA8_2695_41A0L, + /* -238 */ 0x5359_A56C_64EF_E037L, 0x7D0B_EA92_303A_9208L, + /* -237 */ 0x6830_0EC7_7E2B_D845L, 0x7C4E_E536_BC49_368AL, + /* -236 */ 0x411E_093C_AEDB_672BL, 0x5DB1_4F42_35AD_C217L, + /* -235 */ 0x5165_8B8B_DA92_40F6L, 0x551D_A312_C319_329CL, + /* -234 */ 0x65BE_EE6E_D136_D134L, 0x2A65_0BD7_73DF_7F43L, + /* -233 */ 0x7F2E_AA0A_8584_8581L, 0x34FE_4ECD_50D7_5F14L, + /* -232 */ 0x4F7D_2A46_9372_D370L, 0x711E_F140_5286_9B6CL, + /* -231 */ 0x635C_74D8_384F_884DL, 0x0D66_AD90_6728_4247L, + /* -230 */ 0x7C33_920E_4663_6A60L, 0x30C0_58F4_80F2_52D9L, + /* -229 */ 0x4DA0_3B48_EBFE_227CL, 0x1E78_3798_D097_73C8L, + /* -228 */ 0x6108_4A1B_26FD_AB1BL, 0x2616_457F_04BD_50BAL, + /* -227 */ 0x794A_5CA1_F0BD_15E2L, 0x0F9B_D6DE_C5EC_A4E8L, + /* -226 */ 0x4BCE_79E5_3676_2DADL, 0x29C1_664B_3BB3_E711L, + /* -225 */ 0x5EC2_185E_8413_B918L, 0x5431_BFDE_0AA0_E0D5L, + /* -224 */ 0x7672_9E76_2518_A75EL, 0x693E_2FD5_8D49_190BL, + /* -223 */ 0x4A07_A309_D72F_689BL, 0x21C6_DDE5_784D_AFA7L, + /* -222 */ 0x5C89_8BCC_4CFB_42C2L, 0x0A38_955E_D661_1B90L, + /* -221 */ 0x73AB_EEBF_603A_1372L, 0x4CC6_BAB6_8BF9_6274L, + /* -220 */ 0x484B_7537_9C24_4C27L, 0x4FFC_34B2_177B_DD89L, + /* -219 */ 0x5A5E_5285_832D_5F31L, 0x43FB_41DE_9D5A_D4EBL, + /* -218 */ 0x70F5_E726_E3F8_B6FDL, 0x74FA_1256_44B1_8A26L, + /* -217 */ 0x4699_B078_4E7B_725EL, 0x591C_4B75_EAEE_F658L, + /* -216 */ 0x5840_1C96_621A_4EF6L, 0x2F63_5E53_65AA_B3EDL, + /* -215 */ 0x6E50_23BB_FAA0_E2B3L, 0x7B3C_35E8_3F15_60E9L, + /* -214 */ 0x44F2_1655_7CA4_8DB0L, 0x3D05_A1B1_276D_5C92L, + /* -213 */ 0x562E_9BEA_DBCD_B11CL, 0x4C47_0A1D_7148_B3B6L, + /* -212 */ 0x6BBA_42E5_92C1_1D63L, 0x5F58_CCA4_CD9A_E0A3L, + /* -211 */ 0x4354_69CF_7BB8_B25EL, 0x2B97_7FE7_0080_CC66L, + /* -210 */ 0x5429_8443_5AA6_DEF5L, 0x767D_5FE0_C0A0_FF80L, + /* -209 */ 0x6933_E554_3150_96B3L, 0x341C_B7D8_F0C9_3F5FL, + /* -208 */ 0x41C0_6F54_9ED2_5E30L, 0x1091_F2E7_967D_C79CL, + /* -207 */ 0x5230_8B29_C686_F5BCL, 0x14B6_6FA1_7C1D_3983L, + /* -206 */ 0x66BC_ADF4_3828_B32BL, 0x19E4_0B89_DB24_87E3L, + /* -205 */ 0x4035_ECB8_A319_6FFBL, 0x002E_8736_28F6_D4EEL, + /* -204 */ 0x5043_67E6_CBDF_CBF9L, 0x603A_2903_B334_8A2AL, + /* -203 */ 0x6454_41E0_7ED7_BEF8L, 0x1848_B344_A001_ACB4L, + /* -202 */ 0x7D69_5258_9E8D_AEB6L, 0x1E5A_E015_C802_17E1L, + /* -201 */ 0x4E61_D377_6318_8D31L, 0x72F8_CC0D_9D01_4EEDL, + /* -200 */ 0x61FA_4855_3BDE_B07EL, 0x2FB6_FF11_0441_A2A8L, + /* -199 */ 0x7A78_DA6A_8AD6_5C9DL, 0x7BA4_BED5_4552_0B52L, + /* -198 */ 0x4C8B_8882_96C5_F9E2L, 0x5D46_F745_4B53_4713L, + /* -197 */ 0x5FAE_6AA3_3C77_785BL, 0x3498_B516_9E28_18D8L, + /* -196 */ 0x779A_054C_0B95_5672L, 0x21BE_E25C_45B2_1F0EL, + /* -195 */ 0x4AC0_434F_873D_5607L, 0x3517_4D79_AB8F_5369L, + /* -194 */ 0x5D70_5423_690C_AB89L, 0x225D_20D8_1673_2843L, + /* -193 */ 0x74CC_692C_434F_D66BL, 0x4AF4_690E_1C0F_F253L, + /* -192 */ 0x48FF_C1BB_AA11_E603L, 0x1ED8_C1A8_D189_F774L, + /* -191 */ 0x5B3F_B22A_9496_5F84L, 0x068E_F213_05EC_7551L, + /* -190 */ 0x720F_9EB5_39BB_F765L, 0x0832_AE97_C767_92A5L, + /* -189 */ 0x4749_C331_4415_7A9FL, 0x151F_AD1E_DCA0_BBA8L, + /* -188 */ 0x591C_33FD_951A_D946L, 0x7A67_9866_93C8_EA91L, + /* -187 */ 0x6F63_40FC_FA61_8F98L, 0x5901_7E80_38BB_2536L, + /* -186 */ 0x459E_089E_1C7C_F9BFL, 0x37A0_EF10_2374_F742L, + /* -185 */ 0x5705_8AC5_A39C_382FL, 0x2589_2AD4_2C52_3512L, + /* -184 */ 0x6CC6_ED77_0C83_463BL, 0x0EEB_7589_3766_C256L, + /* -183 */ 0x43FC_546A_67D2_0BE4L, 0x7953_2975_C2A0_3976L, + /* -182 */ 0x54FB_6985_01C6_8EDEL, 0x17A7_F3D3_3348_47D4L, + /* -181 */ 0x6A3A_43E6_4238_3295L, 0x5D91_F0C8_001A_59C8L, + /* -180 */ 0x4264_6A6F_E963_1F9DL, 0x4A7B_367D_0010_781DL, + /* -179 */ 0x52FD_850B_E3BB_E784L, 0x7D1A_041C_4014_9625L, + /* -178 */ 0x67BC_E64E_DCAA_E166L, 0x1C60_8523_5019_BBAEL, + /* -177 */ 0x40D6_0FF1_49EA_CCDFL, 0x71BC_5336_1210_154DL, + /* -176 */ 0x510B_93ED_9C65_8017L, 0x6E2B_6803_9694_1AA0L, + /* -175 */ 0x654E_78E9_037E_E01DL, 0x69B6_4204_7C39_2148L, + /* -174 */ 0x7EA2_1723_445E_9825L, 0x2423_D285_9B47_6999L, + /* -173 */ 0x4F25_4E76_0ABB_1F17L, 0x2696_6393_810C_A200L, + /* -172 */ 0x62EE_A213_8D69_E6DDL, 0x103B_FC78_614F_CA80L, + /* -171 */ 0x7BAA_4A98_70C4_6094L, 0x344A_FB96_79A3_BD20L, + /* -170 */ 0x4D4A_6E9F_467A_BC5CL, 0x60AE_DD3E_0C06_5634L, + /* -169 */ 0x609D_0A47_1819_6B73L, 0x78DA_948D_8F07_EBC1L, + /* -168 */ 0x78C4_4CD8_DE1F_C650L, 0x7711_39B0_F2C9_E6B1L, + /* -167 */ 0x4B7A_B007_8AD3_DBF2L, 0x4A6A_C40E_97BE_302FL, + /* -166 */ 0x5E59_5C09_6D88_D2EFL, 0x1D05_7512_3DAD_BC3AL, + /* -165 */ 0x75EF_B30B_C8EB_07ABL, 0x0446_D256_CD19_2B49L, + /* -164 */ 0x49B5_CFE7_5D92_E4CAL, 0x72AC_4376_402F_BB0EL, + /* -163 */ 0x5C23_43E1_34F7_9DFDL, 0x4F57_5453_D03B_A9D1L, + /* -162 */ 0x732C_14D9_8235_857DL, 0x032D_2968_C44A_9445L, + /* -161 */ 0x47FB_8D07_F161_736EL, 0x11FC_39E1_7AAE_9CABL, + /* -160 */ 0x59FA_7049_EDB9_D049L, 0x567B_4859_D95A_43D6L, + /* -159 */ 0x7079_0C5C_6928_445CL, 0x0C1A_1A70_4FB0_D4CCL, + /* -158 */ 0x464B_A7B9_C1B9_2AB9L, 0x4790_5086_31CE_84FFL, + /* -157 */ 0x57DE_91A8_3227_7567L, 0x7974_64A7_BE42_263FL, + /* -156 */ 0x6DD6_3612_3EB1_52C1L, 0x77D1_7DD1_ADD2_AFCFL, + /* -155 */ 0x44A5_E1CB_672E_D3B9L, 0x1AE2_EEA3_0CA3_ADE1L, + /* -154 */ 0x55CF_5A3E_40FA_88A7L, 0x419B_AA4B_CFCC_995AL, + /* -153 */ 0x6B43_30CD_D139_2AD1L, 0x3202_94DE_C3BF_BFB0L, + /* -152 */ 0x4309_FE80_A2C3_BAC2L, 0x6F41_9D0B_3A57_D7CEL, + /* -151 */ 0x53CC_7E20_CB74_A973L, 0x4B12_044E_08ED_CDC2L, + /* -150 */ 0x68BF_9DA8_FE51_D3D0L, 0x3DD6_8561_8B29_4132L, + /* -149 */ 0x4177_C289_9EF3_2462L, 0x26A6_135C_F6F9_C8BFL, + /* -148 */ 0x51D5_B32C_06AF_ED7AL, 0x704F_9834_34B8_3AEFL, + /* -147 */ 0x664B_1FF7_085B_E8D9L, 0x4C63_7E41_41E6_49ABL, + /* -146 */ 0x7FDD_E7F4_CA72_E30FL, 0x7F7C_5DD1_925F_DC15L, + /* -145 */ 0x4FEA_B0F8_FE87_CDE9L, 0x7FAD_BAA2_FB7B_E98DL, + /* -144 */ 0x63E5_5D37_3E29_C164L, 0x3F99_294B_BA5A_E3F1L, + /* -143 */ 0x7CDE_B485_0DB4_31BDL, 0x4F7F_739E_A8F1_9CEDL, + /* -142 */ 0x4E0B_30D3_2890_9F16L, 0x41AF_A843_2997_0214L, + /* -141 */ 0x618D_FD07_F2B4_C6DCL, 0x121B_9253_F3FC_C299L, + /* -140 */ 0x79F1_7C49_EF61_F893L, 0x16A2_76E8_F0FB_F33FL, + /* -139 */ 0x4C36_EDAE_359D_3B5BL, 0x7E25_8A51_969D_7808L, + /* -138 */ 0x5F44_A919_C304_8A32L, 0x7DAE_ECE5_FC44_D609L, + /* -137 */ 0x7715_D360_33C5_ACBFL, 0x5D1A_A81F_7B56_0B8CL, + /* -136 */ 0x4A6D_A41C_205B_8BF7L, 0x6A30_A913_AD15_C738L, + /* -135 */ 0x5D09_0D23_2872_6EF5L, 0x64BC_D358_985B_3905L, + /* -134 */ 0x744B_506B_F28F_0AB3L, 0x1DEC_082E_BE72_0746L, + /* -133 */ 0x48AF_1243_7799_66B0L, 0x02B3_851D_3707_448CL, + /* -132 */ 0x5ADA_D6D4_557F_C05CL, 0x0360_6664_84C9_15AFL, + /* -131 */ 0x7191_8C89_6ADF_B073L, 0x0438_7FFD_A5FB_5B1BL, + /* -130 */ 0x46FA_F7D5_E2CB_CE47L, 0x72A3_4FFE_87BD_18F1L, + /* -129 */ 0x58B9_B5CB_5B7E_C1D9L, 0x6F4C_23FE_29AC_5F2DL, + /* -128 */ 0x6EE8_233E_325E_7250L, 0x2B1F_2CFD_B417_76F8L, + /* -127 */ 0x4551_1606_DF7B_0772L, 0x1AF3_7C1E_908E_AA5BL, + /* -126 */ 0x56A5_5B88_9759_C94EL, 0x61B0_5B26_34B2_54F2L, + /* -125 */ 0x6C4E_B26A_BD30_3BA2L, 0x3A1C_71EF_C1DE_EA2EL, + /* -124 */ 0x43B1_2F82_B63E_2545L, 0x4451_C735_D92B_525DL, + /* -123 */ 0x549D_7B63_63CD_AE96L, 0x7566_3903_4F76_26F4L, + /* -122 */ 0x69C4_DA3C_3CC1_1A3CL, 0x52BF_C744_2353_B0B1L, + /* -121 */ 0x421B_0865_A5F8_B065L, 0x73B7_DC8A_9614_4E6FL, + /* -120 */ 0x52A1_CA7F_0F76_DC7FL, 0x30A5_D3AD_3B99_620BL, + /* -119 */ 0x674A_3D1E_D354_939FL, 0x1CCF_4898_8A7F_BA8DL, + /* -118 */ 0x408E_6633_4414_DC43L, 0x4201_8D5F_568F_D498L, + /* -117 */ 0x50B1_FFC0_151A_1354L, 0x3281_F0B7_2C33_C9BEL, + /* -116 */ 0x64DE_7FB0_1A60_9829L, 0x3F22_6CE4_F740_BC2EL, + /* -115 */ 0x7E16_1F9C_20F8_BE33L, 0x6EEB_081E_3510_EB39L, + /* -114 */ 0x4ECD_D3C1_949B_76E0L, 0x3552_E512_E12A_9304L, + /* -113 */ 0x6281_48B1_F9C2_5498L, 0x42A7_9E57_9975_37C5L, + /* -112 */ 0x7B21_9ADE_7832_E9BEL, 0x5351_85ED_7FD2_85B6L, + /* -111 */ 0x4CF5_00CB_0B1F_D217L, 0x1412_F3B4_6FE3_9392L, + /* -110 */ 0x6032_40FD_CDE7_C69CL, 0x7917_B0A1_8BDC_7876L, + /* -109 */ 0x783E_D13D_4161_B844L, 0x175D_9CC9_EED3_9694L, + /* -108 */ 0x4B27_42C6_48DD_132AL, 0x4E9A_81FE_3544_3E1CL, + /* -107 */ 0x5DF1_1377_DB14_57F5L, 0x2241_227D_C295_4DA3L, + /* -106 */ 0x756D_5855_D1D9_6DF2L, 0x4AD1_6B1D_333A_A10CL, + /* -105 */ 0x4964_5735_A327_E4B7L, 0x4EC2_E2F2_4004_A4A8L, + /* -104 */ 0x5BBD_6D03_0BF1_DDE5L, 0x4273_9BAE_D005_CDD2L, + /* -103 */ 0x72AC_C843_CEEE_555EL, 0x7310_829A_8407_4146L, + /* -102 */ 0x47AB_FD2A_6154_F55BL, 0x27EA_51A0_9284_88CCL, + /* -101 */ 0x5996_FC74_F9AA_32B2L, 0x11E4_E608_B725_AAFFL, + /* -100 */ 0x6FFC_BB92_3814_BF5EL, 0x565E_1F8A_E4EF_15BEL, + /* -99 */ 0x45FD_F53B_630C_F79BL, 0x15FA_D3B6_CF15_6D97L, + /* -98 */ 0x577D_728A_3BD0_3581L, 0x7B79_88A4_82DA_C8FDL, + /* -97 */ 0x6D5C_CF2C_CAC4_42E2L, 0x3A57_EACD_A391_7B3CL, + /* -96 */ 0x445A_017B_FEBA_A9CDL, 0x4476_F2C0_863A_ED06L, + /* -95 */ 0x5570_81DA_FE69_5440L, 0x7594_AF70_A7C9_A847L, + /* -94 */ 0x6ACC_A251_BE03_A951L, 0x12F9_DB4C_D1BC_1258L, + /* -93 */ 0x42BF_E573_16C2_49D2L, 0x5BDC_2910_0315_8B77L, + /* -92 */ 0x536F_DECF_DC72_DC47L, 0x32D3_3354_03DA_EE55L, + /* -91 */ 0x684B_D683_D38F_9359L, 0x1F88_0029_04D1_A9EAL, + /* -90 */ 0x412F_6612_6439_BC17L, 0x63B5_0019_A303_0A33L, + /* -89 */ 0x517B_3F96_FD48_2B1DL, 0x5CA2_4020_0BC3_CCBFL, + /* -88 */ 0x65DA_0F7C_BC9A_35E5L, 0x13CA_D028_0EB4_BFEFL, + /* -87 */ 0x7F50_935B_EBC0_C35EL, 0x38BD_8432_1261_EFEBL, + /* -86 */ 0x4F92_5C19_7358_7A1BL, 0x0376_729F_4B7D_35F3L, + /* -85 */ 0x6376_F31F_D02E_98A1L, 0x6454_0F47_1E5C_836FL, + /* -84 */ 0x7C54_AFE7_C43A_3ECAL, 0x1D69_1318_E5F3_A44BL, + /* -83 */ 0x4DB4_EDF0_DAA4_673EL, 0x3261_ABEF_8FB8_46AFL, + /* -82 */ 0x6122_296D_114D_810DL, 0x7EFA_16EB_73A6_585BL, + /* -81 */ 0x796A_B3C8_55A0_E151L, 0x3EB8_9CA6_508F_EE71L, + /* -80 */ 0x4BE2_B05D_3584_8CD2L, 0x7733_61E7_F259_F507L, + /* -79 */ 0x5EDB_5C74_82E5_B007L, 0x5500_3A61_EEF0_7249L, + /* -78 */ 0x7692_3391_A39F_1C09L, 0x4A40_48FA_6AAC_8EDBL, + /* -77 */ 0x4A1B_603B_0643_7185L, 0x7E68_2D9C_82AB_D949L, + /* -76 */ 0x5CA2_3849_C7D4_4DE7L, 0x3E02_3903_A356_CF9BL, + /* -75 */ 0x73CA_C65C_39C9_6161L, 0x2D82_C744_8C2C_8382L, + /* -74 */ 0x485E_BBF9_A41D_DCDCL, 0x6C71_BC8A_D79B_D231L, + /* -73 */ 0x5A76_6AF8_0D25_5414L, 0x078E_2BAD_8D82_C6BDL, + /* -72 */ 0x7114_05B6_106E_A919L, 0x0971_B698_F0E3_786DL, + /* -71 */ 0x46AC_8391_CA45_29AFL, 0x55E7_121F_968E_2B44L, + /* -70 */ 0x5857_A476_3CD6_741BL, 0x4B60_D6A7_7C31_B615L, + /* -69 */ 0x6E6D_8D93_CC0C_1122L, 0x3E39_0C51_5B3E_239AL, + /* -68 */ 0x4504_787C_5F87_8AB5L, 0x46E3_A7B2_D906_D640L, + /* -67 */ 0x5645_969B_7769_6D62L, 0x789C_919F_8F48_8BD0L, + /* -66 */ 0x6BD6_FC42_5543_C8BBL, 0x56C3_B607_731A_AEC4L, + /* -65 */ 0x4366_5DA9_754A_5D75L, 0x263A_51C4_A7F0_AD3BL, + /* -64 */ 0x543F_F513_D29C_F4D2L, 0x4FC8_E635_D1EC_D88AL, + /* -63 */ 0x694F_F258_C744_3207L, 0x23BB_1FC3_4668_0EACL, + /* -62 */ 0x41D1_F777_7C8A_9F44L, 0x4654_F3DA_0C01_092CL, + /* -61 */ 0x5246_7555_5BAD_4715L, 0x57EA_30D0_8F01_4B76L, + /* -60 */ 0x66D8_12AA_B298_98DBL, 0x0DE4_BD04_B2C1_9E54L, + /* -59 */ 0x4047_0BAA_AF9F_5F88L, 0x78AE_F622_EFB9_02F5L, + /* -58 */ 0x5058_CE95_5B87_376BL, 0x16DA_B3AB_ABA7_43B2L, + /* -57 */ 0x646F_023A_B269_0545L, 0x7C91_6096_9691_149EL, + /* -56 */ 0x7D8A_C2C9_5F03_4697L, 0x3BB5_B8BC_3C35_59C5L, + /* -55 */ 0x4E76_B9BD_DB62_0C1EL, 0x5551_9375_A5A1_581BL, + /* -54 */ 0x6214_682D_523A_8F26L, 0x2AA5_F853_0F09_AE22L, + /* -53 */ 0x7A99_8238_A6C9_32EFL, 0x754F_7667_D2CC_19ABL, + /* -52 */ 0x4C9F_F163_683D_BFD5L, 0x7951_AA00_E3BF_900BL, + /* -51 */ 0x5FC7_EDBC_424D_2FCBL, 0x37A6_1481_1CAF_740DL, + /* -50 */ 0x77B9_E92B_52E0_7BBEL, 0x258F_99A1_63DB_5111L, + /* -49 */ 0x4AD4_31BB_13CC_4D56L, 0x7779_C004_DE69_12ABL, + /* -48 */ 0x5D89_3E29_D8BF_60ACL, 0x5558_3006_1603_5755L, + /* -47 */ 0x74EB_8DB4_4EEF_38D7L, 0x6AAE_3C07_9B84_2D2AL, + /* -46 */ 0x4913_3890_B155_8386L, 0x72AC_E584_C132_9C3BL, + /* -45 */ 0x5B58_06B4_DDAA_E468L, 0x4F58_1EE5_F17F_4349L, + /* -44 */ 0x722E_0862_1515_9D82L, 0x632E_269F_6DDF_141BL, + /* -43 */ 0x475C_C53D_4D2D_8271L, 0x5DFC_D823_A4AB_6C91L, + /* -42 */ 0x5933_F68C_A078_E30EL, 0x157C_0E2C_8DD6_47B5L, + /* -41 */ 0x6F80_F42F_C897_1BD1L, 0x5ADB_11B7_B14B_D9A3L, + /* -40 */ 0x45B0_989D_DD5E_7163L, 0x08C8_EB12_CECF_6806L, + /* -39 */ 0x571C_BEC5_54B6_0DBBL, 0x6AFB_25D7_8283_4207L, + /* -38 */ 0x6CE3_EE76_A9E3_912AL, 0x65B9_EF4D_6324_1289L, + /* -37 */ 0x440E_750A_2A2E_3ABAL, 0x5F94_3590_5DF6_8B96L, + /* -36 */ 0x5512_124C_B4B9_C969L, 0x3779_42F4_7574_2E7BL, + /* -35 */ 0x6A56_96DF_E1E8_3BC3L, 0x6557_93B1_92D1_3A1AL, + /* -34 */ 0x4276_1E4B_ED31_255AL, 0x2F56_BC4E_FBC2_C450L, + /* -33 */ 0x5313_A5DE_E87D_6EB0L, 0x7B2C_6B62_BAB3_7564L, + /* -32 */ 0x67D8_8F56_A29C_CA5DL, 0x19F7_863B_6960_52BDL, + /* -31 */ 0x40E7_5996_25A1_FE7AL, 0x203A_B3E5_21DC_33B6L, + /* -30 */ 0x5121_2FFB_AF0A_7E18L, 0x6849_60DE_6A53_40A4L, + /* -29 */ 0x6569_7BFA_9ACD_1D9FL, 0x025B_B916_04E8_10CDL, + /* -28 */ 0x7EC3_DAF9_4180_6506L, 0x62F2_A75B_8622_1500L, + /* -27 */ 0x4F3A_68DB_C8F0_3F24L, 0x1DD7_A899_33D5_4D20L, + /* -26 */ 0x6309_0312_BB2C_4EEDL, 0x254D_92BF_80CA_A068L, + /* -25 */ 0x7BCB_43D7_69F7_62A8L, 0x4EA0_F76F_60FD_4882L, + /* -24 */ 0x4D5F_0A66_A23A_9DA9L, 0x3124_9AA5_9C9E_4D51L, + /* -23 */ 0x60B6_CD00_4AC9_4513L, 0x5D6D_C14F_03C5_E0A5L, + /* -22 */ 0x78E4_8040_5D7B_9658L, 0x54C9_31A2_C4B7_58CFL, + /* -21 */ 0x4B8E_D028_3A6D_3DF7L, 0x34FD_BF05_BAF2_9781L, + /* -20 */ 0x5E72_8432_4908_8D75L, 0x223D_2EC7_29AF_3D62L, + /* -19 */ 0x760F_253E_DB4A_B0D2L, 0x4ACC_7A78_F41B_0CBAL, + /* -18 */ 0x49C9_7747_490E_AE83L, 0x4EBF_CC8B_9890_E7F4L, + /* -17 */ 0x5C3B_D519_1B52_5A24L, 0x426F_BFAE_7EB5_21F1L, + /* -16 */ 0x734A_CA5F_6226_F0ADL, 0x530B_AF9A_1E62_6A6DL, + /* -15 */ 0x480E_BE7B_9D58_566CL, 0x43E7_4DC0_52FD_8285L, + /* -14 */ 0x5A12_6E1A_84AE_6C07L, 0x54E1_2130_67BC_E326L, + /* -13 */ 0x7097_09A1_25DA_0709L, 0x4A19_697C_81AC_1BEFL, + /* -12 */ 0x465E_6604_B7A8_4465L, 0x7E4F_E1ED_D10B_9175L, + /* -11 */ 0x57F5_FF85_E592_557FL, 0x3DE3_DA69_454E_75D3L, + /* -10 */ 0x6DF3_7F67_5EF6_EADFL, 0x2D5C_D103_96A2_1347L, + /* -9 */ 0x44B8_2FA0_9B5A_52CBL, 0x4C5A_02A2_3E25_4C0DL, + /* -8 */ 0x55E6_3B88_C230_E77EL, 0x3F70_834A_CDAE_9F10L, + /* -7 */ 0x6B5F_CA6A_F2BD_215EL, 0x0F4C_A41D_811A_46D4L, + /* -6 */ 0x431B_DE82_D7B6_34DAL, 0x698F_E692_70B0_6C44L, + /* -5 */ 0x53E2_D623_8DA3_C211L, 0x43F3_E037_0CDC_8755L, + /* -4 */ 0x68DB_8BAC_710C_B295L, 0x74F0_D844_D013_A92BL, + /* -3 */ 0x4189_374B_C6A7_EF9DL, 0x5916_872B_020C_49BBL, + /* -2 */ 0x51EB_851E_B851_EB85L, 0x0F5C_28F5_C28F_5C29L, + /* -1 */ 0x6666_6666_6666_6666L, 0x3333_3333_3333_3334L, + /* 0 */ 0x4000_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 1 */ 0x5000_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 2 */ 0x6400_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 3 */ 0x7D00_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 4 */ 0x4E20_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 5 */ 0x61A8_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 6 */ 0x7A12_0000_0000_0000L, 0x0000_0000_0000_0001L, + /* 7 */ 0x4C4B_4000_0000_0000L, 0x0000_0000_0000_0001L, + /* 8 */ 0x5F5E_1000_0000_0000L, 0x0000_0000_0000_0001L, + /* 9 */ 0x7735_9400_0000_0000L, 0x0000_0000_0000_0001L, + /* 10 */ 0x4A81_7C80_0000_0000L, 0x0000_0000_0000_0001L, + /* 11 */ 0x5D21_DBA0_0000_0000L, 0x0000_0000_0000_0001L, + /* 12 */ 0x746A_5288_0000_0000L, 0x0000_0000_0000_0001L, + /* 13 */ 0x48C2_7395_0000_0000L, 0x0000_0000_0000_0001L, + /* 14 */ 0x5AF3_107A_4000_0000L, 0x0000_0000_0000_0001L, + /* 15 */ 0x71AF_D498_D000_0000L, 0x0000_0000_0000_0001L, + /* 16 */ 0x470D_E4DF_8200_0000L, 0x0000_0000_0000_0001L, + /* 17 */ 0x58D1_5E17_6280_0000L, 0x0000_0000_0000_0001L, + /* 18 */ 0x6F05_B59D_3B20_0000L, 0x0000_0000_0000_0001L, + /* 19 */ 0x4563_9182_44F4_0000L, 0x0000_0000_0000_0001L, + /* 20 */ 0x56BC_75E2_D631_0000L, 0x0000_0000_0000_0001L, + /* 21 */ 0x6C6B_935B_8BBD_4000L, 0x0000_0000_0000_0001L, + /* 22 */ 0x43C3_3C19_3756_4800L, 0x0000_0000_0000_0001L, + /* 23 */ 0x54B4_0B1F_852B_DA00L, 0x0000_0000_0000_0001L, + /* 24 */ 0x69E1_0DE7_6676_D080L, 0x0000_0000_0000_0001L, + /* 25 */ 0x422C_A8B0_A00A_4250L, 0x0000_0000_0000_0001L, + /* 26 */ 0x52B7_D2DC_C80C_D2E4L, 0x0000_0000_0000_0001L, + /* 27 */ 0x6765_C793_FA10_079DL, 0x0000_0000_0000_0001L, + /* 28 */ 0x409F_9CBC_7C4A_04C2L, 0x1000_0000_0000_0001L, + /* 29 */ 0x50C7_83EB_9B5C_85F2L, 0x5400_0000_0000_0001L, + /* 30 */ 0x64F9_64E6_8233_A76FL, 0x2900_0000_0000_0001L, + /* 31 */ 0x7E37_BE20_22C0_914BL, 0x1340_0000_0000_0001L, + /* 32 */ 0x4EE2_D6D4_15B8_5ACEL, 0x7C08_0000_0000_0001L, + /* 33 */ 0x629B_8C89_1B26_7182L, 0x5B0A_0000_0000_0001L, + /* 34 */ 0x7B42_6FAB_61F0_0DE3L, 0x31CC_8000_0000_0001L, + /* 35 */ 0x4D09_85CB_1D36_08AEL, 0x0F1F_D000_0000_0001L, + /* 36 */ 0x604B_E73D_E483_8AD9L, 0x52E7_C400_0000_0001L, + /* 37 */ 0x785E_E10D_5DA4_6D90L, 0x07A1_B500_0000_0001L, + /* 38 */ 0x4B3B_4CA8_5A86_C47AL, 0x04C5_1120_0000_0001L, + /* 39 */ 0x5E0A_1FD2_7128_7598L, 0x45F6_5568_0000_0001L, + /* 40 */ 0x758C_A7C7_0D72_92FEL, 0x5773_EAC2_0000_0001L, + /* 41 */ 0x4977_E8DC_6867_9BDFL, 0x16A8_72B9_4000_0001L, + /* 42 */ 0x5BD5_E313_8281_82D6L, 0x7C52_8F67_9000_0001L, + /* 43 */ 0x72CB_5BD8_6321_E38CL, 0x5B67_3341_7400_0001L, + /* 44 */ 0x47BF_1967_3DF5_2E37L, 0x7920_8008_E880_0001L, + /* 45 */ 0x59AE_DFC1_0D72_79C5L, 0x7768_A00B_22A0_0001L, + /* 46 */ 0x701A_97B1_50CF_1837L, 0x3542_C80D_EB48_0001L, + /* 47 */ 0x4610_9ECE_D281_6F22L, 0x5149_BD08_B30D_0001L, + /* 48 */ 0x5794_C682_8721_CAEBL, 0x259C_2C4A_DFD0_4001L, + /* 49 */ 0x6D79_F823_28EA_3DA6L, 0x0F03_375D_97C4_5001L, + /* 50 */ 0x446C_3B15_F992_6687L, 0x6962_029A_7EDA_B201L, + /* 51 */ 0x5587_49DB_77F7_0029L, 0x63BA_8341_1E91_5E81L, + /* 52 */ 0x6AE9_1C52_55F4_C034L, 0x1CA9_2411_6635_B621L, + /* 53 */ 0x42D1_B1B3_75B8_F820L, 0x51E9_B68A_DFE1_91D5L, + /* 54 */ 0x5386_1E20_5327_3628L, 0x6664_242D_97D9_F64AL, + /* 55 */ 0x6867_A5A8_67F1_03B2L, 0x7FFD_2D38_FDD0_73DCL, + /* 56 */ 0x4140_C789_40F6_A24FL, 0x6FFE_3C43_9EA2_486AL, + /* 57 */ 0x5190_F96B_9134_4AE3L, 0x6BFD_CB54_864A_DA84L, + /* 58 */ 0x65F5_37C6_7581_5D9CL, 0x66FD_3E29_A7DD_9125L, + /* 59 */ 0x7F72_85B8_12E1_B504L, 0x00BC_8DB4_11D4_F56EL, + /* 60 */ 0x4FA7_9393_0BCD_1122L, 0x4075_D890_8B25_1965L, + /* 61 */ 0x6391_7877_CEC0_556BL, 0x1093_4EB4_ADEE_5FBEL, + /* 62 */ 0x7C75_D695_C270_6AC5L, 0x74B8_2261_D969_F7ADL, + /* 63 */ 0x4DC9_A61D_9986_42BBL, 0x58F3_157D_27E2_3ACCL, + /* 64 */ 0x613C_0FA4_FFE7_D36AL, 0x4F2F_DADC_71DA_C97FL, + /* 65 */ 0x798B_138E_3FE1_C845L, 0x22FB_D193_8E51_7BDFL, + /* 66 */ 0x4BF6_EC38_E7ED_1D2BL, 0x25DD_62FC_38F2_ED6CL, + /* 67 */ 0x5EF4_A747_21E8_6476L, 0x0F54_BBBB_472F_A8C6L, + /* 68 */ 0x76B1_D118_EA62_7D93L, 0x5329_EAAA_18FB_92F8L, + /* 69 */ 0x4A2F_22AF_927D_8E7CL, 0x23FA_32AA_4F9D_3BDBL, + /* 70 */ 0x5CBA_EB5B_771C_F21BL, 0x2CF8_BF54_E384_8AD2L, + /* 71 */ 0x73E9_A632_54E4_2EA2L, 0x1836_EF2A_1C65_AD86L, + /* 72 */ 0x4872_07DF_750E_9D25L, 0x2F22_557A_51BF_8C74L, + /* 73 */ 0x5A8E_89D7_5252_446EL, 0x5AEA_EAD8_E62F_6F91L, + /* 74 */ 0x7132_2C4D_26E6_D58AL, 0x31A5_A58F_1FBB_4B75L, + /* 75 */ 0x46BF_5BB0_3850_4576L, 0x3F07_8779_73D5_0F29L, + /* 76 */ 0x586F_329C_4664_56D4L, 0x0EC9_6957_D0CA_52F3L, + /* 77 */ 0x6E8A_FF43_57FD_6C89L, 0x127B_C3AD_C4FC_E7B0L, + /* 78 */ 0x4516_DF8A_16FE_63D5L, 0x5B8D_5A4C_9B1E_10CEL, + /* 79 */ 0x565C_976C_9CBD_FCCBL, 0x1270_B0DF_C1E5_9502L, + /* 80 */ 0x6BF3_BD47_C3ED_7BFDL, 0x770C_DD17_B25E_FA42L, + /* 81 */ 0x4378_564C_DA74_6D7EL, 0x5A68_0A2E_CF7B_5C69L, + /* 82 */ 0x5456_6BE0_1111_88DEL, 0x3102_0CBA_835A_3384L, + /* 83 */ 0x696C_06D8_1555_EB15L, 0x7D42_8FE9_2430_C065L, + /* 84 */ 0x41E3_8447_0D55_B2EDL, 0x5E49_99F1_B69E_783FL, + /* 85 */ 0x525C_6558_D0AB_1FA9L, 0x15DC_006E_2446_164FL, + /* 86 */ 0x66F3_7EAF_04D5_E793L, 0x3B53_0089_AD57_9BE2L, + /* 87 */ 0x4058_2F2D_6305_B0BCL, 0x1513_E056_0C56_C16EL, + /* 88 */ 0x506E_3AF8_BBC7_1CEBL, 0x1A58_D86B_8F6C_71C9L, + /* 89 */ 0x6489_C9B6_EAB8_E426L, 0x00EF_0E86_7347_8E3BL, + /* 90 */ 0x7DAC_3C24_A567_1D2FL, 0x412A_D228_1019_71C9L, + /* 91 */ 0x4E8B_A596_E760_723DL, 0x58BA_C359_0A0F_E71EL, + /* 92 */ 0x622E_8EFC_A138_8ECDL, 0x0EE9_742F_4C93_E0E6L, + /* 93 */ 0x7ABA_32BB_C986_B280L, 0x32A3_D13B_1FB8_D91FL, + /* 94 */ 0x4CB4_5FB5_5DF4_2F90L, 0x1FA6_62C4_F3D3_87B3L, + /* 95 */ 0x5FE1_77A2_B571_3B74L, 0x278F_FB76_30C8_69A0L, + /* 96 */ 0x77D9_D58B_62CD_8A51L, 0x3173_FA53_BCFA_8408L, + /* 97 */ 0x4AE8_2577_1DC0_7672L, 0x6EE8_7C74_561C_9285L, + /* 98 */ 0x5DA2_2ED4_E530_940FL, 0x4AA2_9B91_6BA3_B726L, + /* 99 */ 0x750A_BA8A_1E7C_B913L, 0x3D4B_4275_C68C_A4F0L, + /* 100 */ 0x4926_B496_530D_F3ACL, 0x164F_0989_9C17_E716L, + /* 101 */ 0x5B70_61BB_E7D1_7097L, 0x1BE2_CBEC_031D_E0DCL, + /* 102 */ 0x724C_7A2A_E1C5_CCBDL, 0x02DB_7EE7_03E5_5912L, + /* 103 */ 0x476F_CC5A_CD1B_9FF6L, 0x11C9_2F50_626F_57ACL, + /* 104 */ 0x594B_BF71_8062_87F3L, 0x563B_7B24_7B0B_2D96L, + /* 105 */ 0x6F9E_AF4D_E07B_29F0L, 0x4BCA_59ED_99CD_F8FCL, + /* 106 */ 0x45C3_2D90_AC4C_FA36L, 0x2F5E_7834_8020_BB9EL, + /* 107 */ 0x5733_F8F4_D760_38C3L, 0x7B36_1641_A028_EA85L, + /* 108 */ 0x6D00_F732_0D38_46F4L, 0x7A03_9BD2_0833_2526L, + /* 109 */ 0x4420_9A7F_4843_2C59L, 0x0C42_4163_451F_F738L, + /* 110 */ 0x5528_C11F_1A53_F76FL, 0x2F52_D1BC_1667_F506L, + /* 111 */ 0x6A72_F166_E0E8_F54BL, 0x1B27_862B_1C01_F247L, + /* 112 */ 0x4287_D6E0_4C91_994FL, 0x00F8_B3DA_F181_376DL, + /* 113 */ 0x5329_CC98_5FB5_FFA2L, 0x6136_E0D1_ADE1_8548L, + /* 114 */ 0x67F4_3FBE_77A3_7F8BL, 0x3984_9906_1959_E699L, + /* 115 */ 0x40F8_A7D7_0AC6_2FB7L, 0x13F2_DFA3_CFD8_3020L, + /* 116 */ 0x5136_D1CC_CD77_BBA4L, 0x78EF_978C_C3CE_3C28L, + /* 117 */ 0x6584_8640_00D5_AA8EL, 0x172B_7D6F_F4C1_CB32L, + /* 118 */ 0x7EE5_A7D0_010B_1531L, 0x5CF6_5CCB_F1F2_3DFEL, + /* 119 */ 0x4F4F_88E2_00A6_ED3FL, 0x0A19_F9FF_7737_66BFL, + /* 120 */ 0x6323_6B1A_80D0_A88EL, 0x6CA0_787F_5505_406FL, + /* 121 */ 0x7BEC_45E1_2104_D2B2L, 0x47C8_969F_2A46_908AL, + /* 122 */ 0x4D73_ABAC_B4A3_03AFL, 0x4CDD_5E23_7A6C_1A57L, + /* 123 */ 0x60D0_9697_E1CB_C49BL, 0x4014_B5AC_5907_20ECL, + /* 124 */ 0x7904_BC3D_DA3E_B5C2L, 0x3019_E317_6F48_E927L, + /* 125 */ 0x4BA2_F5A6_A867_3199L, 0x3E10_2DEE_A58D_91B9L, + /* 126 */ 0x5E8B_B310_5280_FDFFL, 0x6D94_396A_4EF0_F627L, + /* 127 */ 0x762E_9FD4_6721_3D7FL, 0x68F9_47C4_E2AD_33B0L, + /* 128 */ 0x49DD_23E4_C074_C66FL, 0x719B_CCDB_0DAC_404EL, + /* 129 */ 0x5C54_6CDD_F091_F80BL, 0x6E02_C011_D117_5062L, + /* 130 */ 0x7369_8815_6CB6_760EL, 0x6983_7016_455D_247AL, + /* 131 */ 0x4821_F50D_63F2_09C9L, 0x21F2_260D_EB5A_36CCL, + /* 132 */ 0x5A2A_7250_BCEE_8C3BL, 0x4A6E_AF91_6630_C47FL, + /* 133 */ 0x70B5_0EE4_EC2A_2F4AL, 0x3D0A_5B75_BFBC_F59FL, + /* 134 */ 0x4671_294F_139A_5D8EL, 0x4626_7929_97D6_1984L, + /* 135 */ 0x580D_73A2_D880_F4F2L, 0x17B0_1773_FDCB_9FE4L, + /* 136 */ 0x6E10_D08B_8EA1_322EL, 0x5D9C_1D50_FD3E_87DDL, + /* 137 */ 0x44CA_8257_3924_BF5DL, 0x1A81_9252_9E47_14EBL, + /* 138 */ 0x55FD_22ED_076D_EF34L, 0x4121_F6E7_45D8_DA25L, + /* 139 */ 0x6B7C_6BA8_4949_6B01L, 0x516A_74A1_174F_10AEL, + /* 140 */ 0x432D_C349_2DCD_E2E1L, 0x02E2_88E4_AE91_6A6DL, + /* 141 */ 0x53F9_341B_7941_5B99L, 0x239B_2B1D_DA35_C508L, + /* 142 */ 0x68F7_8122_5791_B27FL, 0x4C81_F5E5_50C3_364AL, + /* 143 */ 0x419A_B0B5_76BB_0F8FL, 0x5FD1_39AF_527A_01EFL, + /* 144 */ 0x5201_5CE2_D469_D373L, 0x57C5_881B_2718_826AL, + /* 145 */ 0x6681_B41B_8984_4850L, 0x4DB6_EA21_F0DE_A304L, + /* 146 */ 0x4011_1091_35F2_AD32L, 0x3092_5255_368B_25E3L, + /* 147 */ 0x5015_54B5_836F_587EL, 0x7CB6_E6EA_842D_EF5CL, + /* 148 */ 0x641A_A9E2_E44B_2E9EL, 0x5BE4_A0A5_2539_6B32L, + /* 149 */ 0x7D21_545B_9D5D_FA46L, 0x32DD_C8CE_6E87_C5FFL, + /* 150 */ 0x4E34_D4B9_425A_BC6BL, 0x7FCA_9D81_0514_DBBFL, + /* 151 */ 0x61C2_09E7_92F1_6B86L, 0x7FBD_44E1_465A_12AFL, + /* 152 */ 0x7A32_8C61_77AD_C668L, 0x5FAC_9619_97F0_975BL, + /* 153 */ 0x4C5F_97BC_EACC_9C01L, 0x3BCB_DDCF_FEF6_5E99L, + /* 154 */ 0x5F77_7DAC_257F_C301L, 0x6ABE_D543_FEB3_F63FL, + /* 155 */ 0x7755_5D17_2EDF_B3C2L, 0x256E_8A94_FE60_F3CFL, + /* 156 */ 0x4A95_5A2E_7D4B_D059L, 0x3765_169D_1EFC_9861L, + /* 157 */ 0x5D3A_B0BA_1C9E_C46FL, 0x653E_5C44_66BB_BE7AL, + /* 158 */ 0x7489_5CE8_A3C6_758BL, 0x5E8D_F355_806A_AE18L, + /* 159 */ 0x48D5_DA11_665C_0977L, 0x2B18_B815_7042_ACCFL, + /* 160 */ 0x5B0B_5095_BFF3_0BD5L, 0x15DE_E61A_CC53_5803L, + /* 161 */ 0x71CE_24BB_2FEF_CECAL, 0x3B56_9FA1_7F68_2E03L, + /* 162 */ 0x4720_D6F4_FDF5_E13EL, 0x4516_23C4_EFA1_1CC2L, + /* 163 */ 0x58E9_0CB2_3D73_598EL, 0x165B_ACB6_2B89_63F3L, + /* 164 */ 0x6F23_4FDE_CCD0_2FF1L, 0x5BF2_97E3_B66B_BCEFL, + /* 165 */ 0x4576_11EB_4002_1DF7L, 0x0977_9EEE_5203_5616L, + /* 166 */ 0x56D3_9666_1002_A574L, 0x6BD5_86A9_E684_2B9BL, + /* 167 */ 0x6C88_7BFF_9403_4ED2L, 0x06CA_E854_6025_3682L, + /* 168 */ 0x43D5_4D7F_BC82_1143L, 0x243E_D134_BC17_4211L, + /* 169 */ 0x54CA_A0DF_ABA2_9594L, 0x0D4E_8581_EB1D_1295L, + /* 170 */ 0x69FD_4917_968B_3AF9L, 0x10A2_26E2_65E4_573BL, + /* 171 */ 0x423E_4DAE_BE17_04DBL, 0x5A65_584D_7FAE_B685L, + /* 172 */ 0x52CD_E11A_6D9C_C612L, 0x50FE_AE60_DF9A_6426L, + /* 173 */ 0x6781_5961_0903_F797L, 0x253E_59F9_1780_FD2FL, + /* 174 */ 0x40B0_D7DC_A5A2_7ABEL, 0x4746_F83B_AEB0_9E3EL, + /* 175 */ 0x50DD_0DD3_CF0B_196EL, 0x1918_B64A_9A5C_C5CDL, + /* 176 */ 0x6514_5148_C2CD_DFC9L, 0x5F5E_E3DD_40F3_F740L, + /* 177 */ 0x7E59_659A_F381_57BCL, 0x1736_9CD4_9130_F510L, + /* 178 */ 0x4EF7_DF80_D830_D6D5L, 0x4E82_2204_DABE_992AL, + /* 179 */ 0x62B5_D761_0E3D_0C8BL, 0x0222_AA86_116E_3F75L, + /* 180 */ 0x7B63_4D39_51CC_4FADL, 0x62AB_5527_95C9_CF52L, + /* 181 */ 0x4D1E_1043_D31F_B1CCL, 0x4DAB_1538_BD9E_2193L, + /* 182 */ 0x6065_9454_C7E7_9E3FL, 0x6115_DA86_ED05_A9F8L, + /* 183 */ 0x787E_F969_F9E1_85CFL, 0x595B_5128_A847_1476L, + /* 184 */ 0x4B4F_5BE2_3C2C_F3A1L, 0x67D9_12B9_692C_6CCAL, + /* 185 */ 0x5E23_32DA_CB38_308AL, 0x21CF_5767_C377_87FCL, + /* 186 */ 0x75AB_FF91_7E06_3CACL, 0x6A43_2D41_B455_69FBL, + /* 187 */ 0x498B_7FBA_EEC3_E5ECL, 0x0269_FC49_10B5_623DL, + /* 188 */ 0x5BEE_5FA9_AA74_DF67L, 0x0304_7B5B_54E2_BACCL, + /* 189 */ 0x72E9_F794_1512_1740L, 0x63C5_9A32_2A1B_697FL, + /* 190 */ 0x47D2_3ABC_8D2B_4E88L, 0x3E5B_805F_5A51_21F0L, + /* 191 */ 0x59C6_C96B_B076_222AL, 0x4DF2_6077_30E5_6A6CL, + /* 192 */ 0x7038_7BC6_9C93_AAB5L, 0x216E_F894_FD1E_C506L, + /* 193 */ 0x4623_4D5C_21DC_4AB1L, 0x24E5_5B5D_1E33_3B24L, + /* 194 */ 0x57AC_20B3_2A53_5D5DL, 0x4E1E_B234_65C0_09EDL, + /* 195 */ 0x6D97_28DF_F4E8_34B5L, 0x01A6_5EC1_7F30_0C68L, + /* 196 */ 0x447E_798B_F911_20F1L, 0x1107_FB38_EF7E_07C1L, + /* 197 */ 0x559E_17EE_F755_692DL, 0x3549_FA07_2B5D_89B1L, + /* 198 */ 0x6B05_9DEA_B52A_C378L, 0x629C_7888_F634_EC1EL, + /* 199 */ 0x42E3_82B2_B13A_BA2BL, 0x3DA1_CB55_99E1_1393L, + /* 200 */ 0x539C_635F_5D89_68B6L, 0x2D0A_3E2B_0059_5877L, + /* 201 */ 0x6883_7C37_34EB_C2E3L, 0x784C_CDB5_C06F_AE95L, + /* 202 */ 0x4152_2DA2_8113_59CEL, 0x3B30_0091_9845_CD1DL, + /* 203 */ 0x51A6_B90B_2158_3042L, 0x09FC_00B5_FE57_4065L, + /* 204 */ 0x6610_674D_E9AE_3C52L, 0x4C7B_00E3_7DED_107EL, + /* 205 */ 0x7F94_8121_6419_CB67L, 0x1F99_C11C_5D68_549DL, + /* 206 */ 0x4FBC_D0B4_DE90_1F20L, 0x43C0_18B1_BA61_34E2L, + /* 207 */ 0x63AC_04E2_1634_26E8L, 0x54B0_1EDE_28F9_821BL, + /* 208 */ 0x7C97_061A_9BC1_30A2L, 0x69DC_2695_B337_E2A1L, + /* 209 */ 0x4DDE_63D0_A158_BE65L, 0x6229_981D_9002_EDA5L, + /* 210 */ 0x6155_FCC4_C9AE_EDFFL, 0x1AB3_FE24_F403_A90EL, + /* 211 */ 0x79AB_7BF5_FC1A_A97FL, 0x0160_FDAE_3104_9351L, + /* 212 */ 0x4C0B_2D79_BD90_A9EFL, 0x30DC_9E8C_DEA2_DC13L, + /* 213 */ 0x5F0D_F8D8_2CF4_D46BL, 0x1D13_C630_164B_9318L, + /* 214 */ 0x76D1_770E_3832_0986L, 0x0458_B7BC_1BDE_77DDL, + /* 215 */ 0x4A42_EA68_E31F_45F3L, 0x62B7_72D5_916B_0AEBL, + /* 216 */ 0x5CD3_A503_1BE7_1770L, 0x5B65_4F8A_F5C5_CDA5L, + /* 217 */ 0x7408_8E43_E2E0_DD4CL, 0x723E_A36D_B337_410EL, + /* 218 */ 0x4885_58EA_6DCC_8A50L, 0x0767_2624_9002_88A9L, + /* 219 */ 0x5AA6_AF25_093F_ACE4L, 0x0940_EFAD_B403_2AD3L, + /* 220 */ 0x7150_5AEE_4B8F_981DL, 0x0B91_2B99_2103_F588L, + /* 221 */ 0x46D2_38D4_EF39_BF12L, 0x173A_BB3F_B4A2_7975L, + /* 222 */ 0x5886_C70A_2B08_2ED6L, 0x5D09_6A0F_A1CB_17D2L, + /* 223 */ 0x6EA8_78CC_B5CA_3A8CL, 0x344B_C493_8A3D_DDC7L, + /* 224 */ 0x4529_4B7F_F19E_6497L, 0x60AF_5ADC_3666_AA9CL, + /* 225 */ 0x5673_9E5F_EE05_FDBDL, 0x58DB_3193_4400_5543L, + /* 226 */ 0x6C10_85F7_E987_7D2DL, 0x0F11_FDF8_1500_6A94L, + /* 227 */ 0x438A_53BA_F1F4_AE3CL, 0x196B_3EBB_0D20_429DL, + /* 228 */ 0x546C_E8A9_AE71_D9CBL, 0x1FC6_0E69_D068_5344L, + /* 229 */ 0x6988_22D4_1A0E_503EL, 0x07B7_9204_4482_6815L, + /* 230 */ 0x41F5_15C4_9048_F226L, 0x64D2_BB42_AAD1_810DL, + /* 231 */ 0x5272_5B35_B45B_2EB0L, 0x3E07_6A13_5585_E150L, + /* 232 */ 0x670E_F203_2171_FA5CL, 0x4D89_4498_2AE7_59A4L, + /* 233 */ 0x4069_5741_F4E7_3C79L, 0x7075_CADF_1AD0_9807L, + /* 234 */ 0x5083_AD12_7221_0B98L, 0x2C93_3D96_E184_BE08L, + /* 235 */ 0x64A4_9857_0EA9_4E7EL, 0x37B8_0CFC_99E5_ED8AL, + /* 236 */ 0x7DCD_BE6C_D253_A21EL, 0x05A6_103B_C05F_68EDL, + /* 237 */ 0x4EA0_9704_0374_4552L, 0x6387_CA25_583B_A194L, + /* 238 */ 0x6248_BCC5_0451_56A7L, 0x3C69_BCAE_AE4A_89F9L, + /* 239 */ 0x7ADA_EBF6_4565_AC51L, 0x2B84_2BDA_59DD_2C77L, + /* 240 */ 0x4CC8_D379_EB5F_8BB2L, 0x6B32_9B68_782A_3BCBL, + /* 241 */ 0x5FFB_0858_6637_6E9FL, 0x45FF_4242_9634_CABDL, + /* 242 */ 0x77F9_CA6E_7FC5_4A47L, 0x377F_12D3_3BC1_FD6DL, + /* 243 */ 0x4AFC_1E85_0FDB_4E6CL, 0x52AF_6BC4_0559_3E64L, + /* 244 */ 0x5DBB_2626_53D2_2207L, 0x675B_46B5_06AF_8DFDL, + /* 245 */ 0x7529_EFAF_E8C6_AA89L, 0x6132_1862_485B_717CL, + /* 246 */ 0x493A_35CD_F17C_2A96L, 0x0CBF_4F3D_6D39_26EEL, + /* 247 */ 0x5B88_C341_6DDB_353BL, 0x4FEF_230C_C887_70A9L, + /* 248 */ 0x726A_F411_C952_028AL, 0x43EA_EBCF_FAA9_4CD3L, + /* 249 */ 0x4782_D88B_1DD3_4196L, 0x4A72_D361_FCA9_D004L, + /* 250 */ 0x5963_8EAD_E548_11FCL, 0x1D0F_883A_7BD4_4405L, + /* 251 */ 0x6FBC_7259_5E9A_167BL, 0x2453_6A49_1AC9_5506L, + /* 252 */ 0x45D5_C777_DB20_4E0DL, 0x06B4_226D_B0BD_D524L, + /* 253 */ 0x574B_3955_D1E8_6190L, 0x2861_2B09_1CED_4A6DL, + /* 254 */ 0x6D1E_07AB_4662_79F4L, 0x3279_75CB_6428_9D08L, + /* 255 */ 0x4432_C4CB_0BFD_8C38L, 0x5F8B_E99F_1E99_6225L, + /* 256 */ 0x553F_75FD_CEFC_EF46L, 0x776E_E406_E63F_BAAEL, + /* 257 */ 0x6A8F_537D_42BC_2B18L, 0x554A_9D08_9FCF_A95AL, + /* 258 */ 0x4299_942E_49B5_9AEFL, 0x354E_A225_63E1_C9D8L, + /* 259 */ 0x533F_F939_DC23_01ABL, 0x22A2_4AAE_BCDA_3C4EL, + /* 260 */ 0x680F_F788_532B_C216L, 0x0B4A_DD5A_6C10_CB62L, + /* 261 */ 0x4109_FAB5_33FB_594DL, 0x670E_CA58_838A_7F1DL, + /* 262 */ 0x514C_7962_80FA_2FA1L, 0x20D2_7CEE_A46D_1EE4L, + /* 263 */ 0x659F_97BB_2138_BB89L, 0x4907_1C2A_4D88_669DL, + /* 264 */ 0x7F07_7DA9_E986_EA6BL, 0x7B48_E334_E0EA_8045L, + /* 265 */ 0x4F64_AE8A_31F4_5283L, 0x3D0D_8E01_0C92_902BL, + /* 266 */ 0x633D_DA2C_BE71_6724L, 0x2C50_F181_4FB7_3436L, + /* 267 */ 0x7C0D_50B7_EE0D_C0EDL, 0x3765_2DE1_A3A5_0143L, + /* 268 */ 0x4D88_5272_F4C8_9894L, 0x329F_3CAD_0647_20CAL, + /* 269 */ 0x60EA_670F_B1FA_BEB9L, 0x3F47_0BD8_47D8_E8FDL, + /* 270 */ 0x7925_00D3_9E79_6E67L, 0x6F18_CECE_59CF_233CL, + /* 271 */ 0x4BB7_2084_430B_E500L, 0x756F_8140_F821_7605L, + /* 272 */ 0x5EA4_E8A5_53CE_DE41L, 0x12CB_6191_3629_D387L, + /* 273 */ 0x764E_22CE_A8C2_95D1L, 0x377E_39F5_83B4_4868L, + /* 274 */ 0x49F0_D5C1_2979_9DA2L, 0x72AE_E439_7250_AD41L, + /* 275 */ 0x5C6D_0B31_73D8_050BL, 0x4F5A_9D47_CEE4_D891L, + /* 276 */ 0x7388_4DFD_D0CE_064EL, 0x4331_4499_C29E_0EB6L, + /* 277 */ 0x4835_30BE_A280_C3F1L, 0x09FE_CAE0_19A2_C932L, + /* 278 */ 0x5A42_7CEE_4B20_F4EDL, 0x2C7E_7D98_200B_7B7EL, + /* 279 */ 0x70D3_1C29_DDE9_3228L, 0x579E_1CFE_280E_5A5DL, + /* 280 */ 0x4683_F19A_2AB1_BF59L, 0x36C2_D21E_D908_F87BL, + /* 281 */ 0x5824_EE00_B55E_2F2FL, 0x6473_86A6_8F4B_3699L, + /* 282 */ 0x6E2E_2980_E2B5_BAFBL, 0x5D90_6850_331E_043FL, + /* 283 */ 0x44DC_D9F0_8DB1_94DDL, 0x2A7A_4132_1FF2_C2A8L, + /* 284 */ 0x5614_106C_B11D_FA14L, 0x5518_D17E_A7EF_7352L, + /* 285 */ 0x6B99_1487_DD65_7899L, 0x6A5F_05DE_51EB_5026L, + /* 286 */ 0x433F_ACD4_EA5F_6B60L, 0x127B_63AA_F333_1218L, + /* 287 */ 0x540F_980A_24F7_4638L, 0x171A_3C95_AFFF_D69EL, + /* 288 */ 0x6913_7E0C_AE35_17C6L, 0x1CE0_CBBB_1BFF_CC45L, + /* 289 */ 0x41AC_2EC7_ECE1_2EDBL, 0x720C_7F54_F17F_DFABL, + /* 290 */ 0x5217_3A79_E819_7A92L, 0x6E8F_9F2A_2DDF_D796L, + /* 291 */ 0x669D_0918_621F_D937L, 0x4A33_86F4_B957_CD7BL, + /* 292 */ 0x4022_25AF_3D53_E7C2L, 0x5E60_3458_F3D6_E06DL, + /* 293 */ 0x502A_AF1B_0CA8_E1B3L, 0x35F8_416F_30CC_9888L, + /* 294 */ 0x6435_5AE1_CFD3_1A20L, 0x2376_51CA_FCFF_BEAAL, + /* 295 */ 0x7D42_B19A_43C7_E0A8L, 0x2C53_E63D_BC3F_AE55L, + /* 296 */ 0x4E49_AF00_6A5C_EC69L, 0x1BB4_6FE6_95A7_CCF5L, + /* 297 */ 0x61DC_1AC0_84F4_2783L, 0x42A1_8BE0_3B11_C033L, + /* 298 */ 0x7A53_2170_A631_3164L, 0x3349_EED8_49D6_303FL, + /* 299 */ 0x4C73_F4E6_67DE_BEDEL, 0x600E_3547_2E25_DE28L, + /* 300 */ 0x5F90_F220_01D6_6E96L, 0x3811_C298_F9AF_55B1L, + /* 301 */ 0x7775_2EA8_024C_0A3CL, 0x0616_333F_381B_2B1EL, + /* 302 */ 0x4AA9_3D29_016F_8665L, 0x43CD_E007_8310_FAF3L, + /* 303 */ 0x5D53_8C73_41CB_67FEL, 0x74C1_5809_63D5_39AFL, + /* 304 */ 0x74A8_6F90_123E_41FEL, 0x51F1_AE0B_BCCA_881BL, + /* 305 */ 0x48E9_45BA_0B66_E93FL, 0x1337_0CC7_55FE_9511L, + /* 306 */ 0x5B23_9728_8E40_A38EL, 0x7804_CFF9_2B7E_3A55L, + /* 307 */ 0x71EC_7CF2_B1D0_CC72L, 0x5606_03F7_765D_C8EAL, + /* 308 */ 0x4733_CE17_AF22_7FC7L, 0x55C3_C27A_A9FA_9D93L, + /* 309 */ 0x5900_C19D_9AEB_1FB9L, 0x4B34_B319_5479_44F7L, + /* 310 */ 0x6F40_F205_01A5_E7A7L, 0x7E01_DFDF_A997_9635L, + /* 311 */ 0x4588_9743_2107_B0C8L, 0x7EC1_2BEB_C9FE_BDE1L, + /* 312 */ 0x56EA_BD13_E949_9CFBL, 0x1E71_76E6_BC7E_6D59L, + /* 313 */ 0x6CA5_6C58_E39C_043AL, 0x060D_D4A0_6B9E_08B0L, + /* 314 */ 0x43E7_63B7_8E41_82A4L, 0x23C8_A4E4_4342_C56EL, + /* 315 */ 0x54E1_3CA5_71D1_E34DL, 0x2CBA_CE1D_5413_76C9L, + /* 316 */ 0x6A19_8BCE_CE46_5C20L, 0x57E9_81A4_A918_547BL, + /* 317 */ 0x424F_F761_40EB_F994L, 0x36F1_F106_E9AF_34CDL, + /* 318 */ 0x52E3_F539_9126_F7F9L, 0x44AE_6D48_A41B_0201L, + /* 319 */ 0x679C_F287_F570_B5F7L, 0x75DA_089A_CD21_C281L, + /* 320 */ 0x40C2_1794_F966_71BAL, 0x79A8_4560_C035_1991L, + /* 321 */ 0x50F2_9D7A_37C0_0E29L, 0x5812_56B8_F042_5FF5L, + /* 322 */ 0x652F_44D8_C5B0_11B4L, 0x0E16_EC67_2C52_F7F2L, + /* 323 */ 0x7E7B_160E_F71C_1621L, 0x119C_A780_F767_B5EEL, + /* 324 */ 0x4F0C_EDC9_5A71_8DD4L, 0x5B01_E8B0_9AA0_D1B5L, + }; + +} diff --git a/test/jdk/java/lang/FPToDecimal/DoubleToDecString.java b/test/jdk/java/lang/FPToDecimal/DoubleToDecString.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/DoubleToDecString.java @@ -0,0 +1,320 @@ +/* + * Copyright 2018-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 java.util.Random; + +import static java.lang.Math.*; +import static java.lang.Double.*; + +/* + * @test + * @bug 8202555 + * @author Raffaello Giulietti + */ +public class DoubleToDecString { + + private static final boolean FAILURE_THROWS_EXCEPTION = true; + + private static void assertTrue(boolean ok, double v, String s) { + if (ok) { + return; + } + String message = "Double::toString applied to " + + "Double.longBitsToDouble(" + + "0x" + Long.toHexString(doubleToRawLongBits(v)) + "L" + + ")" + + " returns " + + "\"" + s + "\"" + + ", which is not correct according to the specification."; + if (FAILURE_THROWS_EXCEPTION) { + throw new RuntimeException(message); + } + System.err.println(message); + } + + private static void toDec(double v) { +// String s = Double.toString(v); + String s = DoubleToDecimal.toString(v); + assertTrue(new DoubleToStringChecker(v, s).isOK(), v, s); + } + + 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 + */ + toDec(4.9E-324); + toDec(9.9E-324); + } + + /* + 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 = -323; e <= 309; ++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.0) { + 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" + */ + 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 100_000. + These are all exact doubles. + */ + 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() { + Random r = new Random(); + for (int i = 0; i < 1_000_000; ++i) { + toDec(longBitsToDouble(r.nextLong())); + } + } + + /* + Random doubles over the integer range [0, 10^15). + These integers are all exact doubles. + */ + private static void testRandomUnit() { + Random r = new Random(); + for (int i = 0; i < 100_000; ++i) { + toDec(r.nextLong() % 1_000_000_000_000_000L); + } + } + + /* + Random doubles over the range [0, 10^15) as "multiples" of 1e-3 + */ + private static void testRandomMilli() { + Random r = new Random(); + for (int i = 0; i < 100_000; ++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() { + Random r = new Random(); + for (int i = 0; i < 100_000; ++i) { + toDec((r.nextLong() & 0x7FFF_FFFF_FFFF_FFFFL) / 1e6); + } + } + + public static void main(String[] args) { + testExtremeValues(); + testSomeAnomalies(); + testPowersOf2(); + testPowersOf10(); + testPaxson(); + testInts(); + testLongs(); + testRandom(); + testRandomUnit(); + testRandomMilli(); + testRandomMicro(); + } + +} diff --git a/test/jdk/java/lang/FPToDecimal/DoubleToStringChecker.java b/test/jdk/java/lang/FPToDecimal/DoubleToStringChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/DoubleToStringChecker.java @@ -0,0 +1,92 @@ +/* + * Copyright 2018-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 java.math.BigDecimal; + +/** + * @author Raffaello Giulietti + */ +class DoubleToStringChecker extends StringChecker { + + private double v; + + DoubleToStringChecker(double v, String s) { + super(s); + this.v = v; + } + + @Override + BigDecimal toBigDecimal() { + return new BigDecimal(v); + } + + @Override + boolean recovers(BigDecimal b) { + return b.doubleValue() == v; + } + + @Override + boolean recovers(String s) { + return Double.parseDouble(s) == v; + } + + @Override + int maxExp() { + return 309; + } + + @Override + int minExp() { + return -323; + } + + @Override + int maxLen10() { + return 17; + } + + @Override + boolean isZero() { + return v == 0; + } + + @Override + boolean isInfinity() { + return v == Double.POSITIVE_INFINITY; + } + + @Override + void invert() { + v = -v; + } + + @Override + boolean isNegative() { + return Double.doubleToRawLongBits(v) < 0; + } + + @Override + boolean isNaN() { + return Double.isNaN(v); + } + +} diff --git a/test/jdk/java/lang/FPToDecimal/FloatToDecString.java b/test/jdk/java/lang/FPToDecimal/FloatToDecString.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/FloatToDecString.java @@ -0,0 +1,157 @@ +/* + * Copyright 2018-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 java.util.Random; + +import static java.lang.Float.*; + +/* + * @test + * @author Raffaello Giulietti + */ +public class FloatToDecString { + + private static final boolean FAILURE_THROWS_EXCEPTION = true; + + private static void assertTrue(boolean ok, float v, String s) { + if (ok) { + return; + } + String message = "Float::toString applied to " + + "Float.intBitsToFloat(" + + "0x" + Integer.toHexString(floatToRawIntBits(v)) + + ")" + + " returns " + + "\"" + s + "\"" + + ", which is not correct according to the specification."; + if (FAILURE_THROWS_EXCEPTION) { + throw new RuntimeException(message); + } + System.err.println(message); + } + + private static void toDec(float v) { +// String s = Float.toString(v); + String s = FloatToDecimal.toString(v); + assertTrue(new FloatToStringChecker(v, s).isOK(), v, s); + } + + /* + 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 + */ + toDec(1.4E-45F); + toDec(2.8E-45F); + toDec(4.2E-45F); + toDec(5.6E-45F); + toDec(7.0E-45F); + toDec(8.4E-45F); + toDec(9.8E-45F); + } + + /* + Many "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 = -44; e <= 39; ++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.0) { + toDec(v); + } + } + + /* + Tests all integers up to 1_000_000. + These are all exact floats. + */ + private static void testInts() { + for (int i = 0; i <= 1_000_000; ++i) { + toDec(i); + } + } + + /* + Random floats over the whole range. + */ + private static void testRandom() { + Random r = new Random(); + for (int i = 0; i < 1_000_000; ++i) { + toDec(intBitsToFloat(r.nextInt())); + } + } + + /* + All, really all, possible floats. Takes between 90 and 120 minutes. + */ + private static void testAll() { + int bits = Integer.MIN_VALUE; + for (; bits < Integer.MAX_VALUE; ++bits) { + toDec(Float.intBitsToFloat(bits)); + } + toDec(Float.intBitsToFloat(bits)); + } + + public static void main(String[] args) { +// testAll(); + testExtremeValues(); + testPowersOf2(); + testPowersOf10(); + testInts(); + testRandom(); + } + +} diff --git a/test/jdk/java/lang/FPToDecimal/FloatToStringChecker.java b/test/jdk/java/lang/FPToDecimal/FloatToStringChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/FloatToStringChecker.java @@ -0,0 +1,92 @@ +/* + * Copyright 2018-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 java.math.BigDecimal; + +/** + * @author Raffaello Giulietti + */ +class FloatToStringChecker extends StringChecker { + + private float v; + + FloatToStringChecker(float v, String s) { + super(s); + this.v = v; + } + + @Override + BigDecimal toBigDecimal() { + return new BigDecimal(v); + } + + @Override + boolean recovers(BigDecimal b) { + return b.floatValue() == v; + } + + @Override + boolean recovers(String s) { + return Float.parseFloat(s) == v; + } + + @Override + int maxExp() { + return 39; + } + + @Override + int minExp() { + return -44; + } + + @Override + int maxLen10() { + return 9; + } + + @Override + boolean isZero() { + return v == 0; + } + + @Override + boolean isInfinity() { + return v == Float.POSITIVE_INFINITY; + } + + @Override + void invert() { + v = -v; + } + + @Override + boolean isNegative() { + return Float.floatToRawIntBits(v) < 0; + } + + @Override + boolean isNaN() { + return Float.isNaN(v); + } + +} diff --git a/test/jdk/java/lang/FPToDecimal/MathUtilsChecks.java b/test/jdk/java/lang/FPToDecimal/MathUtilsChecks.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/MathUtilsChecks.java @@ -0,0 +1,438 @@ +/* + * Copyright 2018-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 java.math.BigInteger; + +import static java.math.BigInteger.*; + +import static jdk.internal.math.MathUtils.*; + +/* + * @test + * @author Raffaello Giulietti + */ +public class MathUtilsChecks { + + private static final BigInteger THREE = BigInteger.valueOf(3); + + private static void check(boolean claim) { + if (!claim) { + throw new RuntimeException(); + } + } + + /* + Let + 10^e = 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^e <= g 2^r + This is the predicate that will be checked in various forms. + + Throws an exception iff the check fails. + */ + private static void checkPow10(int e, long g1, long g0) { + // 2^62 <= g1 < 2^63, 0 <= g0 < 2^63 + check(g1 << 1 < 0 && g1 >= 0 && g0 >= 0); + + BigInteger g = valueOf(g1).shiftLeft(63).or(valueOf(g0)); + // double check that 2^125 <= g < 2^126 + check(g.signum() > 0 && g.bitLength() == 126); + + // see javadoc of MathUtils.g1(int) + int r = flog2pow10(e) - 125; + + /* + The predicate + (g - 1) 2^r <= 10^e < g 2^r + is equivalent to + g - 1 <= 10^e 2^(-r) < g + When + e >= 0 & r < 0 + all numerical subexpressions are integer-valued. This is the same as + g - 1 = 10^e 2^(-r) + */ + if (e >= 0 && r < 0) { + check(g.subtract(ONE).compareTo(TEN.pow(e).shiftLeft(-r)) == 0); + return; + } + + /* + The predicate + (g - 1) 2^r <= 10^e < g 2^r + is equivalent to + g 10^(-e) - 10^(-e) <= 2^(-r) < g 10^(-e) + When + e < 0 & r < 0 + all numerical subexpressions are integer-valued. + */ + if (e < 0 && r < 0) { + BigInteger pow5 = TEN.pow(-e); + BigInteger mhs = ONE.shiftLeft(-r); + BigInteger rhs = g.multiply(pow5); + check(rhs.subtract(pow5).compareTo(mhs) <= 0 && + mhs.compareTo(rhs) < 0); + return; + } + + /* + Finally, when + e >= 0 & r >= 0 + the predicate + (g - 1) 2^r < 10^e <= g 2^r + can be used straightforwardly as all numerical subexpressions are + already integer-valued. + */ + if (e >= 0) { + BigInteger mhs = TEN.pow(e); + check(g.subtract(ONE).shiftLeft(r).compareTo(mhs) <= 0 && + mhs.compareTo(g.shiftLeft(r)) < 0); + return; + } + + /* + For combinatorial reasons, the only remaining case is + e < 0 & r >= 0 + which, however, cannot arise. Indeed, the predicate + (g - 1) 2^r <= 10^e < g 2^r + implies + (g - 1) 2^r 10^(-e) <= 1 + which cannot hold, as the left-hand side is greater than 1. + */ + check(false); + } + + /* + Verifies the soundness of the values returned by + g1() and g0(). + */ + private static void testPow10Table() { + for (int e = MIN_EXP; e <= MAX_EXP; ++e) { + checkPow10(e, g1(e), g0(e)); + } + } + + /* + Let + k = floor(log10(3/4 2^e)) + The method verifies that + k = flog10threeQuartersPow2(e), |e| <= 300_000 + This range amply covers all binary exponents of IEEE 754 binary formats up + to binary256 (octuple precision), so also suffices for 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 + */ + check(flog10threeQuartersPow2(1) == 0); + + /* + Now check the range -300_000 <= 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); + check(k0 < 0); + BigInteger l = THREE.multiply(TEN.pow(-k0 - 1)); + BigInteger u = l.multiply(TEN); + for (;;) { + check(l.bitLength() <= 2 - e && 2 - e < u.bitLength()); + if (e == -300_000) { + break; + } + --e; + int kp = flog10threeQuartersPow2(e); + check(kp <= k0); + if (kp < k0) { + // k changes at most by 1 at each iteration, hence: + check(k0 - kp == 1); + k0 = kp; + l = u; + u = u.multiply(TEN); + } + } + + /* + Finally, check the range 2 <= e <= 300_000. + 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 integer-valued. + 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); + check(k0 >= 0); + BigInteger l10 = TEN.pow(k0); + BigInteger u10 = l10.multiply(TEN); + l = l10.divide(THREE); + u = u10.divide(THREE); + for (;;) { + check(l.bitLength() <= e - 2 && e - 2 < u.bitLength()); + if (e == 300_000) { + break; + } + ++e; + int kp = flog10threeQuartersPow2(e); + check(kp >= k0); + if (kp > k0) { + // k changes at most by 1 at each iteration, hence: + check(kp - k0 == 1); + 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), |e| <= 300_000 + This range amply covers all binary exponents of IEEE 754 binary formats up + to binary256 (octuple precision), so also suffices for doubles and floats. + + The first equation above is equivalent to + 10^k <= 2^e < 10^(k+1) + Equality holds iff e = 0, implying 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 + */ + check(flog10pow2(0) == 0); + + /* + Now check the range -300_000 <= 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 integer-valued 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); + check(k < 0); + BigInteger l = TEN.pow(-k - 1); + BigInteger u = l.multiply(TEN); + for (;;) { + check(l.bitLength() <= -e && -e < u.bitLength()); + if (e == -300_000) { + break; + } + --e; + int kp = flog10pow2(e); + check(kp <= k); + if (kp < k) { + // k changes at most by 1 at each iteration, hence: + check(k - kp == 1); + k = kp; + l = u; + u = u.multiply(TEN); + } + } + + /* + Finally, in a similar vein, check the range 0 <= e <= 300_000. + 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 integer-valued. + */ + e = 1; + k = flog10pow2(e); + check(k >= 0); + l = TEN.pow(k); + u = l.multiply(TEN); + for (;;) { + check(l.bitLength() <= e && e < u.bitLength()); + if (e == 300_000) { + break; + } + ++e; + int kp = flog10pow2(e); + check(kp >= k); + if (kp > k) { + // k changes at most by 1 at each iteration, hence: + check(kp - k == 1); + k = kp; + l = u; + u = u.multiply(TEN); + } + } + } + + /* + Let + k = floor(log2(10^e)) + The method verifies that + k = flog2pow10(e), |e| <= 100_000 + This range amply covers all decimal exponents of IEEE 754 binary formats up + to binary256 (octuple precision), so also suffices for 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 + */ + check(flog2pow10(0) == 0); + + /* + Now check the range -100_000 <= 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); + check(k0 <= -4); + BigInteger l = TEN; + for (;;) { + check(l.bitLength() == -k0); + if (e == -100_000) { + break; + } + --e; + k0 = flog2pow10(e); + l = l.multiply(TEN); + } + + /* + Finally check the range 0 < e <= 100_000. + 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); + check(k0 >= 3); + l = TEN; + for (;;) { + check(l.bitLength() == k0 + 1); + if (e == 100_000) { + break; + } + ++e; + k0 = flog2pow10(e); + l = l.multiply(TEN); + } + } + + public static void main(String[] args) { + testPow10Table(); + testFlog10pow2(); + testFlog10threeQuartersPow2(); + testFlog2pow10(); + } + +} diff --git a/test/jdk/java/lang/FPToDecimal/StringChecker.java b/test/jdk/java/lang/FPToDecimal/StringChecker.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/lang/FPToDecimal/StringChecker.java @@ -0,0 +1,354 @@ +/* + * Copyright 2018-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 java.io.IOException; +import java.io.StringReader; +import java.math.BigDecimal; + +/** + * @author Raffaello Giulietti + */ +abstract class StringChecker { + /* + A checker for the Javadoc specification. + It just relies on straightforward use of (expensive) BigDecimal arithmetic, + not optimized at all. + */ + + private String s; + private long c; + private int q; + private int len10; + + StringChecker(String s) { + this.s = s; + } + + /* + Returns whether s syntactically meets the expected output of + Double::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() { + try { + // first determine interesting boundaries in the string + StringReader r = new StringReader(s); + 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 != s.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; + } + } + + boolean isOK() { + if (isNaN()) { + return s.equals("NaN"); + } + if (isNegative()) { + if (s.isEmpty() || s.charAt(0) != '-') { + return false; + } + invert(); + s = s.substring(1); + } + if (isInfinity()) { + return s.equals("Infinity"); + } + if (isZero()) { + return s.equals("0.0"); + } + if (!parse()) { + 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(s)) { + 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 int maxExp(); + + abstract int minExp(); + + abstract int maxLen10(); + + abstract boolean isZero(); + + abstract boolean isInfinity(); + + abstract void invert(); + + abstract boolean isNegative(); + + abstract boolean isNaN(); + +} From Alan.Bateman at oracle.com Sun Feb 17 17:37:52 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 17 Feb 2019 17:37:52 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> Message-ID: <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> On 15/02/2019 17:13, Chris Hegarty wrote: > : > I see that there are changes to the Java SE Platform, namely to the > MapMode constructor and an overload of MappedByteBuffer::force. I see > these more as "enablers" in support of this feature ( rather than the > core of the feature itself ). They can happen as part of the same > changeset, or could possibly be pushed separately upfront. > Yes, the 2-arg force method is useful on its own and could be done in advance (if Andrew wants). There are several detailed API issues with this method but we should be able to agree those quickly (Andrew - these are issues due to MBB being a ByteBuffer so we have to sort out - long from/to vs. int index/size, the upper bound check against the limit rather the capacity, and IAE vs. IIOBE - I'll put these in another mail). Making map mode extensible is also something that can be done in advance. The only piece that is would make it SE scope is the isSync (was isPersistent) method but I don't think it is strictly needed to be exposed initially. -Alan From magnus.ihse.bursie at oracle.com Sun Feb 17 18:43:00 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sun, 17 Feb 2019 19:43:00 +0100 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> Message-ID: <0C35970E-82CA-4DB8-8F7D-B86A3E01B8FD@oracle.com> > 16 feb. 2019 kl. 04:03 skrev Alexander Matveev : > > Hi Magnus, > > http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ > > Moved all files from "posix" to "unix" folder and reverted Lib-jdk.jpackage.gmk changes. > Webrev updated with files moved, instead of add/remove. Thank you! This looks good now from a build point of view, but you'll need a review from core-libs as well. /Magnus > > Thanks, > Alexander > >> On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: >> >> >>> On 2019-02-15 04:31, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). >>> >>> - Moved native code under platform specific folder. >>> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. >>> - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp for Mac specific code to filter out some arguments. I decided to keep it as is for now, since Mac specific code is small. >>> - Defines are used in Platform.cpp to initialize platform specific classes. >>> - Removed all pragma warning and fixed all compilation warnings. >>> - Removed unused code. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8212091 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ >> The JDK standard is to use "unix", not "posix", for the shared functionality between linux/solaris/macosx. You can keep the name "PosixPlatform.*" if you want, though; the important thing is the directory name. >> >> Also, if you do that, you do not need any changes to make/lib/Lib-jdk.jpackage.gmk, since that will be automatically understood by the build system. >> >> It looks from the webrev that you have "moved" the files by doing "hg add" and "hg remove". Please use "hg move" instead -- this will keep history intact, and it allows reviewers to see if you have also made changes to the moved files. >> >> (If you do have modified the moved file, reverting a "hg add+hg remove" process is a bit more tricky -- you need to do "hg forget" on the new file, rename it to something else (otherwise "hg move" will complain), "hg revert" the old file back in place, do a "hg move" from the old to the new, and then copy the modified, renamed file back over the target new file again.) >> >> /Magnus >>> >>> Thanks, >>> Alexander > From adinn at redhat.com Mon Feb 18 11:15:18 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 18 Feb 2019 11:15:18 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> Message-ID: <3523d889-bd96-9709-ce7e-7a9fabf42de3@redhat.com> Hi Chris/Alan, On 17/02/2019 17:37, Alan Bateman wrote: > On 15/02/2019 17:13, Chris Hegarty wrote: >> : >> I see that there are changes to the Java SE Platform, namely to the >> MapMode constructor and an overload of MappedByteBuffer::force. I see >> these more as "enablers" in support of this feature ( rather than the >> core of the feature itself ). They can happen as part of the same >> changeset, or could possibly be pushed separately upfront. >> > Yes, the 2-arg force method is useful on its own and could be done in > advance (if Andrew wants). There are several detailed API issues with > this method but we should be able to agree those quickly (Andrew - these > are issues due to MBB being a ByteBuffer so we have to sort out - long > from/to vs. int index/size, the upper bound check against the limit > rather the capacity, and IAE vs. IIOBE - I'll put these in another > mail). Making map mode extensible is also something that can be done in > advance. The only piece that is would make it SE scope is the isSync > (was isPersistent) method but I don't think it is strictly needed to be > exposed initially. Ah well, perhaps we /can/ change the scope to JDK rather than SE. I finessed the isSync() issue by dropping it from the API. Provision of this method is not critical since I envisage that most clients which know about the SYNC option will always be using a SYNC buffer. If not, they can still easily be written to track how the buffer was created. So, the latest JEP does not mention the isSync method and the implementation makes it private. I'd be very happy to pre-push separate, enabling changes for 1) the 2-arg force method 2) making MapMode extensible. Alan, I'll wait for your follow-up note before responding regarding the arguments to force. I'll just note that the latest JEP draft accepts start position and length [i.e. force(from, length)] rather than start position and end position [i.e. force(from, to)]. I thought this would be easier for clients to get right -- less danger of out by one errors. 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, Eric Shander From arno.zeller at sap.com Mon Feb 18 12:49:24 2019 From: arno.zeller at sap.com (Zeller, Arno) Date: Mon, 18 Feb 2019 12:49:24 +0000 Subject: RFR(XS):JDK-8219228: java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test machine. Message-ID: Hello! I found that the test java/util/Base64/TestEncodingDecodingLength.java fails on a machine with 8GB memory after JDK-8218265. The test starts a VM with -Xmx8GB but the VM needs some more memory than only the heap and on machines with just 8GB of memory (and no swap configured) the test will always fail because the VM cannot get enough native memory. Therefore I suggest to increase "@requires os.maxMemory" to >= 10GB to be safe. Could someone please review this minimal change? Bug: https://bugs.openjdk.java.net/browse/JDK-8219228 Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8219228/ Thanks and best regards, Arno From christoph.langer at sap.com Mon Feb 18 15:35:20 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 18 Feb 2019 15:35:20 +0000 Subject: RFR(XS):JDK-8219228: java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test machine. In-Reply-To: References: Message-ID: Hi Arno, this looks good and trivial. I'll sponsor this one. Maybe one of the authors/reviewers of the original fix for bug https://bugs.openjdk.java.net/browse/JDK-8218265 (Nishit, Roger, Naoto) should approve this. Thanks Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Zeller, Arno > Sent: Montag, 18. Februar 2019 13:49 > To: core-libs-dev > Subject: [CAUTION] RFR(XS):JDK-8219228: > java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test > machine. > > Hello! > > I found that the test java/util/Base64/TestEncodingDecodingLength.java fails > on a machine with 8GB memory after JDK-8218265. > The test starts a VM with -Xmx8GB but the VM needs some more memory > than only the heap and on machines with just 8GB of memory (and no swap > configured) the test will always fail because the VM cannot get enough > native memory. > Therefore I suggest to increase "@requires os.maxMemory" to >= 10GB to > be safe. > > Could someone please review this minimal change? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219228 > > Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8219228/ > > Thanks and best regards, > Arno From turbanoff at gmail.com Sun Feb 17 12:11:15 2019 From: turbanoff at gmail.com (Andrey Turbanov) Date: Sun, 17 Feb 2019 15:11:15 +0300 Subject: PATCH. JDK-4887513 Typo in RMIFailureHandler interface doc page Message-ID: Hello. I would like to contribute a small patch for bug: https://bugs.openjdk.java.net/browse/JDK-4887513 Index: src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java (revision 8df4dc07bd6f5545048485493c2edfc5bab53bbb) +++ src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java (date 1550354580517) @@ -43,9 +43,8 @@ * The failure callback is invoked when the RMI * runtime is unable to create a ServerSocket via the * RMISocketFactory. An RMIFailureHandler - * is registered via a call to - * RMISocketFacotry.setFailureHandler. If no failure - * handler is installed, the default behavior is to attempt to + * is registered via a call to RMISocketFactory.setFailureHandler. + * If no failure handler is installed, the default behavior is to attempt to * re-create the ServerSocket. * * @param ex the exception that occurred during ServerSocket Andrey Turbanov From ivan.gerasimov at oracle.com Tue Feb 19 06:32:22 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 18 Feb 2019 22:32:22 -0800 Subject: PATCH. JDK-4887513 Typo in RMIFailureHandler interface doc page In-Reply-To: References: Message-ID: Hi Andrey! The fix looks Okay. I can sponsor pushing the fix for you. With kind regards, Ivan On 2/17/19 4:11 AM, Andrey Turbanov wrote: > Hello. > I would like to contribute a small patch for bug: > https://bugs.openjdk.java.net/browse/JDK-4887513 > > Index: src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java > (revision 8df4dc07bd6f5545048485493c2edfc5bab53bbb) > +++ src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java > (date 1550354580517) > @@ -43,9 +43,8 @@ > * The failure callback is invoked when the RMI > * runtime is unable to create a ServerSocket via the > * RMISocketFactory. An RMIFailureHandler > - * is registered via a call to > - * RMISocketFacotry.setFailureHandler. If no failure > - * handler is installed, the default behavior is to attempt to > + * is registered via a call to > RMISocketFactory.setFailureHandler. > + * If no failure handler is installed, the default behavior is to > attempt to > * re-create the ServerSocket. > * > * @param ex the exception that occurred during ServerSocket > > > > Andrey Turbanov > -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Tue Feb 19 06:51:03 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 18 Feb 2019 22:51:03 -0800 Subject: PATCH. JDK-4887513 Typo in RMIFailureHandler interface doc page In-Reply-To: References: Message-ID: I took opportunity to update the copyright year and replace tags ...<\code> with {@code ...}, so that this code can be left untouched for next 21 years :) Here is the webrev with all the changes: http://cr.openjdk.java.net/~igerasim/4887513/00/webrev/ With kind regards, Ivan On 2/18/19 10:32 PM, Ivan Gerasimov wrote: > Hi Andrey! > > The fix looks Okay. I can sponsor pushing the fix for you. > > With kind regards, > > Ivan > > > On 2/17/19 4:11 AM, Andrey Turbanov wrote: >> Hello. >> I would like to contribute a small patch for bug: >> https://bugs.openjdk.java.net/browse/JDK-4887513 >> >> Index: src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java >> IDEA additional info: >> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >> <+>UTF-8 >> =================================================================== >> --- src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java >> (revision 8df4dc07bd6f5545048485493c2edfc5bab53bbb) >> +++ src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java >> (date 1550354580517) >> @@ -43,9 +43,8 @@ >> * The failure callback is invoked when the RMI >> * runtime is unable to create a ServerSocket via the >> * RMISocketFactory. An >> RMIFailureHandler >> - * is registered via a call to >> - * RMISocketFacotry.setFailureHandler. If no failure >> - * handler is installed, the default behavior is to attempt to >> + * is registered via a call to >> RMISocketFactory.setFailureHandler. >> + * If no failure handler is installed, the default behavior is to >> attempt to >> * re-create the ServerSocket. >> * >> * @param ex the exception that occurred during >> ServerSocket >> >> >> >> Andrey Turbanov >> > -- With kind regards, Ivan Gerasimov From nishit.jain at oracle.com Tue Feb 19 09:05:17 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Tue, 19 Feb 2019 14:35:17 +0530 Subject: RFR(XS):JDK-8219228: java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test machine. In-Reply-To: References: Message-ID: <3f54e68f-729d-864e-b12a-c81f21cd4dad@oracle.com> Hi Arno, Although I don't know if turning off or no swap is expected for a test environment, but tried reproducing the issue locally on a 8Gb Ubuntu linux VM with swap turned off, the test case was passing until I started some other app (like browser) in parallel, in which case it failed with error = "Not enough space". Since it is a memory intensive test, I think it is better and safe to increase "os.maxMemory" check Change looks good to me, I am not an openJDK reviewer though. Regards, Nishit Jain On 18-02-2019 18:19, Zeller, Arno wrote: > Hello! > > I found that the test java/util/Base64/TestEncodingDecodingLength.java fails on a machine with 8GB memory after JDK-8218265. > The test starts a VM with -Xmx8GB but the VM needs some more memory than only the heap and on machines with just 8GB of memory (and no swap configured) the test will always fail because the VM cannot get enough native memory. > Therefore I suggest to increase "@requires os.maxMemory" to >= 10GB to be safe. > > Could someone please review this minimal change? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219228 > > Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8219228/ > > Thanks and best regards, > Arno > From ivan.gerasimov at oracle.com Tue Feb 19 11:21:51 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 19 Feb 2019 03:21:51 -0800 Subject: PATCH. JDK-4887513 Typo in RMIFailureHandler interface doc page In-Reply-To: References: Message-ID: <0bd6956b-9cf8-f488-afb2-49f2659d293b@oracle.com> Actually, it's not a bug, it a tradition of English spacing. It will not affect the resulting HTML, of course. With kind regards, Ivan On 2/18/19 11:23 PM, Andrey Turbanov wrote: >> + * {@code RMISocketFactory.setFailureHandler}. If no failure > One redundant space before "If" > > Andrey Turbanov > -- With kind regards, Ivan Gerasimov From daniel.fuchs at oracle.com Tue Feb 19 11:59:49 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 19 Feb 2019 11:59:49 +0000 Subject: PATCH. JDK-4887513 Typo in RMIFailureHandler interface doc page In-Reply-To: References: Message-ID: Looks good to me Ivan! Thanks for updating the file with {@code }. best regards, -- daniel On 19/02/2019 06:51, Ivan Gerasimov wrote: > I took opportunity to update the copyright year and replace tags > ...<\code> with {@code ...}, so that this code can be left > untouched for next 21 years :) > > Here is the webrev with all the changes: > http://cr.openjdk.java.net/~igerasim/4887513/00/webrev/ > > With kind regards, > Ivan From arno.zeller at sap.com Tue Feb 19 12:25:31 2019 From: arno.zeller at sap.com (Zeller, Arno) Date: Tue, 19 Feb 2019 12:25:31 +0000 Subject: RFR(XS):JDK-8219228: java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test machine. In-Reply-To: <3f54e68f-729d-864e-b12a-c81f21cd4dad@oracle.com> References: <3f54e68f-729d-864e-b12a-c81f21cd4dad@oracle.com> Message-ID: <00ca554a5ae84efa94e2bccccdb5fabb@sap.com> Hi Nishit, thanks for testing! Best regards, Arno >-----Original Message----- >From: Nishit Jain >Sent: Dienstag, 19. Februar 2019 10:05 >To: Zeller, Arno ; core-libs-dev dev at openjdk.java.net> >Subject: Re: RFR(XS):JDK-8219228: >java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test >machine. > >Hi Arno, > >Although I don't know if turning off or no swap is expected for a test >environment, but tried reproducing the issue locally on a 8Gb Ubuntu >linux VM with swap turned off, the test case was passing until I started >some other app (like browser) in parallel, in which case it failed with >error = "Not enough space". Since it is a memory intensive test, I think >it is better and safe to increase "os.maxMemory" check > >Change looks good to me, I am not an openJDK reviewer though. > >Regards, >Nishit Jain >On 18-02-2019 18:19, Zeller, Arno wrote: >> Hello! >> >> I found that the test java/util/Base64/TestEncodingDecodingLength.java >fails on a machine with 8GB memory after JDK-8218265. >> The test starts a VM with -Xmx8GB but the VM needs some more memory >than only the heap and on machines with just 8GB of memory (and no swap >configured) the test will always fail because the VM cannot get enough native >memory. >> Therefore I suggest to increase "@requires os.maxMemory" to >= 10GB to >be safe. >> >> Could someone please review this minimal change? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219228 >> >> Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8219228/ >> >> Thanks and best regards, >> Arno >> From matthias.baesken at sap.com Tue Feb 19 13:01:31 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 19 Feb 2019 13:01:31 +0000 Subject: RFR(XS):JDK-8219228: java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test machine. Message-ID: Looks good to me (not a Reviewer however). Best regards, Matthias > > Message: 2 > Date: Mon, 18 Feb 2019 15:35:20 +0000 > From: "Langer, Christoph" > To: "Zeller, Arno" , Nishit Jain > , Naoto Sato , > Roger > Riggs > Cc: core-libs-dev > Subject: RE: RFR(XS):JDK-8219228: > java/util/Base64/TestEncodingDecodingLength.java failing on 8GB > test > machine. > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hi Arno, > > this looks good and trivial. I'll sponsor this one. > > Maybe one of the authors/reviewers of the original fix for bug > https://bugs.openjdk.java.net/browse/JDK-8218265 (Nishit, Roger, Naoto) > should approve this. > > Thanks > Christoph > > > > -----Original Message----- > > From: core-libs-dev On Behalf > > Of Zeller, Arno > > Sent: Montag, 18. Februar 2019 13:49 > > To: core-libs-dev > > Subject: [CAUTION] RFR(XS):JDK-8219228: > > java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test > > machine. > > > > Hello! > > > > I found that the test java/util/Base64/TestEncodingDecodingLength.java > fails > > on a machine with 8GB memory after JDK-8218265. > > The test starts a VM with -Xmx8GB but the VM needs some more memory > > than only the heap and on machines with just 8GB of memory (and no > swap > > configured) the test will always fail because the VM cannot get enough > > native memory. > > Therefore I suggest to increase "@requires os.maxMemory" to >= 10GB to > > be safe. > > > > Could someone please review this minimal change? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219228 > > > > Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8219228/ > > > > Thanks and best regards, > > Arno From deepak.kejriwal at oracle.com Tue Feb 19 13:55:01 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Tue, 19 Feb 2019 05:55:01 -0800 (PST) Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 Message-ID: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default> Hi All, Please review the backport of the following bug fixes to jdk8u-dev: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation. HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters. HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong short form text for supplemental Japanese era HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 currency code points to Java SE 8uX Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.00/ These code changes are made possible thanks to specification changes already pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7 Regards, Deepak From deepak.kejriwal at oracle.com Tue Feb 19 14:11:47 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Tue, 19 Feb 2019 06:11:47 -0800 (PST) Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 Message-ID: Hi All, Please review the backport of the following bug fixes to jdk8u-dev: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ These code changes are made possible thanks to specification change already pushed: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace Regards, Deepak From deepak.kejriwal at oracle.com Tue Feb 19 14:15:58 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Tue, 19 Feb 2019 06:15:58 -0800 (PST) Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 Message-ID: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> Correcting typo for release. From: Deepak Kejriwal Sent: Tuesday, February 19, 2019 7:42 PM To: 'core-libs-dev' ; 'jdk-updates-dev at openjdk.java.net' Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 Hi All, Please review the backport of the following bug fixes to jdk11u-dev: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ These code changes are made possible thanks to specification change already pushed: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace Regards, Deepak From shade at redhat.com Tue Feb 19 14:25:31 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 Feb 2019 15:25:31 +0100 Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 In-Reply-To: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> Message-ID: <93c82f62-eecd-657c-ea19-acfbe118aec2@redhat.com> Hi Deepak, Please follow the jdk-updates approval process: https://openjdk.java.net/projects/jdk-updates/approval.html You need to put appropriate tags at the issues, explain why they are needed, how the changes apply (if changes do not apply cleanly, ask for RFR -- is this what this thread is? -- and explain what was done to adapt changes to 11u), what testing is done, etc. -Aleksey On 2/19/19 3:15 PM, Deepak Kejriwal wrote: > Correcting typo for release. > > > > From: Deepak Kejriwal > Sent: Tuesday, February 19, 2019 7:42 PM > To: 'core-libs-dev' ; 'jdk-updates-dev at openjdk.java.net' > Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 > > > > Hi All, > > Please review the backport of the following bug fixes to jdk11u-dev: > > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points > > Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ > > These code changes are made possible thanks to specification change already pushed: > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace > > Regards, > Deepak > > > From nishit.jain at oracle.com Tue Feb 19 14:37:35 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Tue, 19 Feb 2019 20:07:35 +0530 Subject: [13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO In-Reply-To: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> References: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> Message-ID: Hi Naoto, Why is the default region set to "US" if there is no region specified in the locale? is this the default behavior of "first day of week" and "minimal days in first week" when a region is missing or the default behavior is that it returns "1"? Can't we just return "1" instead of setting the region to "US"? Regards, Nishit Jain On 16-02-2019 04:25, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8218960 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ > > The CONFIG message was generated because CLDRCalendarDataProviderImpl > was returning null for locales without region. Use "US" as the default > region in such a case. > > Naoto From Alan.Bateman at oracle.com Tue Feb 19 14:58:30 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2019 14:58:30 +0000 Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 In-Reply-To: <93c82f62-eecd-657c-ea19-acfbe118aec2@redhat.com> References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> <93c82f62-eecd-657c-ea19-acfbe118aec2@redhat.com> Message-ID: <641d5002-a5cc-a0f2-7305-23b2cf8c13db@oracle.com> On 19/02/2019 14:25, Aleksey Shipilev wrote: > Hi Deepak, > > Please follow the jdk-updates approval process: > https://openjdk.java.net/projects/jdk-updates/approval.html > > You need to put appropriate tags at the issues, explain why they are needed, how the changes apply > (if changes do not apply cleanly, ask for RFR -- is this what this thread is? -- and explain what > was done to adapt changes to 11u), what testing is done, etc. > I read Deepak's mails as code review requests. The context is issues related to support for external standards. There are MRs of both JSR 337 and JSR 384 in progress. Iris sent a good summary to jdk-update-dev in December [1]. Once the changes are reviewed then I assume Deepak will figure out the process/tagging to get the changes into the update repos but I don't think he's there yet. -Alan [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html From Roger.Riggs at oracle.com Tue Feb 19 15:10:22 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 19 Feb 2019 10:10:22 -0500 Subject: RFR(XS):JDK-8219228: java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test machine. In-Reply-To: <3f54e68f-729d-864e-b12a-c81f21cd4dad@oracle.com> References: <3f54e68f-729d-864e-b12a-c81f21cd4dad@oracle.com> Message-ID: <5cf41d0f-28c4-156d-cb9b-de84c68fb1b5@oracle.com> Looks fine,? Reviewed. On 02/19/2019 04:05 AM, Nishit Jain wrote: > Hi Arno, > > Although I don't know if turning off or no swap is expected for a test > environment, but tried reproducing the issue locally on a 8Gb Ubuntu > linux VM with swap turned off, the test case was passing until I > started some other app (like browser) in parallel, in which case it > failed with error = "Not enough space". Since it is a memory intensive > test, I think it is better and safe to increase "os.maxMemory" check > > Change looks good to me, I am not an openJDK reviewer though. > > Regards, > Nishit Jain > On 18-02-2019 18:19, Zeller, Arno wrote: >> Hello! >> >> I found that the test >> java/util/Base64/TestEncodingDecodingLength.java fails on a machine >> with 8GB memory after JDK-8218265. >> The test starts a VM with -Xmx8GB but the VM needs some more memory >> than only the heap and on machines with just 8GB of memory (and no >> swap configured) the test will always fail because the VM cannot get >> enough native memory. >> Therefore I suggest to increase "@requires os.maxMemory" to >= 10GB >> to be safe. >> >> Could someone please review this minimal change? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219228 >> >> Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8219228/ >> >> Thanks and best regards, >> Arno >> > From sean.coffey at oracle.com Tue Feb 19 15:14:30 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 19 Feb 2019 15:14:30 +0000 Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 In-Reply-To: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> Message-ID: Deepak, changes look fine to me. Some minor comments on formatting : make a space after all? "//" comments e.g. +???????? //isJavaIdentifierStart strictly conforms to code points assigned +???????? //in Unicode 10.0. Since code point {32FF} is not from Unicode 10.0, +???????? //return false. ? 33???? //New code point(Japanese Era Square character) not present in Unicode 10.0 ? 34???? private static final int newCodePoint = 0x32FF; ? 65???????????? //Since Character.isJavaIdentifierPart(int) strictly conforms to ? 66???????????? //character information from version 10.0 of the Unicode Standard, ? 67???????????? //check if code point is new code point. If the code point is new ? 68???????????? //code point, value of variable expected is considered false. ? typo in comment : ? make/data/characterdata/CharacterData00.java.template ??????? boolean isJavaIdentifierPart(int ch) { +???????? //isJavaIdentifierStart strictly conforms to code points assigned +???????? //in Unicode 10.0. Since code point {32FF} is not from Unicode 10.0, regards, Sean. On 19/02/2019 14:15, Deepak Kejriwal wrote: > Correcting typo for release. > > > > From: Deepak Kejriwal > Sent: Tuesday, February 19, 2019 7:42 PM > To: 'core-libs-dev' ; 'jdk-updates-dev at openjdk.java.net' > Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 > > > > Hi All, > > Please review the backport of the following bug fixes to jdk11u-dev: > > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points > > Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ > > These code changes are made possible thanks to specification change already pushed: > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace > > Regards, > Deepak > > From sean.coffey at oracle.com Tue Feb 19 15:24:20 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 19 Feb 2019 15:24:20 +0000 Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 In-Reply-To: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default> References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default> Message-ID: <73e6114c-bea8-ee6e-7294-ada06abc19b6@oracle.com> Looks fine to me. some minor comments on formatting : space after "//" style comments in your new tests : e.g > //List of new code points are not present in Unicode 6.2. > 39 add(0x20BB); //NORDIC MARK SIGN > 40 add(0x20BC); //MANAT SIGN > 41 add(0x20BD); //RUBLE SIGN > 42 add(0x20BE); //LARI SIGN > 43 add(0x20BF); //BITCOIN SIGN > 44 add(0x32FF); //SQUARE ERA NAME NEWERA > 77 //Since Character.isJavaIdentifierPart(int) strictly conforms to > 78 //character information from version 6.2 of the Unicode Standard, > 79 //check if code point is new code point. If the code point is new > 80 //code point, value of variable expected is considered false. this looks like a typo in one of your new tests : > 268 public static void testIsJavaLetterOrDigit() { > 269 for (int i = 0; i <= Character.MAX_VALUE; ++i) { > 270 char ch = (char) i; > 271 boolean expected = false; > 272 //Since Character.isIdentifierIgnorable(char) strictly conforms to regards, Sean. On 19/02/2019 13:55, Deepak Kejriwal wrote: > Hi All, > > Please review the backport of the following bug fixes to jdk8u-dev: > > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation. > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters. > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong short form text for supplemental Japanese era > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 currency code points to Java SE 8uX > > Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.00/ > > These code changes are made possible thanks to specification changes already pushed: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7 > > Regards, > Deepak > > > > > > From andy.herrick at oracle.com Tue Feb 19 15:59:08 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 19 Feb 2019 10:59:08 -0500 Subject: RFR: JDK-8217798: modular jar linking in jpackage Message-ID: JDK-8217798: modular jar linking in jpackage Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8217798 [2] http://cr.openjdk.java.net/~herrick/8217798/ /Andy Herrick From brian.goetz at oracle.com Tue Feb 19 16:01:26 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 19 Feb 2019 11:01:26 -0500 Subject: RFE: add missing methods to Optional, OptionalInt, OptionalLong and OptionalDouble In-Reply-To: <21c52039-aa2c-a625-a855-4012bbb1766f@icemanx.nl> References: <21c52039-aa2c-a625-a855-4012bbb1766f@icemanx.nl> Message-ID: <58cba64a-2af3-b3cc-9f89-399263714ddc@oracle.com> This is a very nice patch, complete with spec and tests, and evidence of OCA. But, before we talk about patches and code, let's step back and talk about stewardship.? With API proposals, we like to start with problems, rather than solutions: what problems we are concerned with, and are these are problems that need to be solved in the JDK?? Assuming we like the answers to the former, we can then move on to whether the proposed solution is the right one, and then to details like spec and code review. We are currently trying to avoid adding anything to OptionalInt/Long/Double, because our current plan is to replace these with a specialized Optional once Valhalla delivers.? Any methods that differ from the base type (Optional) creates potential roadblocks to such a migration, so we'd prefer to leaves these classes be. To the main question, though, whether Optional should have specialized map and flatMap methods ... I'm skeptical.? The goal was never to create parity between Optional and Stream, and my gut reaction is that the return on additional API surface area here is negative.? But, we can surely have a discussion on this. On 2/16/2019 7:52 AM, Rob Spoor wrote: > I noticed that, while Stream and its primitive equivalents have > multiple map and flapMap methods, Optional and its primitive > equivalents were missing those. Since these can still be very useful, > I wrote a patch to add the following methods: > > * Optional: mapToInt, mapToLong, mapToDouble, flatMapToInt, > flatMapToLong, flatMapToDouble > * OptionalInt: map, mapToObj, mapToLong, mapToDouble, flatMap > * OptionalLong: map, mapToObj, mapToInt, mapToDouble, flatMap > * OptionalDouble: map, mapToObj, mapToInt, mapToLong, flatMap > > I did not add any more flatMap methods to OptionalInt, OptionalLong > and OptionalDouble because these also don't exist on IntStream, > LongStream and DoubleStream. > > > In addition, I also added the missing or method to OptionalInt, > OptionalLong and OptionalDouble based on that of Optional. > > > My OCA has been processed on 2019-01-22. > > > Rob From goetz.lindenmaier at sap.com Tue Feb 19 16:08:07 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Feb 2019 16:08:07 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> Message-ID: Hi, I have been looking at how to implement this in Java using StackWalker and ASM. Either I oversee something or there is a row of deficiencies with these tools to solve my issue. StackWalker allows me to collect class name, method name, method description and BCI. Given the current implementation, this must happen in the NPE constructor which is very inefficient, but works. Mandy, should I really change Throwable/StackWalker to overcome this? Alternatively, I could JNI-call into the VM and get the info when I need it. ASM allows me to access the class and the bytecode of the method. Unfortunately, ASM has no notion of BCI. It also does not externally expose the bytecodes of the methods. It simplifies the bytecodes, which is useful to manipulate them, but does not allow me to recompute the BCI of instructions, say, iterating the InsnList. Further, as I understand, the bytecode I can access in ASM is the bytecode as it resides in the class file, not the bytecode used by hotspot (bitwise). Hotspot rewrites bytecodes when it loads them. And the BCI returned by StackWalker corresponds to the bytecode used by hotspot, not that in the class file. If a method has been rewritten, there even might be several instances of the same method/bytecode, the old still needed for running executions and the new, rewritten one. The BCI is only correct for one of these. So I don't see how I should find the ASM representation of the bytecode that caused the NPE. Do you have any advice? Best regards, Goetz. > -----Original Message----- > From: Peter Levart > Sent: Freitag, 15. Februar 2019 18:38 > To: Lindenmaier, Goetz ; Roger Riggs > ; Java Core Libs > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > Hi Goetz, > > Just a couple of things if you go that route (of placeholder String): > > > ? 56???? private static final String MESSAGE_PLACEHOLDER = > "NPE_MESSAGE_PLACEHOLDER"; > > Here, the initializer of that constant should create a private instance > of String: > > ??? private static final String MESSAGE_PLACEHOLDER = new > String("NPE_MESSAGE_PLACEHOLDER"); > > or even (since the content of the placeholder string doesn't matter - > the identity does): > > ??? private static final String MESSAGE_PLACEHOLDER = new String(); > > ...or else anybody calling new > NullPointerException("NPE_MESSAGE_PLACEHOLDER") will also be the subject > of replacement since the string literals are interned constants. I.e.: > > "NPE_MESSAGE_PLACEHOLDER" == "NPE_MESSAGE_PLACEHOLDER" > > > ? 81???? public String getMessage() { > ? 82???????? String message = super.getMessage(); > ? 83???????? if (message == MESSAGE_PLACEHOLDER) { > ? 84???????????? message = getExtendedNPEMessage(); > ? 85???????????? setMessage(message); > ? 86???????? } > ? 87???????? return super.getMessage(); > ? 88???? } > > Why not simply returning 'message' local variable here? > > > Regards, Peter > > On 2/14/19 5:35 PM, Lindenmaier, Goetz wrote: > > Hi Roger, > > > >> Maybe 10 years ago, when native was the only solution. > >> Now there are tools to analyze bytecode in java. > > I'm working on a Java implementation. > > > >>> Peter Levart proposed to initialize the message with a sentinel instead. > >>> I'll implement this as a proposal. > >> That's an extra overhead too, any assignment is. > > Yes, any code requires some run time. But I think this really is negligible > > in comparison to generating the backtrace, which happens on every > > exception. But I'm fine with the 'always recompute, no serialization' > > solution. If it turns out to be limited, it still can be changed easily. > > > >>> I guess we can go without. > >>> It would be possible to construct a case where two threads > >>> do getMessage() on the same NPE Object but the string is not > >>> the same. > >> Really!, if the bci is the same, the bytecode is the same, what could be > different > >> that would change the data used to create the exception? > > e.getMessage().equals(e.getMessage()) will hold, but > > e.getMessage() != e.getMessage(). > > > > I just implemented the two variants of computing the message, they > > basically differ in NullPointerException.java: > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/03- > PeterLevart/ > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/04- > RogerRiggs/ > > > > I also cleaned up the parameters passed as proposed. > > > >>> We uses this code since 2006, it needed only few changes. I would like to > >>> contribute a follow up for hidden frames of lambdas. > >> Valhalla and evolution of the byte code needs to be considered. > >> Just because its worked for years does not mean it's the best approach > >> today. Dropping it in now means maintaining it in its current form > >> or needing to re-write it later. > > Well, yes, that is true. For any change. For any project. We have heard > > this argument for many of our changes. I don't really think it's a good > > argument. As I understand Valhalla is not targeted for jdk13, and > > holding up changes for some future projects not really is the process > > of OpenJDK, is it? > > > >>>> The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a > >>>> question > >>>> about how useful the information is, developers should not need to know > >>>> about "slot 1". > >>> Developers should work with class files with debug information and then > >>> they would get the name printed. If exceptions are thrown in production > >>> code, any information is helpful. Should I just write "a local"? > >> Go back to who you think is going to benefit from it, it seems targeted > >> at a fairly novice developer, so exposing low level details may be more > >> confusing that just giving a line number and NPE. > > Especially on our improved NPE messages we always got good feedback > > from the developers within SAP. And there are quite some experienced > > people. Any message requires some background to be helpful. And I > > like to get any information I can have in first place. Attaching the > > debugger often is a big overhead. E.g., I look at about 50 failing jtreg > > tests every day, I don't want to get each into the debugger every time > > in the setup where it was running to see what is wrong ... > > > > E.g., com/sun/java/swing/plaf/windows/AltFocusIssueTest.java > > is failing in a headless environment with an NPE on this line: > > SwingUtilities.invokeAndWait(() -> frame.dispose()); > > With this change it said "while trying to invoke the method > javax.swing.JFrame.dispose(()V) of a null object loaded from static field > AltFocusIssueTest.frame" and I figured it's the fact we run headless that > > makes the test fail without even looking at the code. > > > > Best regards, > > Goetz > > > > > > > > > > > > > > > > > > From: Roger Riggs > > Sent: Dienstag, 12. Februar 2019 17:03 > > To: Lindenmaier, Goetz ; Java Core Libs libs-dev at openjdk.java.net> > > Cc: hotspot-runtime-dev at openjdk.java.net > > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > > > Hi, > > On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote: > > Hi Roger, > > > > thanks for looking at my change! > > > > A few higher level issues should be considered, though the details of > > the webrev captured my immediate attention. > > > > Is this the right feature > > Yes!! > > Maybe, that's what debuggers are for. > > > > > > > > and is this the right level of implementation (C++/native)? > > See below. > > Maybe 10 years ago, when native was the only solution. > > Now there are tools to analyze bytecode in java. > > > > > > > > From a security perspective, adding field names to exceptions exposes > > information to callers that they could not otherwise get and that breaks > > encapsulation. > > That needs to be evaluated. > > I can not comment on that. How can I trigger an evaluation of this? > > Who needs to evaluate this? > > > > I think there are ways to make this easier to implement and be easier to > > maintain and perform better. > > > > NullPointerException: > > 28: unused import of Field > > Removed > > > > 64: The lazyComputeMessage boolean should be inverted so it does not > > require > > ?? initialization, false is the default, anything else adds overhead. > > ?? And it may not be needed. > > Peter Levart proposed to initialize the message with a sentinel instead. > > I'll implement this as a proposal. > > That's an extra overhead too, any assignment is. > > > > > > > > 91: Why do you think synchonization is necessary?? It is a performance hit. > > ?? It is highly unlikely to be called from multiple threads and the > > value will > > ?? be the same whether it is computed once or multiple times by > > different threads. > > I guess we can go without. > > It would be possible to construct a case where two threads > > do getMessage() on the same NPE Object but the string is not > > the same. > > Really!, if the bci is the same, the bytecode is the same, what could be > different > > that would change the data used to create the exception? > > > > > > > > 99: extendedMessage will never be null (so says the javadoc of > > getExtendedNPEMessage) > > ? Bug: If it does return null, then null is returned from getMessage > > ? regardless of the value of super.getMessage(). > > Fixed. > > > > 121: Simplify getExtendedNPEMessage by making it only responsible for > > the detail > > ? and not concatenation with an existing message.? Put that in > > getMessage(). > > Fixed. You are right, I only call this when the message is NULL. > > > > ? Its not strictly necessary to change the updated message with > > setMessage(). > > ? Avoiding that will avoid complexity and a performance hit. > > ? The message will be computed each time it is needed, and that happens > > infrequently. > > ? (Even in the serialization case, it will be re-computed from the > > attached stack frames). > > No, you can not recompute it from the stacktrace because that > > does not contain the BCI. Also, after deserialization, the bytecode > > might look different or not available at all. It depends on the actual > > bytecode that has been running when the exception was thrown. > > Right, I realized this too when thinking about it over the weekend. > > > > If a suitable low impact mechanism can't be found, then just > > go back to not exposing the extended message and use only the original. > > Its a bad idea to twist and contort the local design and accessibility > > just for serialization. What remote or delayed client needs to know this? > > > > > > > > > > ? And it avoids adding setMessage() to Throwable, that's significant > > change since > > ? the current implementation only allows the message to be initialized > > not updated. > > ? Immutable is an important characteristic to maintain. > > Yes, I don't like I have to set this. But it follows the same pattern > > as with the stack trace which is only computed on demand. Thus, > > Throwable is not immutable anyways. Before, I implemented this by a > > JNI call hiding this in the Java code. > > I proposed implementing setting the field by reflection, Christoph > > proposed a shared secret. David favored the package private setter. > > Please advice what is best. > > All of them are bad. Private needs to mean private. > > > > And making it mutable, also means that synchronization or volatile > > is needed to ensure a consistent value for getMessage(). > > That turns into a performance issue for all throwables. > > None of the above. > > > > > > > > That makes the writeReplace() unnecessary too. > > No. I need this, see above. > > See above, but is not essential to the core feature. > > > > > > > > Additional command line arguments are an unnecessary complexity, > > documentation, and maintenance overhead.? If the feature is as valuable as > > you suggest, it should be enabled all the time. > > Removed. > > > > I'm assuming there are no tests broken by the modification of the message. > > It is likely that somewhere an application or test looks at the message > > itself. > > Has that been verified? > > Our nightly testing runs the headless jdk and hostspot jtreg tests, jck tests > and some > > other applications. They are all unaffected by this change after adapting the > > message in jtreg/vmTestbase/jit/t/t104/t104.gold. > > (win-x86_64, linux: ppc64, ppc64le, s390, x86_64, aarch, aix, solaris-sparc, > mac) > > Also, I modified quite some messages before which didn't cause any follow- > up > > breakages to my knowledge. > > It does seem unlikely. > > > > > > > > I can't speak for the hotspot code, but that seems to add a lot of code > > to support > > only this convenience feature.? That's a maintenance overhead and burden. > > We uses this code since 2006, it needed only few changes. I would like to > > contribute a follow up for hidden frames of lambdas. > > Valhalla and evolution of the byte code needs to be considered. > > Just because its worked for years does not mean its the best approach > > today.? Dropping it in now means maintaining it in its current form > > or needing to re-write it later. > > > > > > > > The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a > > question > > about how useful the information is,? developers should not need to know > > about "slot 1". > > Developers should work with class files with debug information and then > > they would get the name printed. If exceptions are thrown in production > > code, any information is helpful. Should I just write "a local"? > > Go back to who you think is going to benefit from it, it seems targeted > > at a fairly novice developer, so exposing low level details may be more > > confusing that just giving a line number and NPE. > > > > > > > > The test output of NullPointerExceptionTest shows > > "java.lang.Object.hashCode(()I)". > > Why is the argument type for Integer shown as "()I";? that's not the > > conventional > > representation of a primitive int. > > I already discussed this with David Holmes: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019- > February/058464.html > > Other exceptions use the same format. I don't know of an utility in > > hotspot to translate the format to Java source code syntax. We > > implemented such an utility in our internal VM, though, and I would > > like to contribute this, too, adapting all the exceptions. I would do this > > in a follow-up. > > There may be better tools for formatting if it was done in java at a > > more appropriate level of abstraction. > > > > > > > > Generally, the explanations are too verbose. > > Method names and field names would be easier to recognize if they were > > quoted, as is done with 'this'. > > Fixed, although this is not common in exception messages. See the > > messages in > http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runt > ime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, > > line 57ff. Only the String of the name field is quoted, not any entities > > declared in the code. > > Similar > http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runt > ime/LoaderConstraints/vtableAME/Test.java > > line 60, also showing the internal signature, see above. > > > > Argument numbers should be digits, > > not English words (first, second, etc) to make them easier to pick out. > > Fixed. > > And has it limits that do not read easily, e.g. "nr. 9". > > Sorry, I don't understand > > src/hotspot/share/classfile/bytecodeUtils.cpp:566 > > > test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerE > xceptionTest.java:612 > > > > I would not describe 'this' as a local variable. > > Fixed. > > > > Tests, especially new tests should compile without warnings. > > NullPointerExceptionTest.java:125 newInstance has been deprecated. > > Fixed. > > > > The messages can be easier to understand, e.g. > > 'field a1 is null, trying to invoke a1.hashCode...' instead of: > > "while trying to invoke the method java.lang.Object.hashCode(()I) on a > > null reference loaded from local variable 'a1'" > > The message is built along the structure of the bytecode. > > I'll try to change this and then will come up with a new webrev . > > > > It will easier to understand if it looks more like the code. > > BTW, what does this look like for fully optimized code? > > You mean whether the bytecode is jitted? It's independent > > of how the code is executed, interpreted or compiled. > > > > Does it bear any resemblance to the source code at all? > > Or does it have to be deoptimized to come up with a sensible source > > reference. > > No, jitted methods must not be deoptimized. > > > > How much of this can be done in Java code with StackWalker and other > > java APIs? > > It would be a shame to add this much native code if there was a more robust > > way to implement it using APIs with more leverage. > > StackWalker operates on the Java stack tracke, which does not contain the > BCI > > to my knowledge. Also, I need to read the bytecodes. Are there APIs to > access > > the bytecode as it resides in the metaspace, rewritten, constants resolved > etc? > > The code relies on this. > > > > From the other thread, beware adding overhead to the constructor. > > The lazy computation is essential. > > There are a *lot* of NPEs whose messages will never be needed. > > > > Regards, Roger > > > > > > > > > > Best regards, > > Goetz. > > > > > > > > Regards, Roger > > > > > > On 02/08/2019 09:13 AM, Langer, Christoph wrote: > > Hi Goetz, > > > > ok, so here a new webrev just adding a setter for the field: > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 > > > > ... and incorporating the other comments. > > Looks better ?? > > > > I have a few additions to > > src/java.base/share/classes/java/lang/NullPointerException.java: > > > > 28 import java.lang.reflect.Field; > > 29 > > -> can be removed now. > > > > 91 synchronized (this) { > > -> I think this is not needed here. The transient modifier for > > lazyComputeMessage already implies the lock on the Object, I think. > > > > 108 return extendedMessage; > > -> I guess it would be more correct if you returned super.getMessage() here. > > > > Thanks > > Christoph > > > > From andrew_m_leonard at uk.ibm.com Tue Feb 19 16:24:51 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 19 Feb 2019 16:24:51 +0000 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized Message-ID: Please can I request a sponsor for this fix to ReflectionFactory where langReflectAccess is not always correctly initialized. Webrev: http://cr.openjdk.java.net/~aleonard/8219378/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8219378 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 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 Roger.Riggs at oracle.com Tue Feb 19 16:49:18 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 19 Feb 2019 11:49:18 -0500 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> Message-ID: <661ca8a0-8761-83b8-9532-2e3deafbfbba@oracle.com> Hi Alexander, Some files appear to be moved with hg, but others are copied and deleted. Please use hg mv to retain the continuity of the history. Thanks, Roger On 02/15/2019 10:03 PM, Alexander Matveev wrote: > Hi Magnus, > > http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ > > Moved all files from "posix" to "unix" folder and reverted > Lib-jdk.jpackage.gmk changes. > Webrev updated with files moved, instead of add/remove. > > Thanks, > Alexander > > On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: >> >> >> On 2019-02-15 04:31, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - Moved native code under platform specific folder. >>> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. >>> - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp >>> for Mac specific code to filter out some arguments. I decided to >>> keep it as is for now, since Mac specific code is small. >>> - Defines are used in Platform.cpp to initialize platform specific >>> classes. >>> - Removed all pragma warning and fixed all compilation warnings. >>> - Removed unused code. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8212091 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ >> The JDK standard is to use "unix", not "posix", for the shared >> functionality between linux/solaris/macosx. You can keep the name >> "PosixPlatform.*" if you want, though; the important thing is the >> directory name. >> >> Also, if you do that, you do not need any changes to >> make/lib/Lib-jdk.jpackage.gmk, since that will be automatically >> understood by the build system. >> >> It looks from the webrev that you have "moved" the files by doing "hg >> add" and "hg remove". Please use "hg move" instead -- this will keep >> history intact, and it allows reviewers to see if you have also made >> changes to the moved files. >> >> (If you do have modified the moved file, reverting a "hg add+hg >> remove" process is a bit more tricky -- you need to do "hg forget" on >> the new file, rename it to something else (otherwise "hg move" will >> complain), "hg revert" the old file back in place, do a "hg move" >> from the old to the new, and then copy the modified, renamed file >> back over the target new file again.) >> >> /Magnus >>> >>> Thanks, >>> Alexander >> > From Alan.Bateman at oracle.com Tue Feb 19 16:55:13 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2019 16:55:13 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <3523d889-bd96-9709-ce7e-7a9fabf42de3@redhat.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> <3523d889-bd96-9709-ce7e-7a9fabf42de3@redhat.com> Message-ID: <2536d665-0eb7-f4c3-9bd9-248d42514640@oracle.com> On 18/02/2019 11:15, Andrew Dinn wrote: > : > Alan, I'll wait for your follow-up note before responding regarding the > arguments to force. I'll just note that the latest JEP draft accepts > start position and length [i.e. force(from, length)] rather than start > position and end position [i.e. force(from, to)]. I thought this would > be easier for clients to get right -- less danger of out by one errors. > The issues with the 2-arg force method that I think need discussion are: 1. long from/to vs. from/length vs int index/length. Elements in buffers, or the starting index of a region, are addressed by an int index in the existing API. We are currently discussing absolute bulk get/put methods on nio-dev right now and the methods on the table use "int length", this is mostly because they are about bulk copying in/out of byte arrays where offet+length is the norm. 2. limit vs. capacity. If I read the webrev correctly, it checks the upper bound against the buffer capacity. I don't think we have any existing methods where you can specify an index that is >= limit. 3. The javadoc doesn't specify the exception thrown when the bounds checks fail. In the webrev I see that IAE is thrown but the existing buffer methods specify IIOBE. If you agree then it means you can replace the checks with one method: ?? Objects.checkFromIndexSize(index, length, limit()); I think that's it. -Alan From naoto.sato at oracle.com Tue Feb 19 16:53:28 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 19 Feb 2019 08:53:28 -0800 Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 In-Reply-To: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> Message-ID: Hi Deepak, Here are my comments to the webrev (other than what Sean pointed out): TestIsJavaIdentifierMethods.java - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit". - Line 34: "newCodePoint" does not represent the era character, as "new" is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"? - Line 67,68,(...all the comments): Reflect the above change to the comments. - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct. It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions. - Line 104: The test case returns "void", what does this "Expected results" mean? - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int): isLetter(codePoint) returns true getType(codePoint) returns LETTER_NUMBER the referenced character is a currency symbol (such as '$') the referenced character is a connecting punctuation character (such as '_'). - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). Naoto On 2/19/19 6:15 AM, Deepak Kejriwal wrote: > Correcting typo for release. > > > > From: Deepak Kejriwal > Sent: Tuesday, February 19, 2019 7:42 PM > To: 'core-libs-dev' ; 'jdk-updates-dev at openjdk.java.net' > Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 > > > > Hi All, > > Please review the backport of the following bug fixes to jdk11u-dev: > > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points > > Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ > > These code changes are made possible thanks to specification change already pushed: > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace > > Regards, > Deepak > > > From naoto.sato at oracle.com Tue Feb 19 17:10:14 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 19 Feb 2019 09:10:14 -0800 Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 In-Reply-To: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default> References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default> Message-ID: <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com> Hi Deepak, Almost all the comments for the 11u changes [1] applies here, except the "newCodePoint" comment. For this one, I'd suggest renaming "newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2" Naoto [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058610.html On 2/19/19 5:55 AM, Deepak Kejriwal wrote: > Hi All, > > Please review the backport of the following bug fixes to jdk8u-dev: > > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation. > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters. > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong short form text for supplemental Japanese era > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 currency code points to Java SE 8uX > > Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.00/ > > These code changes are made possible thanks to specification changes already pushed: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7 > > Regards, > Deepak > > > > > > > From naoto.sato at oracle.com Tue Feb 19 17:21:00 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 19 Feb 2019 09:21:00 -0800 Subject: [13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO In-Reply-To: References: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> Message-ID: <82b5aa63-75e6-3a01-7f53-fd4dc389676d@oracle.com> Hi Nishit, The reason is that "US" is the only required locale in the JDK (cf. Locale.getAvailableLocales(). In fact, initially I supplied "001" with it, as it means the "world" in CLDR, but it broke some existing tests. "001" returns "MONDAY" as the first day of week, whereas "SUNDAY" in US. For the compatibility reason, I had to resort to "US". I am not sure we want to hardcode "1" in this case without any convincing reason. Naoto On 2/19/19 6:37 AM, Nishit Jain wrote: > Hi Naoto, > > Why is the default region set to "US" if there is no region specified in > the locale? is this the default behavior of "first day of week" and > "minimal days in first week" when a region is missing or the default > behavior is that it returns "1"? Can't we just return "1" instead of > setting the region to "US"? > > Regards, > Nishit Jain > On 16-02-2019 04:25, Naoto Sato wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8218960 >> >> The proposed changeset is located at: >> >> http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ >> >> The CONFIG message was generated because CLDRCalendarDataProviderImpl >> was returning null for locales without region. Use "US" as the default >> region in such a case. >> >> Naoto > From turbanoff at gmail.com Tue Feb 19 07:23:03 2019 From: turbanoff at gmail.com (Andrey Turbanov) Date: Tue, 19 Feb 2019 10:23:03 +0300 Subject: PATCH. JDK-4887513 Typo in RMIFailureHandler interface doc page In-Reply-To: References: Message-ID: >+ * {@code RMISocketFactory.setFailureHandler}. If no failure One redundant space before "If" Andrey Turbanov From adinn at redhat.com Tue Feb 19 18:01:12 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 19 Feb 2019 18:01:12 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <2536d665-0eb7-f4c3-9bd9-248d42514640@oracle.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> <3523d889-bd96-9709-ce7e-7a9fabf42de3@redhat.com> <2536d665-0eb7-f4c3-9bd9-248d42514640@oracle.com> Message-ID: <1876630e-265f-3639-274a-ef28b777964f@redhat.com> Hi Alan, Thanks for following this up. On 19/02/2019 16:55, Alan Bateman wrote: > The issues with the 2-arg force method that I think need discussion are: > > 1. long from/to vs. from/length vs int index/length. Elements in > buffers, or the starting index of a region, are addressed by an int > index in the existing API. We are currently discussing absolute bulk > get/put methods on nio-dev right now and the methods on the table use > "int length", this is mostly because they are about bulk copying in/out > of byte arrays where offet+length is the norm. I agree that the force method should take int arguments to align with other methods. Also, I think they should be offset+length for the same reason. I will modify the JEP and the next webrev accordingly. > 2. limit vs. capacity. If I read the webrev correctly, it checks the > upper bound against the buffer capacity. I don't think we have any > existing methods where you can specify an index that is >= limit. I agree that for consistency with other methods it would be better to check against limit(). I will modify the next webrev accordingly modulo resolution of one small detail. My reason for using capacity() was that I was swayed by the original implementation of force(). It calls force0(fd, mappingAddress(offset), mappingLength(offset)) where offset is long offset = mappingOffset(); The definition of mappingLength(offset) is private long mappingLength(long mappingOffset) { return (long)capacity() + mappingOffset; I'm wondering if this ought to remain as is or ought to change to specify limit()? > 3. The javadoc doesn't specify the exception thrown when the bounds > checks fail. In the webrev I see that IAE is thrown but the existing > buffer methods specify IIOBE. If you agree then it means you can replace > the checks with one method: > ?? Objects.checkFromIndexSize(index, length, limit()); It sounds like a very good idea to use that method and hence to throw IOOBE. I will modify the JEP and the next webrev accordingly. 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, Eric Shander From naoto.sato at oracle.com Tue Feb 19 18:02:50 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 19 Feb 2019 10:02:50 -0800 Subject: RFR(XS):JDK-8219228: java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test machine. In-Reply-To: <5cf41d0f-28c4-156d-cb9b-de84c68fb1b5@oracle.com> References: <3f54e68f-729d-864e-b12a-c81f21cd4dad@oracle.com> <5cf41d0f-28c4-156d-cb9b-de84c68fb1b5@oracle.com> Message-ID: +1 Naoto On 2/19/19 7:10 AM, Roger Riggs wrote: > Looks fine,? Reviewed. > > > On 02/19/2019 04:05 AM, Nishit Jain wrote: >> Hi Arno, >> >> Although I don't know if turning off or no swap is expected for a test >> environment, but tried reproducing the issue locally on a 8Gb Ubuntu >> linux VM with swap turned off, the test case was passing until I >> started some other app (like browser) in parallel, in which case it >> failed with error = "Not enough space". Since it is a memory intensive >> test, I think it is better and safe to increase "os.maxMemory" check >> >> Change looks good to me, I am not an openJDK reviewer though. >> >> Regards, >> Nishit Jain >> On 18-02-2019 18:19, Zeller, Arno wrote: >>> Hello! >>> >>> I found that the test >>> java/util/Base64/TestEncodingDecodingLength.java fails on a machine >>> with 8GB memory after JDK-8218265. >>> The test starts a VM with -Xmx8GB but the VM needs some more memory >>> than only the heap and on machines with just 8GB of memory (and no >>> swap configured) the test will always fail because the VM cannot get >>> enough native memory. >>> Therefore I suggest to increase "@requires os.maxMemory" to >= 10GB >>> to be safe. >>> >>> Could someone please review this minimal change? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219228 >>> >>> Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8219228/ >>> >>> Thanks and best regards, >>> Arno >>> >> > From alexander.matveev at oracle.com Tue Feb 19 20:11:10 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 19 Feb 2019 12:11:10 -0800 Subject: RFR: JDK-8217798: modular jar linking in jpackage In-Reply-To: References: Message-ID: <91ee3e59-9fd0-9c1c-ad9d-47746f473a2a@oracle.com> Hi Andy, Looks good. Thanks, Alexander On 2/19/2019 7:59 AM, Andy Herrick wrote: > JDK-8217798: modular jar linking in jpackage > > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > [1] https://bugs.openjdk.java.net/browse/JDK-8217798 > > [2] http://cr.openjdk.java.net/~herrick/8217798/ > > > /Andy Herrick > From kevin.rushforth at oracle.com Tue Feb 19 23:03:22 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Feb 2019 15:03:22 -0800 Subject: RFR: JDK-8217798: modular jar linking in jpackage In-Reply-To: <91ee3e59-9fd0-9c1c-ad9d-47746f473a2a@oracle.com> References: <91ee3e59-9fd0-9c1c-ad9d-47746f473a2a@oracle.com> Message-ID: Looks fine to me, too. Are you going to add any tests for this case? -- Kevin On 2/19/2019 12:11 PM, Alexander Matveev wrote: > Hi Andy, > > Looks good. > > Thanks, > Alexander > > On 2/19/2019 7:59 AM, Andy Herrick wrote: >> JDK-8217798: modular jar linking in jpackage >> >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217798 >> >> [2] http://cr.openjdk.java.net/~herrick/8217798/ >> >> >> /Andy Herrick >> > From mandy.chung at oracle.com Wed Feb 20 02:17:42 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Feb 2019 18:17:42 -0800 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> Message-ID: On 2/19/19 8:08 AM, Lindenmaier, Goetz wrote: > Hi, > > I have been looking at how to implement this in Java using > StackWalker and ASM. > Either I oversee something or there is a row of deficiencies with > these tools to solve my issue. > > StackWalker allows me to collect class name, method name, method > description and BCI. Given the current implementation, this must > happen in the NPE constructor which is very inefficient, but > works. Mandy, should I really change Throwable/StackWalker to > overcome this? Alternatively, I could JNI-call into the VM > and get the info when I need it. > One idea is to make a call to VM to fill StackFrameInfo array for the backtrace stored in NPE (that is in VM native representation) and then iterate StackFrameInfo and extract the code/local variable etc from the classfile per class/method and BCI for each frame. I don't think you have to modify Throwable/StackWalker API to do so but keep it implementation details. > ASM allows me to access the class and the bytecode of the method. > > Unfortunately, ASM has no notion of BCI. It also does not > externally expose the bytecodes of the methods. It simplifies > the bytecodes, which is useful to manipulate them, but does > not allow me to recompute the BCI of instructions, say, iterating > the InsnList. > > Further, as I understand, the bytecode I can access in ASM > is the bytecode as it resides in the class file, not the > bytecode used by hotspot (bitwise). Hotspot rewrites bytecodes when > it loads them. And the BCI returned by StackWalker corresponds > to the bytecode used by hotspot, not that in the class file. When the class file is redefined, it's reasonable to report the line number is not available. If you want to keep the previous versions of class byte, an instrumentation agent can do this work. > If a method has been rewritten, there even might be several > instances of the same method/bytecode, the old still needed for > running executions and the new, rewritten one. The BCI > is only correct for one of these. The old method would be GC'ed when it becomes unreachable, right? I expect you won't be able to reliably report the info when the method has been redefined. > So I don't see how I should find the ASM representation of > the bytecode that caused the NPE. Do you have any advice? Have you looked at the Code attribute? Mandy > Best regards, > Goetz. > > >> -----Original Message----- >> From: Peter Levart >> Sent: Freitag, 15. Februar 2019 18:38 >> To: Lindenmaier, Goetz ; Roger Riggs >> ; Java Core Libs >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException >> describing what is null. >> >> Hi Goetz, >> >> Just a couple of things if you go that route (of placeholder String): >> >> >> ? 56???? private static final String MESSAGE_PLACEHOLDER = >> "NPE_MESSAGE_PLACEHOLDER"; >> >> Here, the initializer of that constant should create a private instance >> of String: >> >> ??? private static final String MESSAGE_PLACEHOLDER = new >> String("NPE_MESSAGE_PLACEHOLDER"); >> >> or even (since the content of the placeholder string doesn't matter - >> the identity does): >> >> ??? private static final String MESSAGE_PLACEHOLDER = new String(); >> >> ...or else anybody calling new >> NullPointerException("NPE_MESSAGE_PLACEHOLDER") will also be the subject >> of replacement since the string literals are interned constants. I.e.: >> >> "NPE_MESSAGE_PLACEHOLDER" == "NPE_MESSAGE_PLACEHOLDER" >> >> >> ? 81???? public String getMessage() { >> ? 82???????? String message = super.getMessage(); >> ? 83???????? if (message == MESSAGE_PLACEHOLDER) { >> ? 84???????????? message = getExtendedNPEMessage(); >> ? 85???????????? setMessage(message); >> ? 86???????? } >> ? 87???????? return super.getMessage(); >> ? 88???? } >> >> Why not simply returning 'message' local variable here? >> >> >> Regards, Peter >> >> On 2/14/19 5:35 PM, Lindenmaier, Goetz wrote: >>> Hi Roger, >>> >>>> Maybe 10 years ago, when native was the only solution. >>>> Now there are tools to analyze bytecode in java. >>> I'm working on a Java implementation. >>> >>>>> Peter Levart proposed to initialize the message with a sentinel instead. >>>>> I'll implement this as a proposal. >>>> That's an extra overhead too, any assignment is. >>> Yes, any code requires some run time. But I think this really is negligible >>> in comparison to generating the backtrace, which happens on every >>> exception. But I'm fine with the 'always recompute, no serialization' >>> solution. If it turns out to be limited, it still can be changed easily. >>> >>>>> I guess we can go without. >>>>> It would be possible to construct a case where two threads >>>>> do getMessage() on the same NPE Object but the string is not >>>>> the same. >>>> Really!, if the bci is the same, the bytecode is the same, what could be >> different >>>> that would change the data used to create the exception? >>> e.getMessage().equals(e.getMessage()) will hold, but >>> e.getMessage() != e.getMessage(). >>> >>> I just implemented the two variants of computing the message, they >>> basically differ in NullPointerException.java: >>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/03- >> PeterLevart/ >>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/04- >> RogerRiggs/ >>> >>> I also cleaned up the parameters passed as proposed. >>> >>>>> We uses this code since 2006, it needed only few changes. I would like to >>>>> contribute a follow up for hidden frames of lambdas. >>>> Valhalla and evolution of the byte code needs to be considered. >>>> Just because its worked for years does not mean it's the best approach >>>> today. Dropping it in now means maintaining it in its current form >>>> or needing to re-write it later. >>> Well, yes, that is true. For any change. For any project. We have heard >>> this argument for many of our changes. I don't really think it's a good >>> argument. As I understand Valhalla is not targeted for jdk13, and >>> holding up changes for some future projects not really is the process >>> of OpenJDK, is it? >>> >>>>>> The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a >>>>>> question >>>>>> about how useful the information is, developers should not need to know >>>>>> about "slot 1". >>>>> Developers should work with class files with debug information and then >>>>> they would get the name printed. If exceptions are thrown in production >>>>> code, any information is helpful. Should I just write "a local"? >>>> Go back to who you think is going to benefit from it, it seems targeted >>>> at a fairly novice developer, so exposing low level details may be more >>>> confusing that just giving a line number and NPE. >>> Especially on our improved NPE messages we always got good feedback >>> from the developers within SAP. And there are quite some experienced >>> people. Any message requires some background to be helpful. And I >>> like to get any information I can have in first place. Attaching the >>> debugger often is a big overhead. E.g., I look at about 50 failing jtreg >>> tests every day, I don't want to get each into the debugger every time >>> in the setup where it was running to see what is wrong ... >>> >>> E.g., com/sun/java/swing/plaf/windows/AltFocusIssueTest.java >>> is failing in a headless environment with an NPE on this line: >>> SwingUtilities.invokeAndWait(() -> frame.dispose()); >>> With this change it said "while trying to invoke the method >> javax.swing.JFrame.dispose(()V) of a null object loaded from static field >> AltFocusIssueTest.frame" and I figured it's the fact we run headless that >>> makes the test fail without even looking at the code. >>> >>> Best regards, >>> Goetz >>> >>> >>> >>> >>> >>> >>> >>> >>> From: Roger Riggs >>> Sent: Dienstag, 12. Februar 2019 17:03 >>> To: Lindenmaier, Goetz ; Java Core Libs > libs-dev at openjdk.java.net> >>> Cc: hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException >> describing what is null. >>> >>> Hi, >>> On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote: >>> Hi Roger, >>> >>> thanks for looking at my change! >>> >>> A few higher level issues should be considered, though the details of >>> the webrev captured my immediate attention. >>> >>> Is this the right feature >>> Yes!! >>> Maybe, that's what debuggers are for. >>> >>> >>> >>> and is this the right level of implementation (C++/native)? >>> See below. >>> Maybe 10 years ago, when native was the only solution. >>> Now there are tools to analyze bytecode in java. >>> >>> >>> >>> From a security perspective, adding field names to exceptions exposes >>> information to callers that they could not otherwise get and that breaks >>> encapsulation. >>> That needs to be evaluated. >>> I can not comment on that. How can I trigger an evaluation of this? >>> Who needs to evaluate this? >>> >>> I think there are ways to make this easier to implement and be easier to >>> maintain and perform better. >>> >>> NullPointerException: >>> 28: unused import of Field >>> Removed >>> >>> 64: The lazyComputeMessage boolean should be inverted so it does not >>> require >>> ?? initialization, false is the default, anything else adds overhead. >>> ?? And it may not be needed. >>> Peter Levart proposed to initialize the message with a sentinel instead. >>> I'll implement this as a proposal. >>> That's an extra overhead too, any assignment is. >>> >>> >>> >>> 91: Why do you think synchonization is necessary?? It is a performance hit. >>> ?? It is highly unlikely to be called from multiple threads and the >>> value will >>> ?? be the same whether it is computed once or multiple times by >>> different threads. >>> I guess we can go without. >>> It would be possible to construct a case where two threads >>> do getMessage() on the same NPE Object but the string is not >>> the same. >>> Really!, if the bci is the same, the bytecode is the same, what could be >> different >>> that would change the data used to create the exception? >>> >>> >>> >>> 99: extendedMessage will never be null (so says the javadoc of >>> getExtendedNPEMessage) >>> ? Bug: If it does return null, then null is returned from getMessage >>> ? regardless of the value of super.getMessage(). >>> Fixed. >>> >>> 121: Simplify getExtendedNPEMessage by making it only responsible for >>> the detail >>> ? and not concatenation with an existing message.? Put that in >>> getMessage(). >>> Fixed. You are right, I only call this when the message is NULL. >>> >>> ? Its not strictly necessary to change the updated message with >>> setMessage(). >>> ? Avoiding that will avoid complexity and a performance hit. >>> ? The message will be computed each time it is needed, and that happens >>> infrequently. >>> ? (Even in the serialization case, it will be re-computed from the >>> attached stack frames). >>> No, you can not recompute it from the stacktrace because that >>> does not contain the BCI. Also, after deserialization, the bytecode >>> might look different or not available at all. It depends on the actual >>> bytecode that has been running when the exception was thrown. >>> Right, I realized this too when thinking about it over the weekend. >>> >>> If a suitable low impact mechanism can't be found, then just >>> go back to not exposing the extended message and use only the original. >>> Its a bad idea to twist and contort the local design and accessibility >>> just for serialization. What remote or delayed client needs to know this? >>> >>> >>> >>> >>> ? And it avoids adding setMessage() to Throwable, that's significant >>> change since >>> ? the current implementation only allows the message to be initialized >>> not updated. >>> ? Immutable is an important characteristic to maintain. >>> Yes, I don't like I have to set this. But it follows the same pattern >>> as with the stack trace which is only computed on demand. Thus, >>> Throwable is not immutable anyways. Before, I implemented this by a >>> JNI call hiding this in the Java code. >>> I proposed implementing setting the field by reflection, Christoph >>> proposed a shared secret. David favored the package private setter. >>> Please advice what is best. >>> All of them are bad. Private needs to mean private. >>> >>> And making it mutable, also means that synchronization or volatile >>> is needed to ensure a consistent value for getMessage(). >>> That turns into a performance issue for all throwables. >>> None of the above. >>> >>> >>> >>> That makes the writeReplace() unnecessary too. >>> No. I need this, see above. >>> See above, but is not essential to the core feature. >>> >>> >>> >>> Additional command line arguments are an unnecessary complexity, >>> documentation, and maintenance overhead.? If the feature is as valuable as >>> you suggest, it should be enabled all the time. >>> Removed. >>> >>> I'm assuming there are no tests broken by the modification of the message. >>> It is likely that somewhere an application or test looks at the message >>> itself. >>> Has that been verified? >>> Our nightly testing runs the headless jdk and hostspot jtreg tests, jck tests >> and some >>> other applications. They are all unaffected by this change after adapting the >>> message in jtreg/vmTestbase/jit/t/t104/t104.gold. >>> (win-x86_64, linux: ppc64, ppc64le, s390, x86_64, aarch, aix, solaris-sparc, >> mac) >>> Also, I modified quite some messages before which didn't cause any follow- >> up >>> breakages to my knowledge. >>> It does seem unlikely. >>> >>> >>> >>> I can't speak for the hotspot code, but that seems to add a lot of code >>> to support >>> only this convenience feature.? That's a maintenance overhead and burden. >>> We uses this code since 2006, it needed only few changes. I would like to >>> contribute a follow up for hidden frames of lambdas. >>> Valhalla and evolution of the byte code needs to be considered. >>> Just because its worked for years does not mean its the best approach >>> today.? Dropping it in now means maintaining it in its current form >>> or needing to re-write it later. >>> >>> >>> >>> The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a >>> question >>> about how useful the information is,? developers should not need to know >>> about "slot 1". >>> Developers should work with class files with debug information and then >>> they would get the name printed. If exceptions are thrown in production >>> code, any information is helpful. Should I just write "a local"? >>> Go back to who you think is going to benefit from it, it seems targeted >>> at a fairly novice developer, so exposing low level details may be more >>> confusing that just giving a line number and NPE. >>> >>> >>> >>> The test output of NullPointerExceptionTest shows >>> "java.lang.Object.hashCode(()I)". >>> Why is the argument type for Integer shown as "()I";? that's not the >>> conventional >>> representation of a primitive int. >>> I already discussed this with David Holmes: >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019- >> February/058464.html >>> Other exceptions use the same format. I don't know of an utility in >>> hotspot to translate the format to Java source code syntax. We >>> implemented such an utility in our internal VM, though, and I would >>> like to contribute this, too, adapting all the exceptions. I would do this >>> in a follow-up. >>> There may be better tools for formatting if it was done in java at a >>> more appropriate level of abstraction. >>> >>> >>> >>> Generally, the explanations are too verbose. >>> Method names and field names would be easier to recognize if they were >>> quoted, as is done with 'this'. >>> Fixed, although this is not common in exception messages. See the >>> messages in >> http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runt >> ime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, >>> line 57ff. Only the String of the name field is quoted, not any entities >>> declared in the code. >>> Similar >> http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runt >> ime/LoaderConstraints/vtableAME/Test.java >>> line 60, also showing the internal signature, see above. >>> >>> Argument numbers should be digits, >>> not English words (first, second, etc) to make them easier to pick out. >>> Fixed. >>> And has it limits that do not read easily, e.g. "nr. 9". >>> Sorry, I don't understand >>> src/hotspot/share/classfile/bytecodeUtils.cpp:566 >>> >> test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerE >> xceptionTest.java:612 >>> >>> I would not describe 'this' as a local variable. >>> Fixed. >>> >>> Tests, especially new tests should compile without warnings. >>> NullPointerExceptionTest.java:125 newInstance has been deprecated. >>> Fixed. >>> >>> The messages can be easier to understand, e.g. >>> 'field a1 is null, trying to invoke a1.hashCode...' instead of: >>> "while trying to invoke the method java.lang.Object.hashCode(()I) on a >>> null reference loaded from local variable 'a1'" >>> The message is built along the structure of the bytecode. >>> I'll try to change this and then will come up with a new webrev . >>> >>> It will easier to understand if it looks more like the code. >>> BTW, what does this look like for fully optimized code? >>> You mean whether the bytecode is jitted? It's independent >>> of how the code is executed, interpreted or compiled. >>> >>> Does it bear any resemblance to the source code at all? >>> Or does it have to be deoptimized to come up with a sensible source >>> reference. >>> No, jitted methods must not be deoptimized. >>> >>> How much of this can be done in Java code with StackWalker and other >>> java APIs? >>> It would be a shame to add this much native code if there was a more robust >>> way to implement it using APIs with more leverage. >>> StackWalker operates on the Java stack tracke, which does not contain the >> BCI >>> to my knowledge. Also, I need to read the bytecodes. Are there APIs to >> access >>> the bytecode as it resides in the metaspace, rewritten, constants resolved >> etc? >>> The code relies on this. >>> >>> From the other thread, beware adding overhead to the constructor. >>> The lazy computation is essential. >>> There are a *lot* of NPEs whose messages will never be needed. >>> >>> Regards, Roger >>> >>> >>> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> Regards, Roger >>> >>> >>> On 02/08/2019 09:13 AM, Langer, Christoph wrote: >>> Hi Goetz, >>> >>> ok, so here a new webrev just adding a setter for the field: >>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 >>> >>> ... and incorporating the other comments. >>> Looks better ?? >>> >>> I have a few additions to >>> src/java.base/share/classes/java/lang/NullPointerException.java: >>> >>> 28 import java.lang.reflect.Field; >>> 29 >>> -> can be removed now. >>> >>> 91 synchronized (this) { >>> -> I think this is not needed here. The transient modifier for >>> lazyComputeMessage already implies the lock on the Object, I think. >>> >>> 108 return extendedMessage; >>> -> I guess it would be more correct if you returned super.getMessage() here. >>> >>> Thanks >>> Christoph >>> >>> > From alexander.matveev at oracle.com Wed Feb 20 03:44:52 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 19 Feb 2019 19:44:52 -0800 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: <661ca8a0-8761-83b8-9532-2e3deafbfbba@oracle.com> References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> <661ca8a0-8761-83b8-9532-2e3deafbfbba@oracle.com> Message-ID: Hi Roger, Some deleted files are actually deleted files, since I did code cleanup as well. Added files contain code from splitting original source files. This was needed to re-arrange code. Not sure how to log with hg file split. Also, we already moved files without keeping history, since we are not planing to keep history when moving jpackage from sandbox. Thanks, Alexander On 2/19/2019 8:49 AM, Roger Riggs wrote: > Hi Alexander, > > Some files appear to be moved with hg, but others are copied and deleted. > > Please use hg mv to retain the continuity of the history. > > Thanks, Roger > > On 02/15/2019 10:03 PM, Alexander Matveev wrote: >> Hi Magnus, >> >> http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ >> >> Moved all files from "posix" to "unix" folder and reverted >> Lib-jdk.jpackage.gmk changes. >> Webrev updated with files moved, instead of add/remove. >> >> Thanks, >> Alexander >> >> On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: >>> >>> >>> On 2019-02-15 04:31, Alexander Matveev wrote: >>>> Please review the jpackage fix for bug [1] at [2]. >>>> >>>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>>> repository (jpackage). >>>> >>>> - Moved native code under platform specific folder. >>>> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. >>>> - MAC define is still used in JavaVirtualMachine.cpp and >>>> Package.cpp for Mac specific code to filter out some arguments. I >>>> decided to keep it as is for now, since Mac specific code is small. >>>> - Defines are used in Platform.cpp to initialize platform specific >>>> classes. >>>> - Removed all pragma warning and fixed all compilation warnings. >>>> - Removed unused code. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212091 >>>> >>>> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ >>> The JDK standard is to use "unix", not "posix", for the shared >>> functionality between linux/solaris/macosx. You can keep the name >>> "PosixPlatform.*" if you want, though; the important thing is the >>> directory name. >>> >>> Also, if you do that, you do not need any changes to >>> make/lib/Lib-jdk.jpackage.gmk, since that will be automatically >>> understood by the build system. >>> >>> It looks from the webrev that you have "moved" the files by doing >>> "hg add" and "hg remove". Please use "hg move" instead -- this will >>> keep history intact, and it allows reviewers to see if you have also >>> made changes to the moved files. >>> >>> (If you do have modified the moved file, reverting a "hg add+hg >>> remove" process is a bit more tricky -- you need to do "hg forget" >>> on the new file, rename it to something else (otherwise "hg move" >>> will complain), "hg revert" the old file back in place, do a "hg >>> move" from the old to the new, and then copy the modified, renamed >>> file back over the target new file again.) >>> >>> /Magnus >>>> >>>> Thanks, >>>> Alexander >>> >> > From nishit.jain at oracle.com Wed Feb 20 08:33:14 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Wed, 20 Feb 2019 14:03:14 +0530 Subject: [13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO In-Reply-To: <82b5aa63-75e6-3a01-7f53-fd4dc389676d@oracle.com> References: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> <82b5aa63-75e6-3a01-7f53-fd4dc389676d@oracle.com> Message-ID: Hi Naoto, Thanks for the explanation. Change looks fine to me. Regards, Nishit Jain On 19-02-2019 22:51, Naoto Sato wrote: > Hi Nishit, > > The reason is that "US" is the only required locale in the JDK (cf. > Locale.getAvailableLocales(). In fact, initially I supplied "001" with > it, as it means the "world" in CLDR, but it broke some existing tests. > "001" returns "MONDAY" as the first day of week, whereas "SUNDAY" in > US. For the compatibility reason, I had to resort to "US". I am not > sure we want to hardcode "1" in this case without any convincing reason. > > Naoto > > On 2/19/19 6:37 AM, Nishit Jain wrote: >> Hi Naoto, >> >> Why is the default region set to "US" if there is no region specified >> in the locale? is this the default behavior of "first day of week" >> and "minimal days in first week" when a region is missing or the >> default behavior is that it returns "1"? Can't we just return "1" >> instead of setting the region to "US"? >> >> Regards, >> Nishit Jain >> On 16-02-2019 04:25, Naoto Sato wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8218960 >>> >>> The proposed changeset is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ >>> >>> The CONFIG message was generated because >>> CLDRCalendarDataProviderImpl was returning null for locales without >>> region. Use "US" as the default region in such a case. >>> >>> Naoto >> From Alan.Bateman at oracle.com Wed Feb 20 11:11:55 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Feb 2019 11:11:55 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <1876630e-265f-3639-274a-ef28b777964f@redhat.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> <3523d889-bd96-9709-ce7e-7a9fabf42de3@redhat.com> <2536d665-0eb7-f4c3-9bd9-248d42514640@oracle.com> <1876630e-265f-3639-274a-ef28b777964f@redhat.com> Message-ID: <6a9744cf-10ec-4684-f667-80471bbcae95@oracle.com> On 19/02/2019 18:01, Andrew Dinn wrote: > : > My reason for using capacity() was that I was swayed by the original > implementation of force(). It calls > > force0(fd, mappingAddress(offset), mappingLength(offset)) > > : > > I'm wondering if this ought to remain as is or ought to change to > specify limit()? > The no-arg force method is specified to force any changes to the buffer content to be written so I don't think it needs to change. We could clarify the spec on this point but I don't think it is strictly needed. -Alan From adinn at redhat.com Wed Feb 20 11:28:47 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 20 Feb 2019 11:28:47 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <6a9744cf-10ec-4684-f667-80471bbcae95@oracle.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> <3523d889-bd96-9709-ce7e-7a9fabf42de3@redhat.com> <2536d665-0eb7-f4c3-9bd9-248d42514640@oracle.com> <1876630e-265f-3639-274a-ef28b777964f@redhat.com> <6a9744cf-10ec-4684-f667-80471bbcae95@oracle.com> Message-ID: On 20/02/2019 11:11, Alan Bateman wrote: > On 19/02/2019 18:01, Andrew Dinn wrote: >> : >> My reason for using capacity() was that I was swayed by the original >> implementation of force(). It calls >> >> ?? force0(fd, mappingAddress(offset), mappingLength(offset)) >> >> : >> >> I'm wondering if this ought to remain as is or ought to change to >> specify limit()? >> > The no-arg force method is specified to force any changes to the buffer > content to be written so I don't think it needs to change. We could > clarify the spec on this point but I don't think it is strictly needed. Ok, thanks. So, in the next webrev when force() with no args is called on a non-SYNC mode buffer I will ensure it continues to call force0(fd, mappingAddress(offset), mappingLength(offset)) For a SYNC buffer I'll redirect to call force(0, limit()) That will retain the existing behaviour for force() on non-SYNC buffers and ensure the call to Objects.checkFromIndexSize in force(int, int) does not throw any surprise IOOBEs. 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, Eric Shander From aph at redhat.com Wed Feb 20 11:33:30 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Feb 2019 11:33:30 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> <3523d889-bd96-9709-ce7e-7a9fabf42de3@redhat.com> <2536d665-0eb7-f4c3-9bd9-248d42514640@oracle.com> <1876630e-265f-3639-274a-ef28b777964f@redhat.com> <6a9744cf-10ec-4684-f667-80471bbcae95@oracle.com> Message-ID: <937e7d2f-75e6-9f77-9df6-4f30a7577a7a@redhat.com> On 2/20/19 11:28 AM, Andrew Dinn wrote: > So, in the next webrev when force() with no args is called on a non-SYNC > mode buffer I will ensure it continues to call > > force0(fd, mappingAddress(offset), mappingLength(offset)) > > For a SYNC buffer I'll redirect to call > > force(0, limit()) Whoa! If that first argument a file descrpitor? If it is, you do know that 0 is a legal fd, right? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Wed Feb 20 12:32:30 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 20 Feb 2019 12:32:30 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <937e7d2f-75e6-9f77-9df6-4f30a7577a7a@redhat.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> <3523d889-bd96-9709-ce7e-7a9fabf42de3@redhat.com> <2536d665-0eb7-f4c3-9bd9-248d42514640@oracle.com> <1876630e-265f-3639-274a-ef28b777964f@redhat.com> <6a9744cf-10ec-4684-f667-80471bbcae95@oracle.com> <937e7d2f-75e6-9f77-9df6-4f30a7577a7a@redhat.com> Message-ID: On 20/02/2019 11:33, Andrew Haley wrote: > On 2/20/19 11:28 AM, Andrew Dinn wrote: >> So, in the next webrev when force() with no args is called on a non-SYNC >> mode buffer I will ensure it continues to call >> >> force0(fd, mappingAddress(offset), mappingLength(offset)) >> >> For a SYNC buffer I'll redirect to call >> >> force(0, limit()) > > > Whoa! If that first argument a file descrpitor? If it is, you do know > that 0 is a legal fd, right? > No need to panic. That first argument is not a file descriptor. I was explaining to Alan that I can (and will) implement the force() API method for SYNC buffers by redirecting to force(int,int). force(int,int) is a new API method to force a specific subregion of the buffer. If it needs to do writeback via an fd it pulls that out of the private MappedByteBuffer field (i.e this.fd) and passes it in the call to native method force0. n.b. for the above redirect case the force will be for a SYNC mapped buffer so an fd will not actually be needed. 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, Eric Shander From forax at univ-mlv.fr Wed Feb 20 14:17:39 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 20 Feb 2019 15:17:39 +0100 (CET) Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> Message-ID: <1794675000.777446.1550672259479.JavaMail.zimbra@u-pem.fr> with my ASM hat, ----- Mail original ----- > De: "Lindenmaier, Goetz" > ?: "Peter Levart" , "Roger Riggs" , "core-libs-dev" > > Cc: hotspot-runtime-dev at openjdk.java.net > Envoy?: Mardi 19 F?vrier 2019 17:08:07 > Objet: RE: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. > Hi, > > I have been looking at how to implement this in Java using > StackWalker and ASM. > Either I oversee something or there is a row of deficiencies with > these tools to solve my issue. > > StackWalker allows me to collect class name, method name, method > description and BCI. Given the current implementation, this must > happen in the NPE constructor which is very inefficient, but > works. Mandy, should I really change Throwable/StackWalker to > overcome this? Alternatively, I could JNI-call into the VM > and get the info when I need it. > > ASM allows me to access the class and the bytecode of the method. > > Unfortunately, ASM has no notion of BCI. It also does not > externally expose the bytecodes of the methods. It simplifies > the bytecodes, which is useful to manipulate them, but does > not allow me to recompute the BCI of instructions, say, iterating > the InsnList. yes, it's a feature of ASM, offer the right abstraction to do bytecode generation/transformation i.e. a stream of opcodes that are more abstract than the real bytecode, so there is no way to get a direct access to the bytecode at a specific BCI. > > Further, as I understand, the bytecode I can access in ASM > is the bytecode as it resides in the class file, not the > bytecode used by hotspot (bitwise). Hotspot rewrites bytecodes when > it loads them. And the BCI returned by StackWalker corresponds > to the bytecode used by hotspot, not that in the class file. > > If a method has been rewritten, there even might be several > instances of the same method/bytecode, the old still needed for > running executions and the new, rewritten one. The BCI > is only correct for one of these. > > So I don't see how I should find the ASM representation of > the bytecode that caused the NPE. Do you have any advice? > > Best regards, > Goetz. > R?mi > >> -----Original Message----- >> From: Peter Levart >> Sent: Freitag, 15. Februar 2019 18:38 >> To: Lindenmaier, Goetz ; Roger Riggs >> ; Java Core Libs >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException >> describing what is null. >> >> Hi Goetz, >> >> Just a couple of things if you go that route (of placeholder String): >> >> >> ? 56???? private static final String MESSAGE_PLACEHOLDER = >> "NPE_MESSAGE_PLACEHOLDER"; >> >> Here, the initializer of that constant should create a private instance >> of String: >> >> ??? private static final String MESSAGE_PLACEHOLDER = new >> String("NPE_MESSAGE_PLACEHOLDER"); >> >> or even (since the content of the placeholder string doesn't matter - >> the identity does): >> >> ??? private static final String MESSAGE_PLACEHOLDER = new String(); >> >> ...or else anybody calling new >> NullPointerException("NPE_MESSAGE_PLACEHOLDER") will also be the subject >> of replacement since the string literals are interned constants. I.e.: >> >> "NPE_MESSAGE_PLACEHOLDER" == "NPE_MESSAGE_PLACEHOLDER" >> >> >> ? 81???? public String getMessage() { >> ? 82???????? String message = super.getMessage(); >> ? 83???????? if (message == MESSAGE_PLACEHOLDER) { >> ? 84???????????? message = getExtendedNPEMessage(); >> ? 85???????????? setMessage(message); >> ? 86???????? } >> ? 87???????? return super.getMessage(); >> ? 88???? } >> >> Why not simply returning 'message' local variable here? >> >> >> Regards, Peter >> >> On 2/14/19 5:35 PM, Lindenmaier, Goetz wrote: >> > Hi Roger, >> > >> >> Maybe 10 years ago, when native was the only solution. >> >> Now there are tools to analyze bytecode in java. >> > I'm working on a Java implementation. >> > >> >>> Peter Levart proposed to initialize the message with a sentinel instead. >> >>> I'll implement this as a proposal. >> >> That's an extra overhead too, any assignment is. >> > Yes, any code requires some run time. But I think this really is negligible >> > in comparison to generating the backtrace, which happens on every >> > exception. But I'm fine with the 'always recompute, no serialization' >> > solution. If it turns out to be limited, it still can be changed easily. >> > >> >>> I guess we can go without. >> >>> It would be possible to construct a case where two threads >> >>> do getMessage() on the same NPE Object but the string is not >> >>> the same. >> >> Really!, if the bci is the same, the bytecode is the same, what could be >> different >> >> that would change the data used to create the exception? >> > e.getMessage().equals(e.getMessage()) will hold, but >> > e.getMessage() != e.getMessage(). >> > >> > I just implemented the two variants of computing the message, they >> > basically differ in NullPointerException.java: >> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/03- >> PeterLevart/ >> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/04- >> RogerRiggs/ >> > >> > I also cleaned up the parameters passed as proposed. >> > >> >>> We uses this code since 2006, it needed only few changes. I would like to >> >>> contribute a follow up for hidden frames of lambdas. >> >> Valhalla and evolution of the byte code needs to be considered. >> >> Just because its worked for years does not mean it's the best approach >> >> today. Dropping it in now means maintaining it in its current form >> >> or needing to re-write it later. >> > Well, yes, that is true. For any change. For any project. We have heard >> > this argument for many of our changes. I don't really think it's a good >> > argument. As I understand Valhalla is not targeted for jdk13, and >> > holding up changes for some future projects not really is the process >> > of OpenJDK, is it? >> > >> >>>> The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a >> >>>> question >> >>>> about how useful the information is, developers should not need to know >> >>>> about "slot 1". >> >>> Developers should work with class files with debug information and then >> >>> they would get the name printed. If exceptions are thrown in production >> >>> code, any information is helpful. Should I just write "a local"? >> >> Go back to who you think is going to benefit from it, it seems targeted >> >> at a fairly novice developer, so exposing low level details may be more >> >> confusing that just giving a line number and NPE. >> > Especially on our improved NPE messages we always got good feedback >> > from the developers within SAP. And there are quite some experienced >> > people. Any message requires some background to be helpful. And I >> > like to get any information I can have in first place. Attaching the >> > debugger often is a big overhead. E.g., I look at about 50 failing jtreg >> > tests every day, I don't want to get each into the debugger every time >> > in the setup where it was running to see what is wrong ... >> > >> > E.g., com/sun/java/swing/plaf/windows/AltFocusIssueTest.java >> > is failing in a headless environment with an NPE on this line: >> > SwingUtilities.invokeAndWait(() -> frame.dispose()); >> > With this change it said "while trying to invoke the method >> javax.swing.JFrame.dispose(()V) of a null object loaded from static field >> AltFocusIssueTest.frame" and I figured it's the fact we run headless that >> > makes the test fail without even looking at the code. >> > >> > Best regards, >> > Goetz >> > >> > >> > >> > >> > >> > >> > >> > >> > From: Roger Riggs >> > Sent: Dienstag, 12. Februar 2019 17:03 >> > To: Lindenmaier, Goetz ; Java Core Libs > libs-dev at openjdk.java.net> >> > Cc: hotspot-runtime-dev at openjdk.java.net >> > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException >> describing what is null. >> > >> > Hi, >> > On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote: >> > Hi Roger, >> > >> > thanks for looking at my change! >> > >> > A few higher level issues should be considered, though the details of >> > the webrev captured my immediate attention. >> > >> > Is this the right feature >> > Yes!! >> > Maybe, that's what debuggers are for. >> > >> > >> > >> > and is this the right level of implementation (C++/native)? >> > See below. >> > Maybe 10 years ago, when native was the only solution. >> > Now there are tools to analyze bytecode in java. >> > >> > >> > >> > From a security perspective, adding field names to exceptions exposes >> > information to callers that they could not otherwise get and that breaks >> > encapsulation. >> > That needs to be evaluated. >> > I can not comment on that. How can I trigger an evaluation of this? >> > Who needs to evaluate this? >> > >> > I think there are ways to make this easier to implement and be easier to >> > maintain and perform better. >> > >> > NullPointerException: >> > 28: unused import of Field >> > Removed >> > >> > 64: The lazyComputeMessage boolean should be inverted so it does not >> > require >> > ?? initialization, false is the default, anything else adds overhead. >> > ?? And it may not be needed. >> > Peter Levart proposed to initialize the message with a sentinel instead. >> > I'll implement this as a proposal. >> > That's an extra overhead too, any assignment is. >> > >> > >> > >> > 91: Why do you think synchonization is necessary?? It is a performance hit. >> > ?? It is highly unlikely to be called from multiple threads and the >> > value will >> > ?? be the same whether it is computed once or multiple times by >> > different threads. >> > I guess we can go without. >> > It would be possible to construct a case where two threads >> > do getMessage() on the same NPE Object but the string is not >> > the same. >> > Really!, if the bci is the same, the bytecode is the same, what could be >> different >> > that would change the data used to create the exception? >> > >> > >> > >> > 99: extendedMessage will never be null (so says the javadoc of >> > getExtendedNPEMessage) >> > ? Bug: If it does return null, then null is returned from getMessage >> > ? regardless of the value of super.getMessage(). >> > Fixed. >> > >> > 121: Simplify getExtendedNPEMessage by making it only responsible for >> > the detail >> > ? and not concatenation with an existing message.? Put that in >> > getMessage(). >> > Fixed. You are right, I only call this when the message is NULL. >> > >> > ? Its not strictly necessary to change the updated message with >> > setMessage(). >> > ? Avoiding that will avoid complexity and a performance hit. >> > ? The message will be computed each time it is needed, and that happens >> > infrequently. >> > ? (Even in the serialization case, it will be re-computed from the >> > attached stack frames). >> > No, you can not recompute it from the stacktrace because that >> > does not contain the BCI. Also, after deserialization, the bytecode >> > might look different or not available at all. It depends on the actual >> > bytecode that has been running when the exception was thrown. >> > Right, I realized this too when thinking about it over the weekend. >> > >> > If a suitable low impact mechanism can't be found, then just >> > go back to not exposing the extended message and use only the original. >> > Its a bad idea to twist and contort the local design and accessibility >> > just for serialization. What remote or delayed client needs to know this? >> > >> > >> > >> > >> > ? And it avoids adding setMessage() to Throwable, that's significant >> > change since >> > ? the current implementation only allows the message to be initialized >> > not updated. >> > ? Immutable is an important characteristic to maintain. >> > Yes, I don't like I have to set this. But it follows the same pattern >> > as with the stack trace which is only computed on demand. Thus, >> > Throwable is not immutable anyways. Before, I implemented this by a >> > JNI call hiding this in the Java code. >> > I proposed implementing setting the field by reflection, Christoph >> > proposed a shared secret. David favored the package private setter. >> > Please advice what is best. >> > All of them are bad. Private needs to mean private. >> > >> > And making it mutable, also means that synchronization or volatile >> > is needed to ensure a consistent value for getMessage(). >> > That turns into a performance issue for all throwables. >> > None of the above. >> > >> > >> > >> > That makes the writeReplace() unnecessary too. >> > No. I need this, see above. >> > See above, but is not essential to the core feature. >> > >> > >> > >> > Additional command line arguments are an unnecessary complexity, >> > documentation, and maintenance overhead.? If the feature is as valuable as >> > you suggest, it should be enabled all the time. >> > Removed. >> > >> > I'm assuming there are no tests broken by the modification of the message. >> > It is likely that somewhere an application or test looks at the message >> > itself. >> > Has that been verified? >> > Our nightly testing runs the headless jdk and hostspot jtreg tests, jck tests >> and some >> > other applications. They are all unaffected by this change after adapting the >> > message in jtreg/vmTestbase/jit/t/t104/t104.gold. >> > (win-x86_64, linux: ppc64, ppc64le, s390, x86_64, aarch, aix, solaris-sparc, >> mac) >> > Also, I modified quite some messages before which didn't cause any follow- >> up >> > breakages to my knowledge. >> > It does seem unlikely. >> > >> > >> > >> > I can't speak for the hotspot code, but that seems to add a lot of code >> > to support >> > only this convenience feature.? That's a maintenance overhead and burden. >> > We uses this code since 2006, it needed only few changes. I would like to >> > contribute a follow up for hidden frames of lambdas. >> > Valhalla and evolution of the byte code needs to be considered. >> > Just because its worked for years does not mean its the best approach >> > today.? Dropping it in now means maintaining it in its current form >> > or needing to re-write it later. >> > >> > >> > >> > The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a >> > question >> > about how useful the information is,? developers should not need to know >> > about "slot 1". >> > Developers should work with class files with debug information and then >> > they would get the name printed. If exceptions are thrown in production >> > code, any information is helpful. Should I just write "a local"? >> > Go back to who you think is going to benefit from it, it seems targeted >> > at a fairly novice developer, so exposing low level details may be more >> > confusing that just giving a line number and NPE. >> > >> > >> > >> > The test output of NullPointerExceptionTest shows >> > "java.lang.Object.hashCode(()I)". >> > Why is the argument type for Integer shown as "()I";? that's not the >> > conventional >> > representation of a primitive int. >> > I already discussed this with David Holmes: >> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019- >> February/058464.html >> > Other exceptions use the same format. I don't know of an utility in >> > hotspot to translate the format to Java source code syntax. We >> > implemented such an utility in our internal VM, though, and I would >> > like to contribute this, too, adapting all the exceptions. I would do this >> > in a follow-up. >> > There may be better tools for formatting if it was done in java at a >> > more appropriate level of abstraction. >> > >> > >> > >> > Generally, the explanations are too verbose. >> > Method names and field names would be easier to recognize if they were >> > quoted, as is done with 'this'. >> > Fixed, although this is not common in exception messages. See the >> > messages in >> http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runt >> ime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java, >> > line 57ff. Only the String of the name field is quoted, not any entities >> > declared in the code. >> > Similar >> http://hg.openjdk.java.net/jdk/jdk/file/2178d300d6b3/test/hotspot/jtreg/runt >> ime/LoaderConstraints/vtableAME/Test.java >> > line 60, also showing the internal signature, see above. >> > >> > Argument numbers should be digits, >> > not English words (first, second, etc) to make them easier to pick out. >> > Fixed. >> > And has it limits that do not read easily, e.g. "nr. 9". >> > Sorry, I don't understand >> > src/hotspot/share/classfile/bytecodeUtils.cpp:566 >> > >> test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerE >> xceptionTest.java:612 >> > >> > I would not describe 'this' as a local variable. >> > Fixed. >> > >> > Tests, especially new tests should compile without warnings. >> > NullPointerExceptionTest.java:125 newInstance has been deprecated. >> > Fixed. >> > >> > The messages can be easier to understand, e.g. >> > 'field a1 is null, trying to invoke a1.hashCode...' instead of: >> > "while trying to invoke the method java.lang.Object.hashCode(()I) on a >> > null reference loaded from local variable 'a1'" >> > The message is built along the structure of the bytecode. >> > I'll try to change this and then will come up with a new webrev . >> > >> > It will easier to understand if it looks more like the code. >> > BTW, what does this look like for fully optimized code? >> > You mean whether the bytecode is jitted? It's independent >> > of how the code is executed, interpreted or compiled. >> > >> > Does it bear any resemblance to the source code at all? >> > Or does it have to be deoptimized to come up with a sensible source >> > reference. >> > No, jitted methods must not be deoptimized. >> > >> > How much of this can be done in Java code with StackWalker and other >> > java APIs? >> > It would be a shame to add this much native code if there was a more robust >> > way to implement it using APIs with more leverage. >> > StackWalker operates on the Java stack tracke, which does not contain the >> BCI >> > to my knowledge. Also, I need to read the bytecodes. Are there APIs to >> access >> > the bytecode as it resides in the metaspace, rewritten, constants resolved >> etc? >> > The code relies on this. >> > >> > From the other thread, beware adding overhead to the constructor. >> > The lazy computation is essential. >> > There are a *lot* of NPEs whose messages will never be needed. >> > >> > Regards, Roger >> > >> > >> > >> > >> > Best regards, >> > Goetz. >> > >> > >> > >> > Regards, Roger >> > >> > >> > On 02/08/2019 09:13 AM, Langer, Christoph wrote: >> > Hi Goetz, >> > >> > ok, so here a new webrev just adding a setter for the field: >> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/02 >> > >> > ... and incorporating the other comments. >> > Looks better ?? >> > >> > I have a few additions to >> > src/java.base/share/classes/java/lang/NullPointerException.java: >> > >> > 28 import java.lang.reflect.Field; >> > 29 >> > -> can be removed now. >> > >> > 91 synchronized (this) { >> > -> I think this is not needed here. The transient modifier for >> > lazyComputeMessage already implies the lock on the Object, I think. >> > >> > 108 return extendedMessage; >> > -> I guess it would be more correct if you returned super.getMessage() here. >> > >> > Thanks >> > Christoph >> > From goetz.lindenmaier at sap.com Wed Feb 20 16:36:47 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Feb 2019 16:36:47 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: <1794675000.777446.1550672259479.JavaMail.zimbra@u-pem.fr> References: <7c4b0bc27961471e91195bef9e767226@sap.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <1794675000.777446.1550672259479.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, > yes, it's a feature of ASM, offer the right abstraction to do bytecode > generation/transformation i.e. a stream of opcodes that are more abstract > than the real bytecode, so there is no way to get a direct access to the > bytecode at a specific BCI. For the generation of the NPE message I intend the abstraction would be helpful. But I need to identify the bytecode that raised the NPE to start with, and I need to operate on the exact bytecode that was executed when the NPE occurred. Thus, two questions: 1. As I understand, it would be simple to extend ASM to deliver the initial BCIs when the stream is parsed. They could be stored separately and discarded once something gets modified (similar to InsnList.cache). 2. Is there any possibility to access the live datastructures/bytecode in the VM? I was pointed to former JvmtiClassFileReconstitutor ... something like that? Thanks and best regards, Goetz. From Roger.Riggs at oracle.com Wed Feb 20 16:50:04 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 20 Feb 2019 11:50:04 -0500 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> <661ca8a0-8761-83b8-9532-2e3deafbfbba@oracle.com> Message-ID: Hi Alexander, Ok, thanks Note: code reviews of code going into the sandbox is not a substitute for code review when it is to be pushed to jdk/jdk. (The sandbox has much more informal rules for commits that are branch specific.) Roger On 02/19/2019 10:44 PM, Alexander Matveev wrote: > Hi Roger, > > Some deleted files are actually deleted files, since I did code > cleanup as well. > Added files contain code from splitting original source files. This > was needed to re-arrange code. > Not sure how to log with hg file split. > > Also, we already moved files without keeping history, since we are not > planing to keep history when moving jpackage from sandbox. > > Thanks, > Alexander > > On 2/19/2019 8:49 AM, Roger Riggs wrote: >> Hi Alexander, >> >> Some files appear to be moved with hg, but others are copied and >> deleted. >> >> Please use hg mv to retain the continuity of the history. >> >> Thanks, Roger >> >> On 02/15/2019 10:03 PM, Alexander Matveev wrote: >>> Hi Magnus, >>> >>> http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ >>> >>> Moved all files from "posix" to "unix" folder and reverted >>> Lib-jdk.jpackage.gmk changes. >>> Webrev updated with files moved, instead of add/remove. >>> >>> Thanks, >>> Alexander >>> >>> On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2019-02-15 04:31, Alexander Matveev wrote: >>>>> Please review the jpackage fix for bug [1] at [2]. >>>>> >>>>> This is a fix for the JDK-8200758-branch branch of the open >>>>> sandbox repository (jpackage). >>>>> >>>>> - Moved native code under platform specific folder. >>>>> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. >>>>> - MAC define is still used in JavaVirtualMachine.cpp and >>>>> Package.cpp for Mac specific code to filter out some arguments. I >>>>> decided to keep it as is for now, since Mac specific code is small. >>>>> - Defines are used in Platform.cpp to initialize platform specific >>>>> classes. >>>>> - Removed all pragma warning and fixed all compilation warnings. >>>>> - Removed unused code. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212091 >>>>> >>>>> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ >>>> The JDK standard is to use "unix", not "posix", for the shared >>>> functionality between linux/solaris/macosx. You can keep the name >>>> "PosixPlatform.*" if you want, though; the important thing is the >>>> directory name. >>>> >>>> Also, if you do that, you do not need any changes to >>>> make/lib/Lib-jdk.jpackage.gmk, since that will be automatically >>>> understood by the build system. >>>> >>>> It looks from the webrev that you have "moved" the files by doing >>>> "hg add" and "hg remove". Please use "hg move" instead -- this will >>>> keep history intact, and it allows reviewers to see if you have >>>> also made changes to the moved files. >>>> >>>> (If you do have modified the moved file, reverting a "hg add+hg >>>> remove" process is a bit more tricky -- you need to do "hg forget" >>>> on the new file, rename it to something else (otherwise "hg move" >>>> will complain), "hg revert" the old file back in place, do a "hg >>>> move" from the old to the new, and then copy the modified, renamed >>>> file back over the target new file again.) >>>> >>>> /Magnus >>>>> >>>>> Thanks, >>>>> Alexander >>>> >>> >> > From deepak.kejriwal at oracle.com Wed Feb 20 16:53:10 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Wed, 20 Feb 2019 08:53:10 -0800 (PST) Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 In-Reply-To: References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> Message-ID: <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default> Thanks Naoto San and Sean for review. I have incorporate all the comments. Please find below updated version of webrev :- http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/ Regards, Deepak -----Original Message----- From: Naoto Sato Sent: Tuesday, February 19, 2019 10:23 PM To: Deepak Kejriwal ; core-libs-dev ; jdk-updates-dev at openjdk.java.net Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 Hi Deepak, Here are my comments to the webrev (other than what Sean pointed out): TestIsJavaIdentifierMethods.java - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit". - Line 34: "newCodePoint" does not represent the era character, as "new" is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"? - Line 67,68,(...all the comments): Reflect the above change to the comments. - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct. It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions. - Line 104: The test case returns "void", what does this "Expected results" mean? - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int): isLetter(codePoint) returns true getType(codePoint) returns LETTER_NUMBER the referenced character is a currency symbol (such as '$') the referenced character is a connecting punctuation character (such as '_'). - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). Naoto On 2/19/19 6:15 AM, Deepak Kejriwal wrote: > Correcting typo for release. > > > > From: Deepak Kejriwal > Sent: Tuesday, February 19, 2019 7:42 PM > To: 'core-libs-dev' ; > 'jdk-updates-dev at openjdk.java.net' > Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 > > > > Hi All, > > Please review the backport of the following bug fixes to jdk11u-dev: > > HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add > test cases for lenient Japanese era parsing HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square > character support for the Japanese new era HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change > isJavaIdentifierStart and isJavaIdentifierPart to handle new code > points > > Webrev: > http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ > > These code changes are made possible thanks to specification change already pushed: > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace > > Regards, > Deepak > > > From deepak.kejriwal at oracle.com Wed Feb 20 16:57:14 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Wed, 20 Feb 2019 08:57:14 -0800 (PST) Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 In-Reply-To: <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com> References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default> <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com> Message-ID: Thanks Naoto San and Sean for review. I have incorporate all the comments. Please find below updated version of webrev :- http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.01/ Regards, Deepak -----Original Message----- From: Naoto Sato Sent: Tuesday, February 19, 2019 10:40 PM To: Deepak Kejriwal ; core-libs-dev ; jdk8u-dev at openjdk.java.net Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 Hi Deepak, Almost all the comments for the 11u changes [1] applies here, except the "newCodePoint" comment. For this one, I'd suggest renaming "newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2" Naoto [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058610.html On 2/19/19 5:55 AM, Deepak Kejriwal wrote: > Hi All, > > Please review the backport of the following bug fixes to jdk8u-dev: > > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation. > HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters. > HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square > character support for the Japanese new era HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong > short form text for supplemental Japanese era HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add > test cases for lenient Japanese era parsing HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change > isJavaIdentifierStart and isJavaIdentifierPart to handle new code > points HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 > currency code points to Java SE 8uX > > Webrev: > http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u > /webrev.00/ > > These code changes are made possible thanks to specification changes already pushed: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7 > > Regards, > Deepak > > > > > > > From andy.herrick at oracle.com Wed Feb 20 16:57:01 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 20 Feb 2019 11:57:01 -0500 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> <661ca8a0-8761-83b8-9532-2e3deafbfbba@oracle.com> Message-ID: <579353e3-f0cb-d120-04b3-ce51b046bc50@oracle.com> On 2/20/2019 11:50 AM, Roger Riggs wrote: > Hi Alexander, > > Ok, thanks > > Note: code reviews of code going into the sandbox is not a substitute > for code review when it is to be pushed to jdk/jdk. > (The sandbox has much more informal rules for commits that are branch > specific.) sure - we will do a full code review of final contents before pushing sandbox into mainline. we started doing public review of all sandbox changes after EA2, just to get more and beter feedback. /Andy > > Roger > > > On 02/19/2019 10:44 PM, Alexander Matveev wrote: >> Hi Roger, >> >> Some deleted files are actually deleted files, since I did code >> cleanup as well. >> Added files contain code from splitting original source files. This >> was needed to re-arrange code. >> Not sure how to log with hg file split. >> >> Also, we already moved files without keeping history, since we are >> not planing to keep history when moving jpackage from sandbox. >> >> Thanks, >> Alexander >> >> On 2/19/2019 8:49 AM, Roger Riggs wrote: >>> Hi Alexander, >>> >>> Some files appear to be moved with hg, but others are copied and >>> deleted. >>> >>> Please use hg mv to retain the continuity of the history. >>> >>> Thanks, Roger >>> >>> On 02/15/2019 10:03 PM, Alexander Matveev wrote: >>>> Hi Magnus, >>>> >>>> http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ >>>> >>>> Moved all files from "posix" to "unix" folder and reverted >>>> Lib-jdk.jpackage.gmk changes. >>>> Webrev updated with files moved, instead of add/remove. >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2019-02-15 04:31, Alexander Matveev wrote: >>>>>> Please review the jpackage fix for bug [1] at [2]. >>>>>> >>>>>> This is a fix for the JDK-8200758-branch branch of the open >>>>>> sandbox repository (jpackage). >>>>>> >>>>>> - Moved native code under platform specific folder. >>>>>> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. >>>>>> - MAC define is still used in JavaVirtualMachine.cpp and >>>>>> Package.cpp for Mac specific code to filter out some arguments. I >>>>>> decided to keep it as is for now, since Mac specific code is small. >>>>>> - Defines are used in Platform.cpp to initialize platform >>>>>> specific classes. >>>>>> - Removed all pragma warning and fixed all compilation warnings. >>>>>> - Removed unused code. >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212091 >>>>>> >>>>>> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ >>>>> The JDK standard is to use "unix", not "posix", for the shared >>>>> functionality between linux/solaris/macosx. You can keep the name >>>>> "PosixPlatform.*" if you want, though; the important thing is the >>>>> directory name. >>>>> >>>>> Also, if you do that, you do not need any changes to >>>>> make/lib/Lib-jdk.jpackage.gmk, since that will be automatically >>>>> understood by the build system. >>>>> >>>>> It looks from the webrev that you have "moved" the files by doing >>>>> "hg add" and "hg remove". Please use "hg move" instead -- this >>>>> will keep history intact, and it allows reviewers to see if you >>>>> have also made changes to the moved files. >>>>> >>>>> (If you do have modified the moved file, reverting a "hg add+hg >>>>> remove" process is a bit more tricky -- you need to do "hg forget" >>>>> on the new file, rename it to something else (otherwise "hg move" >>>>> will complain), "hg revert" the old file back in place, do a "hg >>>>> move" from the old to the new, and then copy the modified, renamed >>>>> file back over the target new file again.) >>>>> >>>>> /Magnus >>>>>> >>>>>> Thanks, >>>>>> Alexander >>>>> >>>> >>> >> > From adinn at redhat.com Wed Feb 20 17:28:37 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 20 Feb 2019 17:28:37 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <1794675000.777446.1550672259479.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Goetz, Forgive me for jumping in here and, possibly, misunderstanding what you want -- I may have misunderstood what you are trying to do as I have not been following this thread carefully. On 20/02/2019 16:36, Lindenmaier, Goetz wrote: > 1. As I understand, it would be simple to extend ASM to deliver the initial > BCIs when the stream is parsed. They could be stored separately and > discarded once something gets modified (similar to InsnList.cache). Non-method bytecodes are normally dropped by the JVM during parsing. Only method bytecode is retained in the metadata model. One exception is when a registered ClassFileTransformer changes the loaded bytecode at load time. The original bytecode for the class is saved when that happens. Note that retaining method bytecode does not imply retaining the original classpool in bytecode format. Indices into the classpool are interpreted as indices into a metadata version of the classpool. Amongst other things, that allows sharing of symbols that occur in more than one class files. This avoids a /vast/ amount of storage costs. > 2. Is there any possibility to access the live datastructures/bytecode in the VM? > I was pointed to former JvmtiClassFileReconstitutor ... something like that? JvmtiClassFileReconstitutor exists precisely to recreate the full class bytecode from the metadata when needed. I believe it is only ever needed to allow a ClassFileTransformer to retransform a loaded class that was not transformed at load time. Using it seems like overkill to me (also see below). If you want to locate a specific bytecode instruction in a method you should be able to do so by pulling the method bytecodes out of the metadata. Also, if you want your message to reflect the bytecode that is actually in use when the exception occurs then you really need to do it by pulling the bytecodes out of the method metadata. The bytecode returned by JvmtiClassFileReconstitutor will not include any bytecode changes that were installed by a ClassFileTransformer. However, this is a potential can of worms because old and new versions of a method and associated bytecode can exist at the same time. You need to be sure which version of the method and, hence, bytecode the exception was generated from. If you are trying to do this from Java by calling into the JVM then I think you are going to have problems. 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, Eric Shander From naoto.sato at oracle.com Wed Feb 20 17:35:45 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 20 Feb 2019 09:35:45 -0800 Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 In-Reply-To: <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default> References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default> Message-ID: <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com> Hi Deepak, I see the following comment is not addressed yet: > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). Naoto On 2/20/19 8:53 AM, Deepak Kejriwal wrote: > Thanks Naoto San and Sean for review. I have incorporate all the comments. Please find below updated version of webrev :- > > http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/ > > Regards, > Deepak > > -----Original Message----- > From: Naoto Sato > Sent: Tuesday, February 19, 2019 10:23 PM > To: Deepak Kejriwal ; core-libs-dev ; jdk-updates-dev at openjdk.java.net > Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 > > Hi Deepak, > > Here are my comments to the webrev (other than what Sean pointed out): > > TestIsJavaIdentifierMethods.java > > - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit". > > - Line 34: "newCodePoint" does not represent the era character, as "new" > is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"? > > - Line 67,68,(...all the comments): Reflect the above change to the comments. > > - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct. > It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions. > > - Line 104: The test case returns "void", what does this "Expected results" mean? > > - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int): > > isLetter(codePoint) returns true > getType(codePoint) returns LETTER_NUMBER > the referenced character is a currency symbol (such as '$') > the referenced character is a connecting punctuation character (such as '_'). > > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). > > Naoto > > > On 2/19/19 6:15 AM, Deepak Kejriwal wrote: >> Correcting typo for release. >> >> >> >> From: Deepak Kejriwal >> Sent: Tuesday, February 19, 2019 7:42 PM >> To: 'core-libs-dev' ; >> 'jdk-updates-dev at openjdk.java.net' >> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 >> >> >> >> Hi All, >> >> Please review the backport of the following bug fixes to jdk11u-dev: >> >> HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add >> test cases for lenient Japanese era parsing HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square >> character support for the Japanese new era HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change >> isJavaIdentifierStart and isJavaIdentifierPart to handle new code >> points >> >> Webrev: >> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ >> >> These code changes are made possible thanks to specification change already pushed: >> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace >> >> Regards, >> Deepak >> >> >> From naoto.sato at oracle.com Wed Feb 20 17:37:08 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 20 Feb 2019 09:37:08 -0800 Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 In-Reply-To: References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default> <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com> Message-ID: <6a3ff77d-ac17-b072-83e5-7b91c4163be4@oracle.com> Hi Deepak, The same comment for 11u can be applied here too: > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). Naoto On 2/20/19 8:57 AM, Deepak Kejriwal wrote: > Thanks Naoto San and Sean for review. I have incorporate all the comments. Please find below updated version of webrev :- > > http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.01/ > > Regards, > Deepak > > -----Original Message----- > From: Naoto Sato > Sent: Tuesday, February 19, 2019 10:40 PM > To: Deepak Kejriwal ; core-libs-dev ; jdk8u-dev at openjdk.java.net > Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 > > Hi Deepak, > > Almost all the comments for the 11u changes [1] applies here, except the "newCodePoint" comment. For this one, I'd suggest renaming "newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2" > > Naoto > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058610.html > > On 2/19/19 5:55 AM, Deepak Kejriwal wrote: >> Hi All, >> >> Please review the backport of the following bug fixes to jdk8u-dev: >> >> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation. >> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters. >> HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square >> character support for the Japanese new era HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong >> short form text for supplemental Japanese era HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add >> test cases for lenient Japanese era parsing HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change >> isJavaIdentifierStart and isJavaIdentifierPart to handle new code >> points HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 >> currency code points to Java SE 8uX >> >> Webrev: >> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u >> /webrev.00/ >> >> These code changes are made possible thanks to specification changes already pushed: >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7 >> >> Regards, >> Deepak >> >> >> >> >> >> >> From mandy.chung at oracle.com Wed Feb 20 18:27:34 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 20 Feb 2019 10:27:34 -0800 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: <22d39d10-1889-474e-b5e5-30be633915e4@oracle.com> References: <71aa15a5-ac75-ee7a-f84d-d7ea2ee9098d@oracle.com> <054c2067-604a-d7b9-7569-1d4a647a9232@oracle.com> <22d39d10-1889-474e-b5e5-30be633915e4@oracle.com> Message-ID: <4bb0eb67-75e2-6dcb-cb22-95678641f76a@oracle.com> Hi Daniel, I return today from vacation. On 2/15/19 10:46 AM, Daniel Fuchs wrote: > Hi Mandy, > > Here is the new webrev: > > http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.01/ Looks good. I suggest to make the javadoc clear that isLoggable accepts null @param record a {@code LogRecord} or {@code null} > It is much nicer than the previous version [1], but unfortunately > it makes the following JCK tests fail: > > api/java_util/logging/MemoryHandler/IsLoggable.html > api/java_util/logging/MemoryHandler/Publish.html JDK-4769466 modified the spec to allow null LogRecord and so this is JCK test bug that should have been updated in JDK 5. We should file a bug for these tests. > These test expect the NPE even though the spec says that false > should be returned. I believe there was some disconnect between > the spec and the implementation at some point (see my > archeological finds [2] and [3] below). Thanks for finding the history. > So what should we do? > > Keep webrev.0.1, write CSR and release notes, and fix the > JCK in 13? I think fixing the implementation to match the spec per JDK-4769466 is reasonable and no compatibility risk as existing code would not call MemoryHandler::isLoggable and publish methods with null; otherwise, it fails with NPE. There is no spec change for this fix and no CSR is needed in my opinion. The JCK test failure is an existing test bug that should be fixed. Mandy From philipp.kunz at paratix.ch Wed Feb 20 18:44:10 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Wed, 20 Feb 2019 19:44:10 +0100 Subject: Faulty Null-Check Suspected in ToolProvider In-Reply-To: References: <1550266989.2497.19.camel@paratix.ch> <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> <1550275179.2497.21.camel@paratix.ch> <1550305222.2497.24.camel@paratix.ch> <4fe8ea57-e4dd-e48f-50da-6214fc479930@oracle.com> <1550364331.2497.28.camel@paratix.ch> Message-ID: <1550688250.2433.17.camel@paratix.ch> Hi Jon, All right, let's not document flushing behavior then. It's probably really not important enough. So we're back to the null-checks?For that see patch of https://mail.openjdk.java.net/pipermail/core-libs-dev/2019 -February/058576.html Regards,Philipp On Sat, 2019-02-16 at 17:05 -0800, Jonathan Gibbons wrote: > ????I still don't see why it is necessary to specify this behavior. > ????-- Jon > > ???? > > ?? > From lance.andersen at oracle.com Wed Feb 20 18:48:44 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 20 Feb 2019 13:48:44 -0500 Subject: Faulty Null-Check Suspected in ToolProvider In-Reply-To: <1550688250.2433.17.camel@paratix.ch> References: <1550266989.2497.19.camel@paratix.ch> <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> <1550275179.2497.21.camel@paratix.ch> <1550305222.2497.24.camel@paratix.ch> <4fe8ea57-e4dd-e48f-50da-6214fc479930@oracle.com> <1550364331.2497.28.camel@paratix.ch> <1550688250.2433.17.camel@paratix.ch> Message-ID: its on my todo list as is looking at your other issue, just have not gotten to it yet :-) > On Feb 20, 2019, at 1:44 PM, Philipp Kunz wrote: > > Hi Jon, > > All right, let's not document flushing behavior then. It's probably really not important enough. So we're back to the null-checks? > For that see patch of https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058576.html > > Regards, > Philipp > > > On Sat, 2019-02-16 at 17:05 -0800, Jonathan Gibbons wrote: >> I still don't see why it is necessary to specify this behavior. >> >> -- Jon >> 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 daniel.fuchs at oracle.com Wed Feb 20 18:57:12 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 20 Feb 2019 18:57:12 +0000 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: <4bb0eb67-75e2-6dcb-cb22-95678641f76a@oracle.com> References: <71aa15a5-ac75-ee7a-f84d-d7ea2ee9098d@oracle.com> <054c2067-604a-d7b9-7569-1d4a647a9232@oracle.com> <22d39d10-1889-474e-b5e5-30be633915e4@oracle.com> <4bb0eb67-75e2-6dcb-cb22-95678641f76a@oracle.com> Message-ID: On 20/02/2019 18:27, Mandy Chung wrote: >> Here is the new webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.01/ > > Looks good. Thanks Mandy! > I suggest to make the javadoc clear that isLoggable accepts null > ? @param record? a {@code LogRecord} or {@code null} Right - here is an updated webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.02/ > JDK-4769466 modified the spec to allow null LogRecord and so > this is JCK test bug that should have been updated in JDK 5. > We should file a bug for these tests. OK. I will file a bug. > I think fixing the implementation to match the spec per JDK-4769466 > is reasonable and no compatibility risk as existing code would not > call MemoryHandler::isLoggable and publish methods with null; > otherwise, it fails with NPE.? There is no spec change for this fix > and no CSR is needed in my opinion. > > The JCK test failure is an existing test bug that should be fixed. Agreed! > Mandy Thanks again for the feedback! best regards, -- daniel From mandy.chung at oracle.com Wed Feb 20 19:06:17 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 20 Feb 2019 11:06:17 -0800 Subject: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable In-Reply-To: References: <71aa15a5-ac75-ee7a-f84d-d7ea2ee9098d@oracle.com> <054c2067-604a-d7b9-7569-1d4a647a9232@oracle.com> <22d39d10-1889-474e-b5e5-30be633915e4@oracle.com> <4bb0eb67-75e2-6dcb-cb22-95678641f76a@oracle.com> Message-ID: On 2/20/19 10:57 AM, Daniel Fuchs wrote: > Right - here is an updated webrev: > > http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.02/ Looks good. Mandy From openjdk at icemanx.nl Wed Feb 20 21:45:55 2019 From: openjdk at icemanx.nl (Rob Spoor) Date: Wed, 20 Feb 2019 22:45:55 +0100 Subject: RFE: add missing methods to Optional, OptionalInt, OptionalLong and OptionalDouble In-Reply-To: <58cba64a-2af3-b3cc-9f89-399263714ddc@oracle.com> References: <21c52039-aa2c-a625-a855-4012bbb1766f@icemanx.nl> <58cba64a-2af3-b3cc-9f89-399263714ddc@oracle.com> Message-ID: I was actually missing at least one of the map methods. I have a method that is returning an OptionalInt, and I wanted to easily turn that into an Optional by applying mapToObj(Integer::valueOf). The same could also be done for OptionalLong -> Optional and OptionalDouble -> Optional. However, Valhalla's Optional will indeed make OptionalInt more or less superfluous (likewise for Optional and Optional). That raises one question - would it be worth adding these "missing" methods for just a few releases, after which they would no longer be necessary? They would not differ from the base type any more than IntStream, LongStream and DoubleStream differ from Stream, so that shouldn't block it. Speaking of the OptionalInt returning method, that is a version of Integer.parseInt that does not throw an exception but instead returns an OptionalInt (to prevent having the exception created and caught, only to be ignored). In line with C# I was calling it tryParseInt. I was actually intending to have an RFE for that one too, but in light of the upcoming Optional I think it's probably a better idea to wait with that until it's possible to return an Optional. Otherwise this method would be stuck with the "old" OptionalInt return type. On 19/02/2019 17:01, Brian Goetz wrote: > This is a very nice patch, complete with spec and tests, and evidence of > OCA. > > But, before we talk about patches and code, let's step back and talk > about stewardship.? With API proposals, we like to start with problems, > rather than solutions: what problems we are concerned with, and are > these are problems that need to be solved in the JDK?? Assuming we like > the answers to the former, we can then move on to whether the proposed > solution is the right one, and then to details like spec and code review. > > We are currently trying to avoid adding anything to > OptionalInt/Long/Double, because our current plan is to replace these > with a specialized Optional once Valhalla delivers.? Any methods > that differ from the base type (Optional) creates potential roadblocks > to such a migration, so we'd prefer to leaves these classes be. > > To the main question, though, whether Optional should have specialized > map and flatMap methods ... I'm skeptical.? The goal was never to create > parity between Optional and Stream, and my gut reaction is that the > return on additional API surface area here is negative.? But, we can > surely have a discussion on this. > > > > On 2/16/2019 7:52 AM, Rob Spoor wrote: >> I noticed that, while Stream and its primitive equivalents have >> multiple map and flapMap methods, Optional and its primitive >> equivalents were missing those. Since these can still be very useful, >> I wrote a patch to add the following methods: >> >> * Optional: mapToInt, mapToLong, mapToDouble, flatMapToInt, >> flatMapToLong, flatMapToDouble >> * OptionalInt: map, mapToObj, mapToLong, mapToDouble, flatMap >> * OptionalLong: map, mapToObj, mapToInt, mapToDouble, flatMap >> * OptionalDouble: map, mapToObj, mapToInt, mapToLong, flatMap >> >> I did not add any more flatMap methods to OptionalInt, OptionalLong >> and OptionalDouble because these also don't exist on IntStream, >> LongStream and DoubleStream. >> >> >> In addition, I also added the missing or method to OptionalInt, >> OptionalLong and OptionalDouble based on that of Optional. >> >> >> My OCA has been processed on 2019-01-22. >> >> >> Rob From naoto.sato at oracle.com Wed Feb 20 22:54:58 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 20 Feb 2019 14:54:58 -0800 Subject: [13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO In-Reply-To: References: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> <82b5aa63-75e6-3a01-7f53-fd4dc389676d@oracle.com> Message-ID: <5c858614-ea1f-cc7a-e98b-3ac8c3379db1@oracle.com> Thanks, Nishit. I'd still like to ask for a review from a Reviewer. Naoto On 2/20/19 12:33 AM, Nishit Jain wrote: > Hi Naoto, > > Thanks for the explanation. Change looks fine to me. > > Regards, > Nishit Jain > On 19-02-2019 22:51, Naoto Sato wrote: >> Hi Nishit, >> >> The reason is that "US" is the only required locale in the JDK (cf. >> Locale.getAvailableLocales(). In fact, initially I supplied "001" with >> it, as it means the "world" in CLDR, but it broke some existing tests. >> "001" returns "MONDAY" as the first day of week, whereas "SUNDAY" in >> US. For the compatibility reason, I had to resort to "US". I am not >> sure we want to hardcode "1" in this case without any convincing reason. >> >> Naoto >> >> On 2/19/19 6:37 AM, Nishit Jain wrote: >>> Hi Naoto, >>> >>> Why is the default region set to "US" if there is no region specified >>> in the locale? is this the default behavior of "first day of week" >>> and "minimal days in first week" when a region is missing or the >>> default behavior is that it returns "1"? Can't we just return "1" >>> instead of setting the region to "US"? >>> >>> Regards, >>> Nishit Jain >>> On 16-02-2019 04:25, Naoto Sato wrote: >>>> Hello, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8218960 >>>> >>>> The proposed changeset is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ >>>> >>>> The CONFIG message was generated because >>>> CLDRCalendarDataProviderImpl was returning null for locales without >>>> region. Use "US" as the default region in such a case. >>>> >>>> Naoto >>> > From vicente.romero at oracle.com Wed Feb 20 23:10:46 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 20 Feb 2019 18:10:46 -0500 Subject: RFR: JDK-8219480: j.l.c.ClassDesc::arrayType(int rank) throws IllegalArgumentException if rank = 0 Message-ID: Please review the simple patch to fix [1] at [2]. The patch is simply adding a comment to the API, (javadoc) to sync it with the implementation. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8219480 [2] http://cr.openjdk.java.net/~vromero/8219480/webrev.00/ From roger.riggs at oracle.com Thu Feb 21 02:41:32 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 20 Feb 2019 21:41:32 -0500 Subject: [13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO In-Reply-To: <5c858614-ea1f-cc7a-e98b-3ac8c3379db1@oracle.com> References: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> <82b5aa63-75e6-3a01-7f53-fd4dc389676d@oracle.com> <5c858614-ea1f-cc7a-e98b-3ac8c3379db1@oracle.com> Message-ID: <1b9e6ab6-38af-d775-3526-392bd402fe8e@oracle.com> Hi Naoto, The fix looks fine. The direction for new tests is to give them functional names, not bugids. Is there a suitable name? CalendarDataUtility.java: 260;? the assert is just documentation right? Its rare to see asserts enabled except in test contexts. Thanks, Roger On 2/20/19 5:54 PM, naoto.sato at oracle.com wrote: > Thanks, Nishit. > > I'd still like to ask for a review from a Reviewer. > > Naoto > > On 2/20/19 12:33 AM, Nishit Jain wrote: >> Hi Naoto, >> >> Thanks for the explanation. Change looks fine to me. >> >> Regards, >> Nishit Jain >> On 19-02-2019 22:51, Naoto Sato wrote: >>> Hi Nishit, >>> >>> The reason is that "US" is the only required locale in the JDK (cf. >>> Locale.getAvailableLocales(). In fact, initially I supplied "001" >>> with it, as it means the "world" in CLDR, but it broke some existing >>> tests. "001" returns "MONDAY" as the first day of week, whereas >>> "SUNDAY" in US. For the compatibility reason, I had to resort to >>> "US". I am not sure we want to hardcode "1" in this case without any >>> convincing reason. >>> >>> Naoto >>> >>> On 2/19/19 6:37 AM, Nishit Jain wrote: >>>> Hi Naoto, >>>> >>>> Why is the default region set to "US" if there is no region >>>> specified in the locale? is this the default behavior of "first day >>>> of week" and "minimal days in first week" when a region is missing >>>> or the default behavior is that it returns "1"? Can't we just >>>> return "1" instead of setting the region to "US"? >>>> >>>> Regards, >>>> Nishit Jain >>>> On 16-02-2019 04:25, Naoto Sato wrote: >>>>> Hello, >>>>> >>>>> Please review the fix to the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8218960 >>>>> >>>>> The proposed changeset is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ >>>>> >>>>> The CONFIG message was generated because >>>>> CLDRCalendarDataProviderImpl was returning null for locales >>>>> without region. Use "US" as the default region in such a case. >>>>> >>>>> Naoto >>>> >> From igor.ignatyev at oracle.com Thu Feb 21 05:19:58 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 20 Feb 2019 21:19:58 -0800 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm Message-ID: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html > 40 lines changed: 17 ins; 2 del; 21 mod; Hi all, could you please review this small patch which moves tests from test/jdk/vm? there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 testing: tier[1-2] (in progress), all the touched tests locally Thanks, -- Igor From david.holmes at oracle.com Thu Feb 21 08:11:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Feb 2019 18:11:30 +1000 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> Message-ID: <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> Hi Igor, On 21/02/2019 3:19 pm, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >> 40 lines changed: 17 ins; 2 del; 21 mod; > > Hi all, > > could you please review this small patch which moves tests from test/jdk/vm? I find some of these tests - the runtime ones at least - of extremely dubious value. They either cover basic functionality that is already well covered, or are regression tests for bugs in code that hasn't existed for many many years! BTW: test/hotspot/jtreg/runtime/ShiftTest.java is actually a jit test according to the test comment. > there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test No its a JNI invocation API test - nothing to do with our launcher. It belongs in runtime/jni. But we already have tests in runtime that use the JNI invocation API so this test adds no new coverage. I really think the value of these tests needs to be examined before they are brought over. Thanks, David ----- > and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. > > webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 > testing: tier[1-2] (in progress), all the touched tests locally > > Thanks, > -- Igor > From Alan.Bateman at oracle.com Thu Feb 21 08:19:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2019 08:19:56 +0000 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> Message-ID: On 21/02/2019 05:19, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >> 40 lines changed: 17 ins; 2 del; 21 mod; > Hi all, > > could you please review this small patch which moves tests from test/jdk/vm? > > there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. > > webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 > testing: tier[1-2] (in progress), all the touched tests locally > The tools/launcher directory is the tests for the java launcher, I don't think it's the right place for tests for the JNI invocation interface - I think that one is asking to be moved to be with the other JNI tests. -Alan From deepak.kejriwal at oracle.com Thu Feb 21 08:26:47 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Thu, 21 Feb 2019 00:26:47 -0800 (PST) Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 In-Reply-To: <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com> References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default> <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com> Message-ID: <672daacf-f12e-47a5-af14-b7ac054a3f1c@default> Hi Naoto, Corrected the exception message. Please find below updated version of webrev:- http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/ Thanks for review. Regards, Deepak -----Original Message----- From: Naoto Sato Sent: Wednesday, February 20, 2019 11:06 PM To: Deepak Kejriwal ; Sean Coffey ; core-libs-dev ; jdk-updates-dev at openjdk.java.net Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 Hi Deepak, I see the following comment is not addressed yet: > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). Naoto On 2/20/19 8:53 AM, Deepak Kejriwal wrote: > Thanks Naoto San and Sean for review. I have incorporate all the > comments. Please find below updated version of webrev :- > > http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/ > > Regards, > Deepak > > -----Original Message----- > From: Naoto Sato > Sent: Tuesday, February 19, 2019 10:23 PM > To: Deepak Kejriwal ; core-libs-dev > ; jdk-updates-dev at openjdk.java.net > Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 > > Hi Deepak, > > Here are my comments to the webrev (other than what Sean pointed out): > > TestIsJavaIdentifierMethods.java > > - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit". > > - Line 34: "newCodePoint" does not represent the era character, as "new" > is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"? > > - Line 67,68,(...all the comments): Reflect the above change to the comments. > > - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct. > It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions. > > - Line 104: The test case returns "void", what does this "Expected results" mean? > > - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int): > > isLetter(codePoint) returns true > getType(codePoint) returns LETTER_NUMBER > the referenced character is a currency symbol (such as '$') > the referenced character is a connecting punctuation character (such as '_'). > > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). > > Naoto > > > On 2/19/19 6:15 AM, Deepak Kejriwal wrote: >> Correcting typo for release. >> >> >> >> From: Deepak Kejriwal >> Sent: Tuesday, February 19, 2019 7:42 PM >> To: 'core-libs-dev' ; >> 'jdk-updates-dev at openjdk.java.net' >> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 >> >> >> >> Hi All, >> >> Please review the backport of the following bug fixes to jdk11u-dev: >> >> HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add >> test cases for lenient Japanese era parsing HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : >> Square character support for the Japanese new era HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : >> Change isJavaIdentifierStart and isJavaIdentifierPart to handle new >> code points >> >> Webrev: >> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ >> >> These code changes are made possible thanks to specification change already pushed: >> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace >> >> Regards, >> Deepak >> >> >> From sean.coffey at oracle.com Thu Feb 21 08:41:27 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 21 Feb 2019 08:41:27 +0000 Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 In-Reply-To: <672daacf-f12e-47a5-af14-b7ac054a3f1c@default> References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default> <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com> <672daacf-f12e-47a5-af14-b7ac054a3f1c@default> Message-ID: <1bfebd99-bbf4-0a6c-e0e3-7dd8cda73911@oracle.com> Deepak, this exception message in new test still needs correction: > 166 "Character.isLetter(int) failed for codepoint " > 167 + Integer.toHexString(cp)); As an aside, there's probably no need for such specific exception messages in a test case. It's error prone (but you've come this far now) regards, Sean. On 21/02/2019 08:26, Deepak Kejriwal wrote: > Hi Naoto, > > Corrected the exception message. Please find below updated version of webrev:- > http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/ > > Thanks for review. > > Regards, > Deepak > > -----Original Message----- > From: Naoto Sato > Sent: Wednesday, February 20, 2019 11:06 PM > To: Deepak Kejriwal ; Sean Coffey ; core-libs-dev ; jdk-updates-dev at openjdk.java.net > Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 > > Hi Deepak, > > I see the following comment is not addressed yet: > > > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). > > Naoto > > On 2/20/19 8:53 AM, Deepak Kejriwal wrote: >> Thanks Naoto San and Sean for review. I have incorporate all the >> comments. Please find below updated version of webrev :- >> >> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/ >> >> Regards, >> Deepak >> >> -----Original Message----- >> From: Naoto Sato >> Sent: Tuesday, February 19, 2019 10:23 PM >> To: Deepak Kejriwal ; core-libs-dev >> ; jdk-updates-dev at openjdk.java.net >> Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 >> >> Hi Deepak, >> >> Here are my comments to the webrev (other than what Sean pointed out): >> >> TestIsJavaIdentifierMethods.java >> >> - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit". >> >> - Line 34: "newCodePoint" does not represent the era character, as "new" >> is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"? >> >> - Line 67,68,(...all the comments): Reflect the above change to the comments. >> >> - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct. >> It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions. >> >> - Line 104: The test case returns "void", what does this "Expected results" mean? >> >> - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int): >> >> isLetter(codePoint) returns true >> getType(codePoint) returns LETTER_NUMBER >> the referenced character is a currency symbol (such as '$') >> the referenced character is a connecting punctuation character (such as '_'). >> >> - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). >> >> Naoto >> >> >> On 2/19/19 6:15 AM, Deepak Kejriwal wrote: >>> Correcting typo for release. >>> >>> >>> >>> From: Deepak Kejriwal >>> Sent: Tuesday, February 19, 2019 7:42 PM >>> To: 'core-libs-dev' ; >>> 'jdk-updates-dev at openjdk.java.net' >>> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 >>> >>> >>> >>> Hi All, >>> >>> Please review the backport of the following bug fixes to jdk11u-dev: >>> >>> HYPERLINK >>> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add >>> test cases for lenient Japanese era parsing HYPERLINK >>> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : >>> Square character support for the Japanese new era HYPERLINK >>> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : >>> Change isJavaIdentifierStart and isJavaIdentifierPart to handle new >>> code points >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ >>> >>> These code changes are made possible thanks to specification change already pushed: >>> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace >>> >>> Regards, >>> Deepak >>> >>> >>> From deepak.kejriwal at oracle.com Thu Feb 21 08:54:43 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Thu, 21 Feb 2019 00:54:43 -0800 (PST) Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 In-Reply-To: <6a3ff77d-ac17-b072-83e5-7b91c4163be4@oracle.com> References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default> <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com> <6a3ff77d-ac17-b072-83e5-7b91c4163be4@oracle.com> Message-ID: <87fb7fb1-eb11-4b5a-a026-b0bf0da57327@default> Hi Naoto, Corrected the exception message. Please find below updated version of webrev:- http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.02/ Thanks for review. Regards, Deepak -----Original Message----- From: Naoto Sato Sent: Wednesday, February 20, 2019 11:07 PM To: Deepak Kejriwal ; Sean Coffey ; core-libs-dev ; jdk8u-dev at openjdk.java.net Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 Hi Deepak, The same comment for 11u can be applied here too: > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). Naoto On 2/20/19 8:57 AM, Deepak Kejriwal wrote: > Thanks Naoto San and Sean for review. I have incorporate all the > comments. Please find below updated version of webrev :- > > http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u > /webrev.01/ > > Regards, > Deepak > > -----Original Message----- > From: Naoto Sato > Sent: Tuesday, February 19, 2019 10:40 PM > To: Deepak Kejriwal ; core-libs-dev > ; jdk8u-dev at openjdk.java.net > Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, > JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 > > Hi Deepak, > > Almost all the comments for the 11u changes [1] applies here, except the "newCodePoint" comment. For this one, I'd suggest renaming "newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2" > > Naoto > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/05 > 8610.html > > On 2/19/19 5:55 AM, Deepak Kejriwal wrote: >> Hi All, >> >> Please review the backport of the following bug fixes to jdk8u-dev: >> >> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation. >> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters. >> HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : >> Square character support for the Japanese new era HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong >> short form text for supplemental Japanese era HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add >> test cases for lenient Japanese era parsing HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : >> Change isJavaIdentifierStart and isJavaIdentifierPart to handle new >> code points HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 >> currency code points to Java SE 8uX >> >> Webrev: >> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8 >> u >> /webrev.00/ >> >> These code changes are made possible thanks to specification changes already pushed: >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7 >> >> Regards, >> Deepak >> >> >> >> >> >> >> From deepak.kejriwal at oracle.com Thu Feb 21 09:10:21 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Thu, 21 Feb 2019 01:10:21 -0800 (PST) Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 In-Reply-To: <1bfebd99-bbf4-0a6c-e0e3-7dd8cda73911@oracle.com> References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default> <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com> <672daacf-f12e-47a5-af14-b7ac054a3f1c@default> <1bfebd99-bbf4-0a6c-e0e3-7dd8cda73911@oracle.com> Message-ID: <62567a03-7473-4651-b1b3-a338629c6666@default> Hi Sean, ? The webrev I shared was not correct. I have corrected the webrev.02 now. Please check now:- http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/ ? Regards, Deepak ? From: Se?n Coffey Sent: Thursday, February 21, 2019 2:11 PM To: Deepak Kejriwal ; Naoto Sato ; core-libs-dev ; jdk-updates-dev at openjdk.java.net Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 ? Deepak, this exception message in new test still needs correction: 166???????????????????????? "Character.isLetter(int) failed for codepoint " 167???????????????????????????????? + Integer.toHexString(cp)); As an aside, there's probably no need for such specific exception messages in a test case. It's error prone (but you've come this far now) regards, Sean. On 21/02/2019 08:26, Deepak Kejriwal wrote: Hi Naoto, ? Corrected the exception message. Please find below updated version of webrev:- http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/ ? Thanks for review. ? Regards, Deepak ? -----Original Message----- From: Naoto Sato Sent: Wednesday, February 20, 2019 11:06 PM To: Deepak Kejriwal HYPERLINK "mailto:deepak.kejriwal at oracle.com"; Sean Coffey HYPERLINK "mailto:sean.coffey at oracle.com"; core-libs-dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net"; HYPERLINK "mailto:jdk-updates-dev at openjdk.java.net"jdk-updates-dev at openjdk.java.net Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 ? Hi Deepak, ? I see the following comment is not addressed yet: ? > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). ? Naoto ? On 2/20/19 8:53 AM, Deepak Kejriwal wrote: Thanks Naoto San and Sean for review. I have incorporate all the comments. Please find below updated version of webrev :- ? http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/ ? Regards, Deepak ? -----Original Message----- From: Naoto Sato Sent: Tuesday, February 19, 2019 10:23 PM To: Deepak Kejriwal HYPERLINK "mailto:deepak.kejriwal at oracle.com"; core-libs-dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net"; HYPERLINK "mailto:jdk-updates-dev at openjdk.java.net"jdk-updates-dev at openjdk.java.net Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 ? Hi Deepak, ? Here are my comments to the webrev (other than what Sean pointed out): ? TestIsJavaIdentifierMethods.java ? - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit". ? - Line 34: "newCodePoint" does not represent the era character, as "new" is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"? ? - Line 67,68,(...all the comments): Reflect the above change to the comments. ? - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct. It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions. ? - Line 104: The test case returns "void", what does this "Expected results" mean? ? - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int): ? ???? isLetter(codePoint) returns true ???? getType(codePoint) returns LETTER_NUMBER ???? the referenced character is a currency symbol (such as '$') ???? the referenced character is a connecting punctuation character (such as '_'). ? - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). ? Naoto ? ? On 2/19/19 6:15 AM, Deepak Kejriwal wrote: Correcting typo for release. ? ?? ? From: Deepak Kejriwal HYPERLINK "mailto:deepak.kejriwal at oracle.com" Sent: Tuesday, February 19, 2019 7:42 PM To: 'core-libs-dev' HYPERLINK "mailto:core-libs-dev at openjdk.java.net"; 'HYPERLINK "mailto:jdk-updates-dev at openjdk.java.net"jdk-updates-dev at openjdk.java.net' HYPERLINK "mailto:jdk-updates-dev at openjdk.java.net" Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 ? ?? ? Hi All, ? Please review the backport of the following bug fixes to jdk11u-dev: ? HYPERLINK HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120""https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing HYPERLINK HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398""https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era HYPERLINK HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915""https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points ? Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ ? These code changes are made possible thanks to specification change already pushed: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace ? Regards, Deepak ? ?? ? From sean.coffey at oracle.com Thu Feb 21 10:24:17 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 21 Feb 2019 10:24:17 +0000 Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 In-Reply-To: <62567a03-7473-4651-b1b3-a338629c6666@default> References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default> <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com> <672daacf-f12e-47a5-af14-b7ac054a3f1c@default> <1bfebd99-bbf4-0a6c-e0e3-7dd8cda73911@oracle.com> <62567a03-7473-4651-b1b3-a338629c6666@default> Message-ID: <400181fb-4e53-3a84-7cc6-cca85bc7207b@oracle.com> Thanks. Looks good to me. regards, Sean. On 21/02/2019 09:10, Deepak Kejriwal wrote: > > Hi Sean, > > The webrev I shared was not correct. I have corrected the webrev.02 > now. Please check now:- > > http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/ > > Regards, > > Deepak > > *From:*Se?n Coffey > *Sent:* Thursday, February 21, 2019 2:11 PM > *To:* Deepak Kejriwal ; Naoto Sato > ; core-libs-dev > ; jdk-updates-dev at openjdk.java.net > *Subject:* Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 > > Deepak, > > this exception message in new test still needs correction: > > 166???????????????????????? "Character.isLetter(int) failed for codepoint " > > 167???????????????????????????????? + Integer.toHexString(cp)); > > As an aside, there's probably no need for such specific exception > messages in a test case. It's error prone (but you've come this far now) > > regards, > Sean. > > On 21/02/2019 08:26, Deepak Kejriwal wrote: > > Hi Naoto, > > Corrected the exception message. Please find below updated version of webrev:- > > http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/ > > Thanks for review. > > Regards, > > Deepak > > -----Original Message----- > > From: Naoto Sato > > Sent: Wednesday, February 20, 2019 11:06 PM > > To: Deepak Kejriwal ; Sean Coffey ; core-libs-dev ;jdk-updates-dev at openjdk.java.net > > Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 > > Hi Deepak, > > I see the following comment is not addressed yet: > > > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). > > Naoto > > On 2/20/19 8:53 AM, Deepak Kejriwal wrote: > > Thanks Naoto San and Sean for review. I have incorporate all the > > comments. Please find below updated version of webrev :- > > http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/ > > Regards, > > Deepak > > -----Original Message----- > > From: Naoto Sato > > Sent: Tuesday, February 19, 2019 10:23 PM > > To: Deepak Kejriwal ; core-libs-dev > > ;jdk-updates-dev at openjdk.java.net > > Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 > > Hi Deepak, > > Here are my comments to the webrev (other than what Sean pointed out): > > TestIsJavaIdentifierMethods.java > > - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit". > > - Line 34: "newCodePoint" does not represent the era character, as "new" > > is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"? > > - Line 67,68,(...all the comments): Reflect the above change to the comments. > > - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct. > > It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions. > > - Line 104: The test case returns "void", what does this "Expected results" mean? > > - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int): > > ???? isLetter(codePoint) returns true > > ???? getType(codePoint) returns LETTER_NUMBER > > ???? the referenced character is a currency symbol (such as '$') > > ???? the referenced character is a connecting punctuation character (such as '_'). > > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). > > Naoto > > On 2/19/19 6:15 AM, Deepak Kejriwal wrote: > > Correcting typo for release. > > > > From: Deepak Kejriwal > > Sent: Tuesday, February 19, 2019 7:42 PM > > To: 'core-libs-dev' ; > > 'jdk-updates-dev at openjdk.java.net ' > > Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 > > > > Hi All, > > Please review the backport of the following bug fixes to jdk11u-dev: > > HYPERLINK > > "https://bugs.openjdk.java.net/browse/JDK-8206120" JDK-8206120 : Add > > test cases for lenient Japanese era parsing HYPERLINK > > "https://bugs.openjdk.java.net/browse/JDK-8211398" JDK-8211398 : > > Square character support for the Japanese new era HYPERLINK > > "https://bugs.openjdk.java.net/browse/JDK-8218915" JDK-8218915 : > > Change isJavaIdentifierStart and isJavaIdentifierPart to handle new > > code points > > Webrev: > > http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ > > These code changes are made possible thanks to specification change already pushed: > > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace > > Regards, > > Deepak > > > From sean.coffey at oracle.com Thu Feb 21 10:27:04 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 21 Feb 2019 10:27:04 +0000 Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 In-Reply-To: <87fb7fb1-eb11-4b5a-a026-b0bf0da57327@default> References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default> <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com> <6a3ff77d-ac17-b072-83e5-7b91c4163be4@oracle.com> <87fb7fb1-eb11-4b5a-a026-b0bf0da57327@default> Message-ID: Looks good. regards, Sean. On 21/02/2019 08:54, Deepak Kejriwal wrote: > Hi Naoto, > > Corrected the exception message. Please find below updated version of webrev:- > http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.02/ > > > Thanks for review. > > Regards, > Deepak > > -----Original Message----- > From: Naoto Sato > Sent: Wednesday, February 20, 2019 11:07 PM > To: Deepak Kejriwal ; Sean Coffey ; core-libs-dev ; jdk8u-dev at openjdk.java.net > Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 > > Hi Deepak, > > The same comment for 11u can be applied here too: > > > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). > > Naoto > > On 2/20/19 8:57 AM, Deepak Kejriwal wrote: >> Thanks Naoto San and Sean for review. I have incorporate all the >> comments. Please find below updated version of webrev :- >> >> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u >> /webrev.01/ >> >> Regards, >> Deepak >> >> -----Original Message----- >> From: Naoto Sato >> Sent: Tuesday, February 19, 2019 10:40 PM >> To: Deepak Kejriwal ; core-libs-dev >> ; jdk8u-dev at openjdk.java.net >> Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, >> JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 >> >> Hi Deepak, >> >> Almost all the comments for the 11u changes [1] applies here, except the "newCodePoint" comment. For this one, I'd suggest renaming "newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2" >> >> Naoto >> >> [1] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/05 >> 8610.html >> >> On 2/19/19 5:55 AM, Deepak Kejriwal wrote: >>> Hi All, >>> >>> Please review the backport of the following bug fixes to jdk8u-dev: >>> >>> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation. >>> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters. >>> HYPERLINK >>> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : >>> Square character support for the Japanese new era HYPERLINK >>> "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong >>> short form text for supplemental Japanese era HYPERLINK >>> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add >>> test cases for lenient Japanese era parsing HYPERLINK >>> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : >>> Change isJavaIdentifierStart and isJavaIdentifierPart to handle new >>> code points HYPERLINK >>> "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 >>> currency code points to Java SE 8uX >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8 >>> u >>> /webrev.00/ >>> >>> These code changes are made possible thanks to specification changes already pushed: >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7 >>> >>> Regards, >>> Deepak >>> >>> >>> >>> >>> >>> >>> From adinn at redhat.com Thu Feb 21 12:02:47 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 21 Feb 2019 12:02:47 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <1876630e-265f-3639-274a-ef28b777964f@redhat.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <2a0a385d-81ee-df66-f147-e4dd9aa5b72e@oracle.com> <8b2ab749-20f1-8dd3-3cc7-64db5d45bc7d@redhat.com> <0aae37aa-7797-fde5-63d5-96c8eb961183@oracle.com> <86a1988a-a8d2-b6af-0985-11a94d6d76a5@redhat.com> <69510788-52e6-815b-1ed7-a6f4886d0398@oracle.com> <3e3c4f7d-049e-4aec-c165-f2! 664e7c98ef@redhat.com> <1db29a76-f228-ea92-5351-64aedc0803a2@redhat.com> <66d9fcc4-d351-fb29-6be6-eb281864cbe0@oracle.com> <3523d889-bd96-9709-ce7e-7a9fabf42de3@redhat.com> <2536d665-0eb7-f4c3-9bd9-248d42514640@oracle.com> <1876630e-265f-3639-274a-ef28b777964f@redhat.com> Message-ID: The latest JEP and draft implementation now address the 3 outstanding issues: 1) 2-arg force method now uses integer start offset and length force(int from, int length) 2) length is checked against buffer limit rather than capacity 3) start position and length checks are implemented using Objects.checkFromIndexSize. In consequence, force(int,int) now throws IOOBE. I updated the JEP and javadoc to record this. JEP: http://openjdk.java.net/jeps/8207851 webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.06 I also made one small, additional correction to the implementation. When force(int,int) is called with a non-SYNC buffer it is expected to redirect to force0. The address arg passed in this call was being computed by adding the supplied offset to buffer start address. However, the underlying implementation of force0 calls msync which requires a page-aligned address. The latest version rounds down the computed address to a page boundary. It also increments length by the amount thus subtracted, ensuring all the bytes in the requested range are written back. 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, Eric Shander From goetz.lindenmaier at sap.com Thu Feb 21 12:57:00 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Feb 2019 12:57:00 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <1794675000.777446.1550672259479.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Andrew, thanks for giving this advice! It confirms the problems I see. For the context: I proposed better NPE exception messages: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/ The original implementation is C++ and walks the metaspace given the method* and BCI where the exception occurred. So it uses only data already sitting in memory. See JVM_GetExtendedNPEMessage() in jvm.cpp. The idea was to implement this in Java using StackWalker and ASM. If I had the right bytecodes, and the right starting point, ASM would be helpful to implement the analysis I think. I'll look some more into the reconstituter code... Thanks, Goetz. > -----Original Message----- > From: Andrew Dinn > Sent: Mittwoch, 20. Februar 2019 18:29 > To: Lindenmaier, Goetz > Cc: core-libs-dev ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > Hi Goetz, > > Forgive me for jumping in here and, possibly, misunderstanding what you > want -- I may have misunderstood what you are trying to do as I have not > been following this thread carefully. > > On 20/02/2019 16:36, Lindenmaier, Goetz wrote: > > 1. As I understand, it would be simple to extend ASM to deliver the initial > > BCIs when the stream is parsed. They could be stored separately and > > discarded once something gets modified (similar to InsnList.cache). > > Non-method bytecodes are normally dropped by the JVM during parsing. > Only method bytecode is retained in the metadata model. One exception is > when a registered ClassFileTransformer changes the loaded bytecode at > load time. The original bytecode for the class is saved when that happens. > > Note that retaining method bytecode does not imply retaining the > original classpool in bytecode format. Indices into the classpool are > interpreted as indices into a metadata version of the classpool. Amongst > other things, that allows sharing of symbols that occur in more than one > class files. This avoids a /vast/ amount of storage costs. > > > 2. Is there any possibility to access the live datastructures/bytecode in the > VM? > > I was pointed to former JvmtiClassFileReconstitutor ... something like that? > JvmtiClassFileReconstitutor exists precisely to recreate the full class > bytecode from the metadata when needed. I believe it is only ever needed > to allow a ClassFileTransformer to retransform a loaded class that was > not transformed at load time. Using it seems like overkill to me (also > see below). If you want to locate a specific bytecode instruction in a > method you should be able to do so by pulling the method bytecodes out > of the metadata. > > Also, if you want your message to reflect the bytecode that is actually > in use when the exception occurs then you really need to do it by > pulling the bytecodes out of the method metadata. The bytecode returned > by JvmtiClassFileReconstitutor will not include any bytecode changes > that were installed by a ClassFileTransformer. > > However, this is a potential can of worms because old and new versions > of a method and associated bytecode can exist at the same time. You need > to be sure which version of the method and, hence, bytecode the > exception was generated from. If you are trying to do this from Java by > calling into the JVM then I think you are going to have problems. > > 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, Eric Shander From adinn at redhat.com Thu Feb 21 14:02:01 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 21 Feb 2019 14:02:01 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <1794675000.777446.1550672259479.JavaMail.zimbra@u-pem.fr> Message-ID: On 21/02/2019 12:57, Lindenmaier, Goetz wrote: > thanks for giving this advice! It confirms the problems I see. You are welcome. > For the context: > The idea was to implement this in Java using StackWalker and > ASM. If I had the right bytecodes, and the right starting point, > ASM would be helpful to implement the analysis I think. Ok. However, if you have the appropriate method bytecodes and the BCI at which the exception occurred then I'm not sure why you would need ASM. Also, it was not strictly correct when I said all that is retained is the method bytecodes. Exception tables, line number tables and local var name & type tables are also retained. 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, Eric Shander From goetz.lindenmaier at sap.com Thu Feb 21 14:27:29 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Feb 2019 14:27:29 +0000 Subject: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <7c4b0bc27961471e91195bef9e767226@sap.com> <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com> <01361236-c046-0cac-e09d-be59ea6499e0@oracle.com> <2d38e96dcd214dd091f4d79d2a9e71e3@sap.com> <1794675000.777446.1550672259479.JavaMail.zimbra@u-pem.fr> Message-ID: <776b45816d3646b485effb69ec9a134a@sap.com> Hi Andrew, > Ok. However, if you have the appropriate method bytecodes and the BCI at > which the exception occurred then I'm not sure why you would need ASM. I implemented it in C++ at first. I was asked to investigate an implementation in Java by the reviewers. Thanks! Goetz > Also, it was not strictly correct when I said all that is retained is > the method bytecodes. Exception tables, line number tables and local var > name & type tables are also retained. > > 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, Eric Shander From christoph.langer at sap.com Thu Feb 21 15:04:40 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 21 Feb 2019 15:04:40 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> Message-ID: <953449f0913340f6a94ae3d83611fd92@sap.com> Hi Alan, here is the next iteration: http://cr.openjdk.java.net/~clanger/webrevs/8213031.7/ I focused on your comments regarding implementation details: > I'm not sure about using ${user.name} and "" as default. > Have you looked at using the zip file owner/group (or owner/owner on > Windows) as the default?? Also just wondering if 777 might be more > appropriate (maybe you have a reason for choosing 660?). It might be > useful to see what Linux, macOS and other operating systems do when > mounting a FAT file system. I'm using Files.getOwner() now as well as the default of 777 for permissions. > Did you consider using the string representation of the user, group and > permissions in the configuration properties? The zip file system > provider could support both of course. String might make it a bit easier > to create the map of configuration properties when creating the file > system e.g > Map.of("enablePosixPermissions", "true", "defaultOwner", "joe", > "defaultPermissions", "rw-rw---"); Implemented. I also added Lance's suggestions to the test. Are there other major implementation points left? If not I guess we should start refining the documentation... Thanks Christoph From naoto.sato at oracle.com Thu Feb 21 15:48:09 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 21 Feb 2019 07:48:09 -0800 Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 In-Reply-To: <400181fb-4e53-3a84-7cc6-cca85bc7207b@oracle.com> References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default> <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default> <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com> <672daacf-f12e-47a5-af14-b7ac054a3f1c@default> <1bfebd99-bbf4-0a6c-e0e3-7dd8cda73911@oracle.com> <62567a03-7473-4651-b1b3-a338629c6666@default> <400181fb-4e53-3a84-7cc6-cca85bc7207b@oracle.com> Message-ID: <8c9ec321-3ed9-1224-0b51-53b0300cbe13@oracle.com> +1 Please follow the appropriate process to push the changeset. Naoto On 2/21/19 2:24 AM, Se?n Coffey wrote: > Thanks. Looks good to me. > > regards, > Sean. > > On 21/02/2019 09:10, Deepak Kejriwal wrote: >> >> Hi Sean, >> >> The webrev I shared was not correct. I have corrected the webrev.02 >> now. Please check now:- >> >> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/ >> >> Regards, >> >> Deepak >> >> *From:*Se?n Coffey >> *Sent:* Thursday, February 21, 2019 2:11 PM >> *To:* Deepak Kejriwal ; Naoto Sato >> ; core-libs-dev >> ; jdk-updates-dev at openjdk.java.net >> *Subject:* Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 >> >> Deepak, >> >> this exception message in new test still needs correction: >> >> 166???????????????????????? "Character.isLetter(int) failed for codepoint " >> >> 167???????????????????????????????? + Integer.toHexString(cp)); >> >> As an aside, there's probably no need for such specific exception >> messages in a test case. It's error prone (but you've come this far now) >> >> regards, >> Sean. >> >> On 21/02/2019 08:26, Deepak Kejriwal wrote: >> >> Hi Naoto, >> >> Corrected the exception message. Please find below updated version of webrev:- >> >> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/ >> >> Thanks for review. >> >> Regards, >> >> Deepak >> >> -----Original Message----- >> >> From: Naoto Sato >> >> Sent: Wednesday, February 20, 2019 11:06 PM >> >> To: Deepak Kejriwal ; Sean Coffey ; core-libs-dev ;jdk-updates-dev at openjdk.java.net >> >> Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 >> >> Hi Deepak, >> >> I see the following comment is not addressed yet: >> >> > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). >> >> Naoto >> >> On 2/20/19 8:53 AM, Deepak Kejriwal wrote: >> >> Thanks Naoto San and Sean for review. I have incorporate all the >> >> comments. Please find below updated version of webrev :- >> >> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/ >> >> Regards, >> >> Deepak >> >> -----Original Message----- >> >> From: Naoto Sato >> >> Sent: Tuesday, February 19, 2019 10:23 PM >> >> To: Deepak Kejriwal ; core-libs-dev >> >> ;jdk-updates-dev at openjdk.java.net >> >> Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 >> >> Hi Deepak, >> >> Here are my comments to the webrev (other than what Sean pointed out): >> >> TestIsJavaIdentifierMethods.java >> >> - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit". >> >> - Line 34: "newCodePoint" does not represent the era character, as "new" >> >> is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"? >> >> - Line 67,68,(...all the comments): Reflect the above change to the comments. >> >> - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct. >> >> It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions. >> >> - Line 104: The test case returns "void", what does this "Expected results" mean? >> >> - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int): >> >> ???? isLetter(codePoint) returns true >> >> ???? getType(codePoint) returns LETTER_NUMBER >> >> ???? the referenced character is a currency symbol (such as '$') >> >> ???? the referenced character is a connecting punctuation character (such as '_'). >> >> - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart(). >> >> Naoto >> >> On 2/19/19 6:15 AM, Deepak Kejriwal wrote: >> >> Correcting typo for release. >> >> >> >> From: Deepak Kejriwal >> >> Sent: Tuesday, February 19, 2019 7:42 PM >> >> To: 'core-libs-dev' ; >> >> 'jdk-updates-dev at openjdk.java.net ' >> >> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 >> >> >> >> Hi All, >> >> Please review the backport of the following bug fixes to jdk11u-dev: >> >> HYPERLINK >> >> "https://bugs.openjdk.java.net/browse/JDK-8206120" JDK-8206120 : Add >> >> test cases for lenient Japanese era parsing HYPERLINK >> >> "https://bugs.openjdk.java.net/browse/JDK-8211398" JDK-8211398 : >> >> Square character support for the Japanese new era HYPERLINK >> >> "https://bugs.openjdk.java.net/browse/JDK-8218915" JDK-8218915 : >> >> Change isJavaIdentifierStart and isJavaIdentifierPart to handle new >> >> code points >> >> Webrev: >> >> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ >> >> These code changes are made possible thanks to specification change already pushed: >> >> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace >> >> Regards, >> >> Deepak >> >> >> From naoto.sato at oracle.com Thu Feb 21 15:48:51 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 21 Feb 2019 07:48:51 -0800 Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 In-Reply-To: References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default> <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com> <6a3ff77d-ac17-b072-83e5-7b91c4163be4@oracle.com> <87fb7fb1-eb11-4b5a-a026-b0bf0da57327@default> Message-ID: <32827b53-a6eb-0f1b-7781-5addef2598b4@oracle.com> +1 Please follow the appropriate process to push the changeset. Naoto On 2/21/19 2:27 AM, Se?n Coffey wrote: > Looks good. > > regards, > Sean. > > On 21/02/2019 08:54, Deepak Kejriwal wrote: >> Hi Naoto, >> >> Corrected the exception message. Please find below updated version of >> webrev:- >> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.02/ >> >> >> >> Thanks for review. >> >> Regards, >> Deepak >> >> -----Original Message----- >> From: Naoto Sato >> Sent: Wednesday, February 20, 2019 11:07 PM >> To: Deepak Kejriwal ; Sean Coffey >> ; core-libs-dev >> ; jdk8u-dev at openjdk.java.net >> Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, >> JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 >> >> Hi Deepak, >> >> The same comment for 11u can be applied here too: >> >> ? > - Line 163,198: Exception messages are incorrect. they are for >> isJavaIdentifierStart(). >> >> Naoto >> >> On 2/20/19 8:57 AM, Deepak Kejriwal wrote: >>> Thanks Naoto San and Sean for review. I have incorporate all the >>> comments. Please find below updated version of webrev :- >>> >>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u >>> /webrev.01/ >>> >>> Regards, >>> Deepak >>> >>> -----Original Message----- >>> From: Naoto Sato >>> Sent: Tuesday, February 19, 2019 10:40 PM >>> To: Deepak Kejriwal ; core-libs-dev >>> ; jdk8u-dev at openjdk.java.net >>> Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, >>> JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 >>> >>> Hi Deepak, >>> >>> Almost all the comments for the 11u changes [1] applies here, except >>> the "newCodePoint" comment. For this one, I'd suggest renaming >>> "newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2" >>> >>> Naoto >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/05 >>> 8610.html >>> >>> On 2/19/19 5:55 AM, Deepak Kejriwal wrote: >>>> Hi All, >>>> >>>> Please review the backport of the following bug fixes to jdk8u-dev: >>>> >>>> HYPERLINK >>>> "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: >>>> Japanese new era implementation. >>>> HYPERLINK >>>> "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: >>>> Placeholder for Japanese new era should be two characters. >>>> HYPERLINK >>>> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : >>>> Square character support for the Japanese new era HYPERLINK >>>> "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong >>>> short form text for supplemental Japanese era HYPERLINK >>>> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add >>>> test cases for lenient Japanese era parsing HYPERLINK >>>> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : >>>> Change isJavaIdentifierStart and isJavaIdentifierPart to handle new >>>> code points HYPERLINK >>>> "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 >>>> currency code points to Java SE 8uX >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8 >>>> u >>>> /webrev.00/ >>>> >>>> These code changes are made possible thanks to specification changes >>>> already pushed: >>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a >>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7 >>>> >>>> Regards, >>>> Deepak >>>> >>>> >>>> >>>> From Roger.Riggs at oracle.com Thu Feb 21 16:49:07 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 21 Feb 2019 11:49:07 -0500 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: References: Message-ID: Hi Andrew, I can sponsor; it looks correct to me. Any other reviewers? Thanks, Roger On 02/19/2019 11:24 AM, Andrew Leonard wrote: > Please can I request a sponsor for this fix to ReflectionFactory where > langReflectAccess is not always correctly initialized. > Webrev: http://cr.openjdk.java.net/~aleonard/8219378/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8219378 > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > 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 Alan.Bateman at oracle.com Thu Feb 21 16:57:20 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2019 16:57:20 +0000 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: References: Message-ID: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> On 21/02/2019 16:49, Roger Riggs wrote: > Hi Andrew, > > I can sponsor; it looks correct to me. > > Any other reviewers? It looks right but would be good to have a test case that demonstrates the issue. -Alan From naoto.sato at oracle.com Thu Feb 21 17:06:40 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 21 Feb 2019 09:06:40 -0800 Subject: [13] RFR: 8218960: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO In-Reply-To: <1b9e6ab6-38af-d775-3526-392bd402fe8e@oracle.com> References: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> <82b5aa63-75e6-3a01-7f53-fd4dc389676d@oracle.com> <5c858614-ea1f-cc7a-e98b-3ac8c3379db1@oracle.com> <1b9e6ab6-38af-d775-3526-392bd402fe8e@oracle.com> Message-ID: Hi Roger, Sorry for the missing the bug id in the subject, added it. Better late than never :-) On 2/20/19 6:41 PM, Roger Riggs wrote: > Hi Naoto, > > The fix looks fine. > > The direction for new tests is to give them functional names, not bugids. > Is there a suitable name? Renamed the test case, and modified @summary text accordingly. > > CalendarDataUtility.java: 260;? the assert is just documentation right? > Its rare to see asserts enabled except in test contexts. Yes, it's meant for jtreg environment so that they are logged (if ever). Updated webrev: http://cr.openjdk.java.net/~naoto/8218960/webrev.01/ Naoto > > Thanks, Roger > > > On 2/20/19 5:54 PM, naoto.sato at oracle.com wrote: >> Thanks, Nishit. >> >> I'd still like to ask for a review from a Reviewer. >> >> Naoto >> >> On 2/20/19 12:33 AM, Nishit Jain wrote: >>> Hi Naoto, >>> >>> Thanks for the explanation. Change looks fine to me. >>> >>> Regards, >>> Nishit Jain >>> On 19-02-2019 22:51, Naoto Sato wrote: >>>> Hi Nishit, >>>> >>>> The reason is that "US" is the only required locale in the JDK (cf. >>>> Locale.getAvailableLocales(). In fact, initially I supplied "001" >>>> with it, as it means the "world" in CLDR, but it broke some existing >>>> tests. "001" returns "MONDAY" as the first day of week, whereas >>>> "SUNDAY" in US. For the compatibility reason, I had to resort to >>>> "US". I am not sure we want to hardcode "1" in this case without any >>>> convincing reason. >>>> >>>> Naoto >>>> >>>> On 2/19/19 6:37 AM, Nishit Jain wrote: >>>>> Hi Naoto, >>>>> >>>>> Why is the default region set to "US" if there is no region >>>>> specified in the locale? is this the default behavior of "first day >>>>> of week" and "minimal days in first week" when a region is missing >>>>> or the default behavior is that it returns "1"? Can't we just >>>>> return "1" instead of setting the region to "US"? >>>>> >>>>> Regards, >>>>> Nishit Jain >>>>> On 16-02-2019 04:25, Naoto Sato wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the fix to the following issue: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8218960 >>>>>> >>>>>> The proposed changeset is located at: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ >>>>>> >>>>>> The CONFIG message was generated because >>>>>> CLDRCalendarDataProviderImpl was returning null for locales >>>>>> without region. Use "US" as the default region in such a case. >>>>>> >>>>>> Naoto >>>>> >>> > From mandy.chung at oracle.com Thu Feb 21 17:37:54 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 21 Feb 2019 09:37:54 -0800 Subject: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields In-Reply-To: References: <9a9e3212-6e12-bccc-2405-c32016ba2d8d@oracle.com> <1fca19fa-4621-f560-fd2a-7fb55b375ad8@oracle.com> <12e2cb29-57de-f641-6eb0-6d194c77fcdc@oracle.com> <528279fd-f2a8-87c8-ad15-566c0c29c2db@oracle.com> Message-ID: Hi Adam, On 2/14/19 3:16 AM, Adam Farley8 wrote: > Hi Mandy, > > Apologies for the delay. Same here as I returned from vacation yesterday. > Could you review this cdiff as a proposal for the jtreg test? > > Made sense to modify the existing test set for MethodHandle rather than > add a new one. Yes it'd be better if you extend the MethodHandlesGeneralTest and MethodHandlesTest to test the write access. To add the test cases properly, MethodHandlesTest.HasFields should be modified to include the read-only fields. It might be cleaner to add a new HasReadOnlyFields class and maybe a new TEST_SET_ACCESSIBLE bit that requests to call setAccessible(true) and testSetter expects unreflectSetter to throw exception on static final fields (possibly additional bits might be needed). Mandy From dmitry.chuyko at bell-sw.com Thu Feb 21 17:55:56 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 21 Feb 2019 20:55:56 +0300 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> Message-ID: To me thread function wrappers look preferable to platform specific JavaMain signature. Consider this webrev with wrappers: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ In some cases JavaMain is called in the same thread and its result is returned from JLI_Launch. ContinueInNewThread is in shared code. And JavaMain uses macro controlled returns. So when JavaMain returns THREAD_FUNC_RETURN changes may contain some quite artificial macro parts in java.c: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ -Dmitry On 12/19/18 9:27 AM, David Holmes wrote: > On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >> On 12/18/18 3:39 AM, David Holmes wrote: >>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a small fix in java_md_solinux.c: continuation is >>>>>> not truly compatible with pthread_create start_routine's >>>>>> signature but we control what actually happens. So it makes sense >>>>>> to add intermediate void* cast to silence the error. >>>>> >>>>> I'd be tempted to fix the signature and get rid of all the casts. >>>> >>>> David, the signature is a signature of >>>> >>>> int JNICALL JavaMain(void * _args) >>>> >>>> It would be fun to change it. But still on Windows it is correctly >>>> passed to _beginthreadex() and then return code is extracted with >>>> GetExitCodeThread(). In case we want it to return void* the cast >>>> will move there. >>> >>> I think the current double cast is truly ugly and an ifdef for >>> windows, or a cast for Windows only would be an improvement. >> >> I agree. Maybe making a wrapper function is not so ugly. If there are >> no objections to changing beginning of the call stack it is quite >> easy to implement. For consistency it may be done for all 3 points >> (posix unix, posix mac, windows) or just for posix ones. >> >> It looks like ifdef should be better as long as there are already >> OS-specific parts in libjli. Again, if there are no objections to >> have different JavaMain signatures on different platforms. In this >> case there won't be a signature cast for Windows. > > How about setting > > #define THREAD_FUNC_RETURN int > > in windows/java_md.h. > > Then: > > #ifndef THREAD_FUNC_RETURN > ? #define THREAD_FUNC_RETURN void* > #endif > > in java.h (after the other includes). > > Then: > > THREAD_FUNC_RETURN JNICALL > JavaMain(void * _args) > > in java.c. > > ? > > Cheers, > David > > >> >> -Dmitry >> >>> >>> But I won't impose that on you just to silence gcc 8. >>> >>> Cheers, >>> David >>> >>>> -Dmitry >>>> >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>> testing: submit repo >>>>>> (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>>> >>>>>> -Dmitry >>>>>> From Roger.Riggs at oracle.com Thu Feb 21 18:07:14 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 21 Feb 2019 13:07:14 -0500 Subject: [13] RFR: 8218960: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO In-Reply-To: References: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> <82b5aa63-75e6-3a01-7f53-fd4dc389676d@oracle.com> <5c858614-ea1f-cc7a-e98b-3ac8c3379db1@oracle.com> <1b9e6ab6-38af-d775-3526-392bd402fe8e@oracle.com> Message-ID: <9ffef2ff-6b8d-baad-09aa-eee4330ead6a@oracle.com> Thanks for the updates,? Looks good. On 02/21/2019 12:06 PM, Naoto Sato wrote: > Hi Roger, > > Sorry for the missing the bug id in the subject, added it. Better late > than never :-) > > On 2/20/19 6:41 PM, Roger Riggs wrote: >> Hi Naoto, >> >> The fix looks fine. >> >> The direction for new tests is to give them functional names, not >> bugids. >> Is there a suitable name? > > Renamed the test case, and modified @summary text accordingly. > >> >> CalendarDataUtility.java: 260;? the assert is just documentation right? >> Its rare to see asserts enabled except in test contexts. > > Yes, it's meant for jtreg environment so that they are logged (if ever). > > Updated webrev: http://cr.openjdk.java.net/~naoto/8218960/webrev.01/ > > Naoto > >> >> Thanks, Roger >> >> >> On 2/20/19 5:54 PM, naoto.sato at oracle.com wrote: >>> Thanks, Nishit. >>> >>> I'd still like to ask for a review from a Reviewer. >>> >>> Naoto >>> >>> On 2/20/19 12:33 AM, Nishit Jain wrote: >>>> Hi Naoto, >>>> >>>> Thanks for the explanation. Change looks fine to me. >>>> >>>> Regards, >>>> Nishit Jain >>>> On 19-02-2019 22:51, Naoto Sato wrote: >>>>> Hi Nishit, >>>>> >>>>> The reason is that "US" is the only required locale in the JDK >>>>> (cf. Locale.getAvailableLocales(). In fact, initially I supplied >>>>> "001" with it, as it means the "world" in CLDR, but it broke some >>>>> existing tests. "001" returns "MONDAY" as the first day of week, >>>>> whereas "SUNDAY" in US. For the compatibility reason, I had to >>>>> resort to "US". I am not sure we want to hardcode "1" in this case >>>>> without any convincing reason. >>>>> >>>>> Naoto >>>>> >>>>> On 2/19/19 6:37 AM, Nishit Jain wrote: >>>>>> Hi Naoto, >>>>>> >>>>>> Why is the default region set to "US" if there is no region >>>>>> specified in the locale? is this the default behavior of "first >>>>>> day of week" and "minimal days in first week" when a region is >>>>>> missing or the default behavior is that it returns "1"? Can't we >>>>>> just return "1" instead of setting the region to "US"? >>>>>> >>>>>> Regards, >>>>>> Nishit Jain >>>>>> On 16-02-2019 04:25, Naoto Sato wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review the fix to the following issue: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8218960 >>>>>>> >>>>>>> The proposed changeset is located at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ >>>>>>> >>>>>>> The CONFIG message was generated because >>>>>>> CLDRCalendarDataProviderImpl was returning null for locales >>>>>>> without region. Use "US" as the default region in such a case. >>>>>>> >>>>>>> Naoto >>>>>> >>>> >> From Roger.Riggs at oracle.com Thu Feb 21 18:09:16 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 21 Feb 2019 13:09:16 -0500 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> Message-ID: <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> Hi Andrew, Is there a test case?? Since the initialization is a side effect of static initialization, it might be hard to trigger just one of those paths.? How was it discovered? Thanks, Roger On 02/21/2019 11:57 AM, Alan Bateman wrote: > On 21/02/2019 16:49, Roger Riggs wrote: >> Hi Andrew, >> >> I can sponsor; it looks correct to me. >> >> Any other reviewers? > It looks right but would be good to have a test case that demonstrates > the issue. > > -Alan From mikael.vidstedt at oracle.com Thu Feb 21 18:55:16 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 21 Feb 2019 10:55:16 -0800 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> Message-ID: <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> The wrapper based solution looks much cleaner to me as well. webrev.01 looks good. (not a Reviewer) Cheers, Mikael > On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko wrote: > > To me thread function wrappers look preferable to platform specific JavaMain signature. Consider this webrev with wrappers: > > http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ > > In some cases JavaMain is called in the same thread and its result is returned from JLI_Launch. ContinueInNewThread is in shared code. And JavaMain uses macro controlled returns. > So when JavaMain returns THREAD_FUNC_RETURN changes may contain some quite artificial macro parts in java.c: > > http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ > > -Dmitry > > On 12/19/18 9:27 AM, David Holmes wrote: >> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >>> On 12/18/18 3:39 AM, David Holmes wrote: >>>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review a small fix in java_md_solinux.c: continuation is not truly compatible with pthread_create start_routine's signature but we control what actually happens. So it makes sense to add intermediate void* cast to silence the error. >>>>>> >>>>>> I'd be tempted to fix the signature and get rid of all the casts. >>>>> >>>>> David, the signature is a signature of >>>>> >>>>> int JNICALL JavaMain(void * _args) >>>>> >>>>> It would be fun to change it. But still on Windows it is correctly passed to _beginthreadex() and then return code is extracted with GetExitCodeThread(). In case we want it to return void* the cast will move there. >>>> >>>> I think the current double cast is truly ugly and an ifdef for windows, or a cast for Windows only would be an improvement. >>> >>> I agree. Maybe making a wrapper function is not so ugly. If there are no objections to changing beginning of the call stack it is quite easy to implement. For consistency it may be done for all 3 points (posix unix, posix mac, windows) or just for posix ones. >>> >>> It looks like ifdef should be better as long as there are already OS-specific parts in libjli. Again, if there are no objections to have different JavaMain signatures on different platforms. In this case there won't be a signature cast for Windows. >> >> How about setting >> >> #define THREAD_FUNC_RETURN int >> >> in windows/java_md.h. >> >> Then: >> >> #ifndef THREAD_FUNC_RETURN >> #define THREAD_FUNC_RETURN void* >> #endif >> >> in java.h (after the other includes). >> >> Then: >> >> THREAD_FUNC_RETURN JNICALL >> JavaMain(void * _args) >> >> in java.c. >> >> ? >> >> Cheers, >> David >> >> >>> >>> -Dmitry >>> >>>> >>>> But I won't impose that on you just to silence gcc 8. >>>> >>>> Cheers, >>>> David >>>> >>>>> -Dmitry >>>>> >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>>> testing: submit repo (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>>>> >>>>>>> -Dmitry >>>>>>> From edoardo at aspix.it Wed Feb 20 18:57:16 2019 From: edoardo at aspix.it (Edoardo Panfili) Date: Wed, 20 Feb 2019 19:57:16 +0100 Subject: can't create an image using jpackage and javafx Message-ID: <4b29d567-e037-6960-177a-6d9f37a59826@aspix.it> Hi, I'm trying to create an image of an application that uses JavaFX on macOS The builds goes well but when I try to launch the application the result is "LSOpenURLsWithRole() failed with error -10810 for the file /Users/edoardo/Desktop/java-next/workspace/asteroidi/Asteroids.app." the project is a single module and a single file application (with some resources) I try to explain how I build the package: $PATH_TO_J12/java --version openjdk 12 2019-03-19 OpenJDK Runtime Environment (build 12+32) OpenJDK 64-Bit Server VM (build 12+32, mixed mode, sharing) $PATH_TO_J12/javac --module-path $PATH_TO_FX -d mods/asteroidi $(find src/ -name "*.java") cp src/gioco/!(*.java) mods/asteroidi/gioco/ $PATH_TO_J12/java --module-path "$PATH_TO_FX:mods" -m asteroidi/gioco.Angoli all goes well, the application works correctly If I use jlink to build the package all works fine. $PATH_TO_J13/jpackage --version jpackage version 13-internal $PATH_TO_J13/jpackage create-image --output . --name Asteroids --main-class gioco.Angoli --module asteroidi --module-path $PATH_TO_FX_MODS:mods with a double click on the Asteroid application in finder nothing happens using "open Asteroids.app" from the terminal LSOpenURLsWithRole() failed with error -10810 for the file /Users/edoardo/Desktop/java-next/asteroidi/Asteroids.app. Reagards Edoardo From igor.ignatyev at oracle.com Thu Feb 21 19:53:10 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Feb 2019 11:53:10 -0800 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> Message-ID: > On Feb 21, 2019, at 12:11 AM, David Holmes wrote: > > Hi Igor, > > On 21/02/2019 3:19 pm, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>> 40 lines changed: 17 ins; 2 del; 21 mod; >> Hi all, >> could you please review this small patch which moves tests from test/jdk/vm? > > I find some of these tests - the runtime ones at least - of extremely dubious value. They either cover basic functionality that is already well covered, or are regression tests for bugs in code that hasn't existed for many many years! as I wrote in another related email: "one of the reason I'm proposing this move is exactly questionable value of these tests, I want to believe that having these tests in hotspot/ test directories will bring more attention to them from corresponding component teams and hence they will be removed/reworked/re-whatever faster and better. and I also believe that one of the reason we got duplications exactly because these tests were located in jdk test suite." > BTW: > > test/hotspot/jtreg/runtime/ShiftTest.java > > is actually a jit test according to the test comment. sure, I will move it to hotspot/compiler. > >> there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test > > No its a JNI invocation API test - nothing to do with our launcher. It belongs in runtime/jni. But we already have tests in runtime that use the JNI invocation API so this test adds no new coverage. this is actually was my first reaction, and I even have the webrev which moves it to runtime/jni, but then I looked at the associated bug and it is filed against tools/launcher. and I even got a false (as I know by now) memory that I saw JLI_ method being called from the test. there is actually another test (dk/tools/launcher/exeJliLaunchTest.c) associated w/ this bug which calls JLI_Launch. anyhow, I'll move this test to hotspot/runtime/jni. > I really think the value of these tests needs to be examined before they are brought over. I'd prefer to have follow-up RFEs/tasks, b/c the longer we keep jdk/vm directory the more tests can end up there and the more rotten these tests become. Thanks, -- Igor > > Thanks, > David > ----- > >> and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. >> webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 >> testing: tier[1-2] (in progress), all the touched tests locally >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Thu Feb 21 19:55:51 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Feb 2019 11:55:51 -0800 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> Message-ID: > On Feb 21, 2019, at 12:19 AM, Alan Bateman wrote: > On 21/02/2019 05:19, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>> 40 lines changed: 17 ins; 2 del; 21 mod; >> Hi all, >> >> could you please review this small patch which moves tests from test/jdk/vm? >> >> there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 >> testing: tier[1-2] (in progress), all the touched tests locally >> > The tools/launcher directory is the tests for the java launcher, I don't think it's the right place for tests for the JNI invocation interface - I think that one is asking to be moved to be with the other JNI tests. Alan, you are right, this test is a JNI test and should be moved to hotspot/runtime/jni. more details in my answer to the same comment in David's email. in two words, I accidentally looked at another test. -- Igor > > -Alan From Alan.Bateman at oracle.com Thu Feb 21 20:17:21 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2019 20:17:21 +0000 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> Message-ID: <0c282875-2f0b-ed17-4a05-621bd5e0d862@oracle.com> On 21/02/2019 19:55, Igor Ignatyev wrote: > : > Alan, you are right, this test is a JNI test and should be moved to hotspot/runtime/jni. more details in my answer to the same comment in David's email. in two words, I accidentally looked at another test. > Can you double check that it is actually using the JNI invocation interface directly? I don't think we were able to find anyone in Eclipse to explain what their launcher on macOS is doing. I suspect it may be directly (or indirectly) reading the CFBundleExecutable property from Info.plist and calling the JNI_CreateJavaVM function in libjli (not libjvm). We probably need more tests in this area and also a bit more archaeology to see whether this was a supported interface in Apple's JDK. -Alan From lance.andersen at oracle.com Thu Feb 21 20:34:29 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 21 Feb 2019 15:34:29 -0500 Subject: RFR: 8219548 Re: Faulty Null-Check Suspected in ToolProvider In-Reply-To: <1550275179.2497.21.camel@paratix.ch> References: <1550266989.2497.19.camel@paratix.ch> <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> <1550275179.2497.21.camel@paratix.ch> Message-ID: Here is the webrev of the patch from Philipp. I did not change the name of the test() method as it was not necessary http://cr.openjdk.java.net/~lancea/8219548/webrev.00/ > On Feb 15, 2019, at 6:59 PM, Philipp Kunz wrote: > > Hi Lance, > > See attached patch. > > Regards, > Philipp > > > On Fri, 2019-02-15 at 18:10 -0500, Lance Andersen wrote: >> Hi Philipp >> >> This probably makes sense to update. >> >> Can you also update the ToolProviderTest.java to add a test for the changes >> >> Thank you >> >> Best >> Lance >> >>> On Feb 15, 2019, at 4:43 PM, Philipp Kunz > wrote: >>> >>> >> >> >> >> 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 mik3hall at gmail.com Thu Feb 21 21:39:50 2019 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 21 Feb 2019 15:39:50 -0600 Subject: can't create an image using jpackage and javafx In-Reply-To: <4b29d567-e037-6960-177a-6d9f37a59826@aspix.it> References: <4b29d567-e037-6960-177a-6d9f37a59826@aspix.it> Message-ID: <41C36ABE-EC80-4E15-8463-DFD1DC269C31@gmail.com> > On Feb 20, 2019, at 12:57 PM, Edoardo Panfili wrote: > > LSOpenURLsWithRole() failed with error -10810 for the file /Users/edoardo/Desktop/java-next/asteroidi/Asteroids.app. That sounds like maybe an error from the open command - not necessarily the application error. Does this from Terminal show anything different? /Users/edoardo/Desktop/java-next/asteroidi/Asteroids.app/Contents/MacOS/Asteroids From mandy.chung at oracle.com Thu Feb 21 22:22:23 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 21 Feb 2019 14:22:23 -0800 Subject: RFR: JDK-8219480: j.l.c.ClassDesc::arrayType(int rank) throws IllegalArgumentException if rank = 0 In-Reply-To: References: Message-ID: On 2/20/19 3:10 PM, Vicente Romero wrote: > Please review the simple patch to fix [1] at [2]. The patch is simply > adding a comment to the API, (javadoc) to sync it with the implementation. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8219480 > [2] http://cr.openjdk.java.net/~vromero/8219480/webrev.00/ + * @throws IllegalArgumentException if the rank is less or equal to zero or if the rank of the resulting array type is typo: s/less or equal to/less than or equal to/ This needs a CSR for the spec fix. Mandy From andy.herrick at oracle.com Fri Feb 22 00:49:14 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 21 Feb 2019 19:49:14 -0500 Subject: RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder. Message-ID: <71615f59-bc90-36b4-1c88-6e7dfafc9161@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This enhancement removes the use of jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder in favor of invoking jlink directly thru the ToolProvider interface, with associated code cleanup. [1] https://bugs.openjdk.java.net/browse/JDK-8218055 [2] http://cr.openjdk.java.net/~herrick/8218055/webrev.02 /Andy From mandy.chung at oracle.com Fri Feb 22 01:54:08 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 21 Feb 2019 17:54:08 -0800 Subject: RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder. In-Reply-To: <71615f59-bc90-36b4-1c88-6e7dfafc9161@oracle.com> References: <71615f59-bc90-36b4-1c88-6e7dfafc9161@oracle.com> Message-ID: On 2/21/19 4:49 PM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > This enhancement removes the use of > jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder in favor of > invoking jlink directly thru the ToolProvider interface, with associated > code cleanup. > > [1] https://bugs.openjdk.java.net/browse/JDK-8218055 > > [2] http://cr.openjdk.java.net/~herrick/8218055/webrev.02 I only skimmed on the patch. A couple of comments: 73 () -> new RuntimeException("link tool not found")); s/link/jlink/ Instead of RuntimeException, should this error be localized? Does jpackage require jdk.jlink? Then this would never reach. 424 Files.deleteIfExists(output); // jlink will re-create This would fail if output directory is not empty. 453 args,add("--bind-services"); s/,/. (does this compile?) jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder class is no longer needed. This should be removed. Mandy From joe.darcy at oracle.com Fri Feb 22 02:15:10 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 21 Feb 2019 18:15:10 -0800 Subject: JDK 13 RFR of JDK-8219561: Update jdeprscan to avoid the need for start-of-release changes Message-ID: <41ef2545-6715-9346-be59-917eb645e9f1@oracle.com> Hello, Internally jdeprscan initializes a set of strings of releases supporting deprecation with removal. Currently those releases are JDK 9 and subsequent values. The lists is explicitly initialized and must be updated at the start of a release, which adds to the maintenance cost of starting a new release. The update for JDK 13 was: --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Dec 13 17:01:15 2018 +0100 +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Dec 13 19:06:11 2018 +0100 @@ -106,7 +106,7 @@ ???? // Keep these updated manually until there's a compiler API ???? // that allows querying of supported releases. ???? final Set releasesWithoutForRemoval = Set.of("6", "7", "8"); -??? final Set releasesWithForRemoval = Set.of("9", "10", "11", "12"); +??? final Set releasesWithForRemoval = Set.of("9", "10", "11", "12", "13"); ???? final Set validReleases; ???? { Initializing the list more programmatically could avoid the need for an explicit update for the start of a release. Please review the patch below for the programmatic initialization: --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Feb 21 15:17:42 2019 -0800 +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Feb 21 18:01:59 2019 -0800 @@ -45,6 +45,7 @@ ?import java.util.NoSuchElementException; ?import java.util.Set; ?import java.util.Queue; +import java.util.stream.IntStream; ?import java.util.stream.Stream; ?import java.util.stream.StreamSupport; ?import java.util.jar.JarEntry; @@ -106,7 +107,12 @@ ???? // Keep these updated manually until there's a compiler API ???? // that allows querying of supported releases. ???? final Set releasesWithoutForRemoval = Set.of("6", "7", "8"); -??? final Set releasesWithForRemoval = Set.of("9", "10", "11", "12", "13"); +??? // Set.of("9", "10", "11", "12", "13"); +??? final Set releasesWithForRemoval = Set.of(// "9", "10", "11", ... +??????? IntStream.rangeClosed(9, Runtime.version().feature()) +??????? .mapToObj(Integer::toString) +??????? .toArray(String[]::new)); + ???? final Set validReleases; ???? { Thanks, -Joe From david.holmes at oracle.com Fri Feb 22 04:07:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2019 14:07:13 +1000 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> Message-ID: On 22/02/2019 4:55 am, Mikael Vidstedt wrote: > > The wrapper based solution looks much cleaner to me as well. webrev.01 looks good. Sorry I really don't like it. The wrappers obfuscate and make complicated something that is not at all complicated. I have to re-read the new code 3 times to figure out what it is even doing! All that complexity to handle the fact one platform wants to return int instead of void* ?? David ----- > (not a Reviewer) > > Cheers, > Mikael > >> On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko wrote: >> >> To me thread function wrappers look preferable to platform specific JavaMain signature. Consider this webrev with wrappers: >> >> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ >> >> In some cases JavaMain is called in the same thread and its result is returned from JLI_Launch. ContinueInNewThread is in shared code. And JavaMain uses macro controlled returns. >> So when JavaMain returns THREAD_FUNC_RETURN changes may contain some quite artificial macro parts in java.c: >> >> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ >> >> -Dmitry >> >> On 12/19/18 9:27 AM, David Holmes wrote: >>> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >>>> On 12/18/18 3:39 AM, David Holmes wrote: >>>>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review a small fix in java_md_solinux.c: continuation is not truly compatible with pthread_create start_routine's signature but we control what actually happens. So it makes sense to add intermediate void* cast to silence the error. >>>>>>> >>>>>>> I'd be tempted to fix the signature and get rid of all the casts. >>>>>> >>>>>> David, the signature is a signature of >>>>>> >>>>>> int JNICALL JavaMain(void * _args) >>>>>> >>>>>> It would be fun to change it. But still on Windows it is correctly passed to _beginthreadex() and then return code is extracted with GetExitCodeThread(). In case we want it to return void* the cast will move there. >>>>> >>>>> I think the current double cast is truly ugly and an ifdef for windows, or a cast for Windows only would be an improvement. >>>> >>>> I agree. Maybe making a wrapper function is not so ugly. If there are no objections to changing beginning of the call stack it is quite easy to implement. For consistency it may be done for all 3 points (posix unix, posix mac, windows) or just for posix ones. >>>> >>>> It looks like ifdef should be better as long as there are already OS-specific parts in libjli. Again, if there are no objections to have different JavaMain signatures on different platforms. In this case there won't be a signature cast for Windows. >>> >>> How about setting >>> >>> #define THREAD_FUNC_RETURN int >>> >>> in windows/java_md.h. >>> >>> Then: >>> >>> #ifndef THREAD_FUNC_RETURN >>> #define THREAD_FUNC_RETURN void* >>> #endif >>> >>> in java.h (after the other includes). >>> >>> Then: >>> >>> THREAD_FUNC_RETURN JNICALL >>> JavaMain(void * _args) >>> >>> in java.c. >>> >>> ? >>> >>> Cheers, >>> David >>> >>> >>>> >>>> -Dmitry >>>> >>>>> >>>>> But I won't impose that on you just to silence gcc 8. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> -Dmitry >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>>>> testing: submit repo (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> > From Alan.Bateman at oracle.com Fri Feb 22 06:36:58 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Feb 2019 06:36:58 +0000 Subject: RFR: 8219548 Re: Faulty Null-Check Suspected in ToolProvider In-Reply-To: References: <1550266989.2497.19.camel@paratix.ch> <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> <1550275179.2497.21.camel@paratix.ch> Message-ID: <87c13aa2-5906-c19d-e258-426327375ecc@oracle.com> On 21/02/2019 20:34, Lance Andersen wrote: > Here is the webrev of the patch from Philipp. I did not change the name of the test() method as it was not necessary > > http://cr.openjdk.java.net/~lancea/8219548/webrev.00/ > This looks okay to me, probably should get Jon to review as he added this API. -Alan From andrew_m_leonard at uk.ibm.com Fri Feb 22 08:49:32 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 22 Feb 2019 08:49:32 +0000 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> Message-ID: Hi Roger, I had a think about this and a testcase will be difficult, as it was found during OpenJ9 testing and occured during VM bootstrap, feel free to read further details here: https://github.com/eclipse/openj9/issues/3399#issuecomment-459004840 So the issue was discovered due to the bootstrap behaviour, it was not observed with Hotspot, however given the obvious missing initialization check logic in the class it's not to say there's an untested route with Hotspot that could hit it... I'm not sure how I could scaffold a jtreg test to replicate the same? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Roger Riggs To: core-libs-dev at openjdk.java.net, Andrew Leonard Date: 21/02/2019 18:10 Subject: Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized Hi Andrew, Is there a test case? Since the initialization is a side effect of static initialization, it might be hard to trigger just one of those paths. How was it discovered? Thanks, Roger On 02/21/2019 11:57 AM, Alan Bateman wrote: On 21/02/2019 16:49, Roger Riggs wrote: Hi Andrew, I can sponsor; it looks correct to me. Any other reviewers? It looks right but would be good to have a test case that demonstrates the issue. -Alan 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 Fri Feb 22 11:08:01 2019 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 22 Feb 2019 05:08:01 -0600 Subject: can't create an image using jpackage and javafx In-Reply-To: <21dda3d6-c3ae-a8e8-9a77-7584f3ddc83a@aspix.it> References: <4b29d567-e037-6960-177a-6d9f37a59826@aspix.it> <41C36ABE-EC80-4E15-8463-DFD1DC269C31@gmail.com> <21dda3d6-c3ae-a8e8-9a77-7584f3ddc83a@aspix.it> Message-ID: <9D2DEEC8-40C6-401C-BCED-CEFC334D6AEA@gmail.com> > On Feb 21, 2019, at 11:40 PM, Edoardo Panfili wrote: > > Il 21/02/19 22:39, Michael Hall ha scritto: >> >> >>> On Feb 20, 2019, at 12:57 PM, Edoardo Panfili > wrote: >>> >>> LSOpenURLsWithRole() failed with error -10810 for the file /Users/edoardo/Desktop/java-next/asteroidi/Asteroids.app. >> >> That sounds like maybe an error from the open command - not necessarily the application error. >> Does this from Terminal show anything different? >> >> /Users/edoardo/Desktop/java-next/asteroidi/Asteroids.app/Contents/MacOS/Asteroids >> > module asteroidi does not have a ModuleMainClass attribute, use -m / > > maybe my command to create the image was wrong? "jpackage create-image --output . --name Asteroids --main-class gioco.Angoli --module asteroidi --module-path $PATH_TO_FX_MODS:mods " > > thank you > > Edoardo > I?m not that familiar w/ modular. Someone else will have to answer that. From philipp.kunz at paratix.ch Fri Feb 22 11:16:20 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Fri, 22 Feb 2019 12:16:20 +0100 Subject: Manifest ignores last line if not terminated by line break In-Reply-To: <1550266210.2497.16.camel@paratix.ch> References: <1550266210.2497.16.camel@paratix.ch> Message-ID: <1550834180.2433.22.camel@paratix.ch> Hi, Without any impatience, but may I ask if someone has read the previous message or if there is any opinion about it? Regards, Philipp On Fri, 2019-02-15 at 22:30 +0100, Philipp Kunz wrote: > Hi, > > Manifest parsing an input stream given to the constructor or the read > method ignores the contents of the last line unless terminated with a > line break. > > In course of my attempt to fix 8217375, I found that Manifest ignores > the last line when not terminated with a line break whereas > ManifestDigester throws an exception. > Without ManifestDigester's different behavior, I'd have opted for > parsing the last line also without a line break (or the last line > being empty). > But ManifestDigester cannot easily be changed that way, too, because > the line breaks are part of the digested manifest portions. > I don't think Manifest should accept any manifests that cannot later > as well be signed and should therefore raise an error when there is > no line break at the end of a manifest. > Adding a new error condition adds potential for compatibility issues. > On the other hand, I don't think the last 'ill'-terminated line > should really be ignored silently. > A good example how things can go wrong this way is > JavaClassPathTest.java. It uses a one-line manifest without a > trailing line break and m1.jar does not contain the expected Class- > Path entry. > In the long term the best option would probably be to re-unite > Manifest's and ManifestDigester's parsing-related code the biggest > challenge of which is not to change digests and thereby break > existing jar signatures. > > Attached is a patch with a proposed fix. > > The bug number in > test/jdk/java/util/jar/Manifest/NoLineBreakAtEndOfManifestFile.java > is from another bug that lead me to it. If someone creates another > bug it can be replaced. I haven't found an existing issue that > matches. > In test/jdk/tools/launcher/modules/classpath/JavaClassPathTest.java > is a test case > testJARManifestClassPathAttribute/testClassPathAttribute which I have > no clue how this should really work. As far as I can tell the test is > and was wrong but nevertheless passes. > > Is there a chance to find a sponsor for fixing this? > > Regards, > Philipp From daniel.fuchs at oracle.com Fri Feb 22 11:23:54 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 22 Feb 2019 11:23:54 +0000 Subject: JDK 13 RFR of JDK-8219561: Update jdeprscan to avoid the need for start-of-release changes In-Reply-To: <41ef2545-6715-9346-be59-917eb645e9f1@oracle.com> References: <41ef2545-6715-9346-be59-917eb645e9f1@oracle.com> Message-ID: <2d380f07-f997-d014-e972-78b0c8aed27e@oracle.com> Looks good to me Joe! best regards, -- daniel On 22/02/2019 02:15, Joe Darcy wrote: > Hello, > > Internally jdeprscan initializes a set of strings of releases supporting > deprecation with removal. Currently those releases are JDK 9 and > subsequent values. The lists is explicitly initialized and must be > updated at the start of a release, which adds to the maintenance cost of > starting a new release. The update for JDK 13 was: > > --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu > Dec 13 17:01:15 2018 +0100 > +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu > Dec 13 19:06:11 2018 +0100 > @@ -106,7 +106,7 @@ > ???? // Keep these updated manually until there's a compiler API > ???? // that allows querying of supported releases. > ???? final Set releasesWithoutForRemoval = Set.of("6", "7", "8"); > -??? final Set releasesWithForRemoval = Set.of("9", "10", "11", > "12"); > +??? final Set releasesWithForRemoval = Set.of("9", "10", "11", > "12", "13"); > > ???? final Set validReleases; > ???? { > > > Initializing the list more programmatically could avoid the need for an > explicit update for the start of a release. Please review the patch > below for the programmatic initialization: > > --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu > Feb 21 15:17:42 2019 -0800 > +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu > Feb 21 18:01:59 2019 -0800 > @@ -45,6 +45,7 @@ > ?import java.util.NoSuchElementException; > ?import java.util.Set; > ?import java.util.Queue; > +import java.util.stream.IntStream; > ?import java.util.stream.Stream; > ?import java.util.stream.StreamSupport; > ?import java.util.jar.JarEntry; > @@ -106,7 +107,12 @@ > ???? // Keep these updated manually until there's a compiler API > ???? // that allows querying of supported releases. > ???? final Set releasesWithoutForRemoval = Set.of("6", "7", "8"); > -??? final Set releasesWithForRemoval = Set.of("9", "10", "11", > "12", "13"); > +??? // Set.of("9", "10", "11", "12", "13"); > +??? final Set releasesWithForRemoval = Set.of(// "9", "10", > "11", ... > +??????? IntStream.rangeClosed(9, Runtime.version().feature()) > +??????? .mapToObj(Integer::toString) > +??????? .toArray(String[]::new)); > + > > ???? final Set validReleases; > ???? { > > Thanks, > > -Joe > From lance.andersen at oracle.com Fri Feb 22 11:44:32 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 22 Feb 2019 06:44:32 -0500 Subject: Manifest ignores last line if not terminated by line break In-Reply-To: <1550834180.2433.22.camel@paratix.ch> References: <1550266210.2497.16.camel@paratix.ch> <1550834180.2433.22.camel@paratix.ch> Message-ID: <613A23C2-E285-41FB-A4A5-3E54C0AD3A01@oracle.com> Its on my list, just have not time to look at it > On Feb 22, 2019, at 6:16 AM, Philipp Kunz wrote: > > Hi, > > Without any impatience, but may I ask if someone has read the previous > message or if there is any opinion about it? > > Regards, > Philipp > > On Fri, 2019-02-15 at 22:30 +0100, Philipp Kunz wrote: >> Hi, >> >> Manifest parsing an input stream given to the constructor or the read >> method ignores the contents of the last line unless terminated with a >> line break. >> >> In course of my attempt to fix 8217375, I found that Manifest ignores >> the last line when not terminated with a line break whereas >> ManifestDigester throws an exception. >> Without ManifestDigester's different behavior, I'd have opted for >> parsing the last line also without a line break (or the last line >> being empty). >> But ManifestDigester cannot easily be changed that way, too, because >> the line breaks are part of the digested manifest portions. >> I don't think Manifest should accept any manifests that cannot later >> as well be signed and should therefore raise an error when there is >> no line break at the end of a manifest. >> Adding a new error condition adds potential for compatibility issues. >> On the other hand, I don't think the last 'ill'-terminated line >> should really be ignored silently. >> A good example how things can go wrong this way is >> JavaClassPathTest.java. It uses a one-line manifest without a >> trailing line break and m1.jar does not contain the expected Class- >> Path entry. >> In the long term the best option would probably be to re-unite >> Manifest's and ManifestDigester's parsing-related code the biggest >> challenge of which is not to change digests and thereby break >> existing jar signatures. >> >> Attached is a patch with a proposed fix. >> >> The bug number in >> test/jdk/java/util/jar/Manifest/NoLineBreakAtEndOfManifestFile.java >> is from another bug that lead me to it. If someone creates another >> bug it can be replaced. I haven't found an existing issue that >> matches. >> In test/jdk/tools/launcher/modules/classpath/JavaClassPathTest.java >> is a test case >> testJARManifestClassPathAttribute/testClassPathAttribute which I have >> no clue how this should really work. As far as I can tell the test is >> and was wrong but nevertheless passes. >> >> Is there a chance to find a sponsor for fixing this? >> >> Regards, >> Philipp 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 Fri Feb 22 12:06:32 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 22 Feb 2019 07:06:32 -0500 Subject: JDK 13 RFR of JDK-8219561: Update jdeprscan to avoid the need for start-of-release changes In-Reply-To: <41ef2545-6715-9346-be59-917eb645e9f1@oracle.com> References: <41ef2545-6715-9346-be59-917eb645e9f1@oracle.com> Message-ID: <0CE75F85-19E2-46A5-A7F7-4E75DAAA7B3E@oracle.com> Looks good Joe! > On Feb 21, 2019, at 9:15 PM, Joe Darcy wrote: > > Set releasesWithForRemoval = Set.of("9", "10", "11", "12", "13"); 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 nishit.jain at oracle.com Fri Feb 22 13:18:23 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 22 Feb 2019 18:48:23 +0530 Subject: [13] RFR 8209175: Handle 'B' character introduced in CLDR 33 JDK update for Burmese (my) locale Message-ID: <48a1b8bd-7053-5dc8-782a-58fd174b4280@oracle.com> Hi, Please review the fix for JDK-8209175 Bug: https://bugs.openjdk.java.net/browse/JDK-8209175 Webrev: http://cr.openjdk.java.net/~nishjain/8209175/webrev.03/ Issue: In CLDR 33 update, 'B' character has been added in date time patterns for Burmese locale, which is used to represent the day period. This character is not supported in DateTimeFormatter or SimpleDateFormat APIs, so an exception is thrown that an "unknown character is encountered" Fix: A workaround is added in which 'B' character appearing in CLDR date-time pattern is replaced with 'a' character and hence resolved with am/pm strings. This is based on the LDML specification given for 'B' character in which it falls back to 'a' character if it is not supported by any locale. Regards, Nishit Jain From andy.herrick at oracle.com Fri Feb 22 14:17:43 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 22 Feb 2019 09:17:43 -0500 Subject: RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder. In-Reply-To: References: <71615f59-bc90-36b4-1c88-6e7dfafc9161@oracle.com> Message-ID: <7c3bd743-27f2-4e73-af4e-220e411e0c4f@oracle.com> On 2/21/2019 8:54 PM, Mandy Chung wrote: > > > On 2/21/19 4:49 PM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> This enhancement removes the use of >> jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder in favor of >> invoking jlink directly thru the ToolProvider interface, with >> associated code cleanup. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8218055 >> >> [2] http://cr.openjdk.java.net/~herrick/8218055/webrev.02 > > I only skimmed on the patch.? A couple of comments: > > ? 73???????????? () -> new RuntimeException("link tool not found")); yes jlink should always exist in the JDK that jpackage is run from - I just copied this code from jpackage jtreg code, replacing jpackage with jlink.? The orElseThrow arg is unnecessary, the default NoSuchElementException is as good as this one, will change to: > ??? static final ToolProvider JLINK_TOOL = > ??????????? ToolProvider.findFirst("jlink").orElseThrow(); > > s/link/jlink/ > > Instead of RuntimeException, should this error be localized? > Does jpackage require jdk.jlink?? Then this would never reach. > > ?424???????? Files.deleteIfExists(output); // jlink will re-create > > This would fail if output directory is not empty. yes - windows and linux always pass in an empty (but already created) directory. Mac (because of the odd layout of an app image: ".../Plugins/Java.runtime/Contents/Home") will pass in a non-existant directory . AppRuntimeImageBuilder was tolerant of an empty directory, but jlink itself isn't. I had looked into not creating this dir on windows and linux, but that turned into a mess, since jlink might or might not be invoked, and the outputDir passed can be one of 3 places (this is linux or windows): //runtime - (simple create-image case) /images/-//runtime - (simple create-installer case) /images/-/ - (create-installer --runtime-installer case) Do you think I should do something else here or try to clarify this with a better comment ? > > ?453???????? args,add("--bind-services"); sorry - I fixed this between generating and posting the webrev (and forgot to re-generate) - You will see this fix in rev 03 with the other changes. > > s/,/. (does this compile?) > > jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder class is no > longer needed.? This should be removed. I had discussed this with Kevin, because I wasn't sure of the protocol for removing existing non-exported classes from the runtime, and he suggested we remove this as a follow-on cleanup bug. Do you think I should remove with this change ? /Andy > > Mandy From Roger.Riggs at oracle.com Fri Feb 22 14:42:02 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 22 Feb 2019 09:42:02 -0500 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> Message-ID: <58c49c6a-a0ff-17b2-8ab0-3635d4337dd8@oracle.com> Hi Andrew, Thanks for the references and consideration.? I agree it will be hard to reproduce. It is an obvious oversight and is localized to a single file so I don't think a test case is necessary. Thanks, Roger On 02/22/2019 03:49 AM, Andrew Leonard wrote: > Hi Roger, > I had a think about this and a testcase will be difficult, as it was > found during OpenJ9 testing and occured during VM bootstrap, feel free > to read > further details here: > https://github.com/eclipse/openj9/issues/3399#issuecomment-459004840 > So the issue was discovered due to the bootstrap behaviour, it was not > observed with Hotspot, however given the obvious missing > initialization check logic in the class it's not to say there's an > untested route with Hotspot that could hit it... I'm not sure how I > could scaffold a jtreg test to replicate the same? > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Roger Riggs > To: core-libs-dev at openjdk.java.net, Andrew Leonard > > Date: 21/02/2019 18:10 > Subject: Re: Fix proposal: JDK-8219378 NPE in > ReflectionFactory.newMethodAccessor when langReflectAccess not > initialized > ------------------------------------------------------------------------ > > > > Hi Andrew, > > Is there a test case?? Since the initialization is a side effect of > static initialization, > it might be hard to trigger just one of those paths.? How was it > discovered? > > Thanks, Roger > > > On 02/21/2019 11:57 AM, Alan Bateman wrote: > On 21/02/2019 16:49, Roger Riggs wrote: > Hi Andrew, > > I can sponsor; it looks correct to me. > > Any other reviewers? > It looks right but would be good to have a test case that demonstrates > the issue. > > -Alan > > > > 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 Alan.Bateman at oracle.com Fri Feb 22 14:50:40 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Feb 2019 14:50:40 +0000 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> Message-ID: On 22/02/2019 08:49, Andrew Leonard wrote: > Hi Roger, > I had a think about this and a testcase will be difficult, as it was found > during OpenJ9 testing and occured during VM bootstrap, Can you say if the J9 failure was with an exploded build or an images build? Just asking as suggest we could trigger this with an exploded build during startup with the right test. If it's too much work then no problem, I agree with Roger that the issue is obvious. -Alan From Roger.Riggs at oracle.com Fri Feb 22 15:32:50 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 22 Feb 2019 10:32:50 -0500 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> Message-ID: <2b7fc762-d0a6-3452-c57e-30a4447b5149@oracle.com> Hi, If the warning can be addressed with an extra in-line cast then that's cleaner and easier to understand than replicating that structure in 3 files. And of course, add a comment. To make the source more readable, the cast could be factored into a macro in the same file with the comment about why it is needed. Roger On 02/21/2019 11:07 PM, David Holmes wrote: > On 22/02/2019 4:55 am, Mikael Vidstedt wrote: >> >> The wrapper based solution looks much cleaner to me as well. >> webrev.01 looks good. > > Sorry I really don't like it. The wrappers obfuscate and make > complicated something that is not at all complicated. I have to > re-read the new code 3 times to figure out what it is even doing! > > All that complexity to handle the fact one platform wants to return > int instead of void* ?? > > David > ----- > >> (not a Reviewer) >> >> Cheers, >> Mikael >> >>> On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko >>> wrote: >>> >>> To me thread function wrappers look preferable to platform specific >>> JavaMain signature. Consider this webrev with wrappers: >>> >>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ >>> >>> In some cases JavaMain is called in the same thread and its result >>> is returned from JLI_Launch. ContinueInNewThread is in shared code. >>> And JavaMain uses macro controlled returns. >>> So when JavaMain returns THREAD_FUNC_RETURN changes may contain some >>> quite artificial macro parts in java.c: >>> >>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ >>> >>> -Dmitry >>> >>> On 12/19/18 9:27 AM, David Holmes wrote: >>>> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >>>>> On 12/18/18 3:39 AM, David Holmes wrote: >>>>>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>>>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review a small fix in java_md_solinux.c: continuation >>>>>>>>> is not truly compatible with pthread_create start_routine's >>>>>>>>> signature but we control what actually happens. So it makes >>>>>>>>> sense to add intermediate void* cast to silence the error. >>>>>>>> >>>>>>>> I'd be tempted to fix the signature and get rid of all the casts. >>>>>>> >>>>>>> David, the signature is a signature of >>>>>>> >>>>>>> int JNICALL JavaMain(void * _args) >>>>>>> >>>>>>> It would be fun to change it. But still on Windows it is >>>>>>> correctly passed to _beginthreadex() and then return code is >>>>>>> extracted with GetExitCodeThread(). In case we want it to return >>>>>>> void* the cast will move there. >>>>>> >>>>>> I think the current double cast is truly ugly and an ifdef for >>>>>> windows, or a cast for Windows only would be an improvement. >>>>> >>>>> I agree. Maybe making a wrapper function is not so ugly. If there >>>>> are no objections to changing beginning of the call stack it is >>>>> quite easy to implement. For consistency it may be done for all 3 >>>>> points (posix unix, posix mac, windows) or just for posix ones. >>>>> >>>>> It looks like ifdef should be better as long as there are already >>>>> OS-specific parts in libjli. Again, if there are no objections to >>>>> have different JavaMain signatures on different platforms. In this >>>>> case there won't be a signature cast for Windows. >>>> >>>> How about setting >>>> >>>> #define THREAD_FUNC_RETURN int >>>> >>>> in windows/java_md.h. >>>> >>>> Then: >>>> >>>> #ifndef THREAD_FUNC_RETURN >>>> ?? #define THREAD_FUNC_RETURN void* >>>> #endif >>>> >>>> in java.h (after the other includes). >>>> >>>> Then: >>>> >>>> THREAD_FUNC_RETURN JNICALL >>>> JavaMain(void * _args) >>>> >>>> in java.c. >>>> >>>> ? >>>> >>>> Cheers, >>>> David >>>> >>>> >>>>> >>>>> -Dmitry >>>>> >>>>>> >>>>>> But I won't impose that on you just to silence gcc 8. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>>>>> testing: submit repo >>>>>>>>> (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >> From mandy.chung at oracle.com Fri Feb 22 16:06:20 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Feb 2019 08:06:20 -0800 Subject: RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder. In-Reply-To: <7c3bd743-27f2-4e73-af4e-220e411e0c4f@oracle.com> References: <71615f59-bc90-36b4-1c88-6e7dfafc9161@oracle.com> <7c3bd743-27f2-4e73-af4e-220e411e0c4f@oracle.com> Message-ID: <85e94f5d-3f1f-6633-9545-bf6fd43d9684@oracle.com> On 2/22/19 6:17 AM, Andy Herrick wrote: > > > On 2/21/2019 8:54 PM, Mandy Chung wrote: >> I only skimmed on the patch.? A couple of comments: >> >> ? 73???????????? () -> new RuntimeException("link tool not found")); > yes jlink should always exist in the JDK that jpackage is run from - I > just copied this code from jpackage jtreg code, replacing jpackage with > jlink.? The orElseThrow arg is unnecessary, the default > NoSuchElementException is as good as this one, will change to: >> ??? static final ToolProvider JLINK_TOOL = >> ??????????? ToolProvider.findFirst("jlink").orElseThrow(); OK. I check that jdk.jpackage requires jdk.jlink >> >> s/link/jlink/ >> >> Instead of RuntimeException, should this error be localized? >> Does jpackage require jdk.jlink?? Then this would never reach. >> >> ?424???????? Files.deleteIfExists(output); // jlink will re-create >> >> This would fail if output directory is not empty. > yes - windows and linux always pass in an empty (but already created) > directory. Mac (because of the odd layout of an app image: > ".../Plugins/Java.runtime/Contents/Home") will pass in a non-existant > directory . > AppRuntimeImageBuilder was tolerant of an empty directory, but jlink > itself isn't. > > I had looked into not creating this dir on windows and linux, but that > turned into a mess, since jlink might or might not be invoked, and the > outputDir passed can be one of 3 places (this is linux or windows): > //runtime - (simple create-image case) > /images/-//runtime - (simple > create-installer case) > /images/-/ - > (create-installer --runtime-installer case) > > Do you think I should do something else here or try to clarify this with > a better comment ? I don't know this code. From what you describe, looks like some lurking issue. I think the code path should ensure that the dir does not exist when you call jlink Or you can jlink with a temporary output directory and rename it to the destination one. >> jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder class is no >> longer needed.? This should be removed. > I had discussed this with Kevin, because I wasn't sure of the protocol > for removing existing non-exported classes from the runtime, and he > suggested we remove this as a follow-on cleanup bug. > Do you think I should remove with this change ? You should remove this with your patch as this is an internal API. Mandy From kevin.rushforth at oracle.com Fri Feb 22 16:27:58 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 22 Feb 2019 08:27:58 -0800 Subject: RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder. In-Reply-To: <85e94f5d-3f1f-6633-9545-bf6fd43d9684@oracle.com> References: <71615f59-bc90-36b4-1c88-6e7dfafc9161@oracle.com> <7c3bd743-27f2-4e73-af4e-220e411e0c4f@oracle.com> <85e94f5d-3f1f-6633-9545-bf6fd43d9684@oracle.com> Message-ID: <37c31a29-6836-a97c-ca96-aa77257c64ae@oracle.com> On 2/22/2019 8:06 AM, Mandy Chung wrote: > > > On 2/22/19 6:17 AM, Andy Herrick wrote: >> >> >> On 2/21/2019 8:54 PM, Mandy Chung wrote: >>> I only skimmed on the patch.? A couple of comments: >>> >>> ? 73???????????? () -> new RuntimeException("link tool not found")); >> yes jlink should always exist in the JDK that jpackage is run from - >> I just copied this code from jpackage jtreg code, replacing jpackage >> with jlink.? The orElseThrow arg is unnecessary, the default >> NoSuchElementException is as good as this one, will change to: >>> ??? static final ToolProvider JLINK_TOOL = >>> ??????????? ToolProvider.findFirst("jlink").orElseThrow(); > > OK.? I check that jdk.jpackage requires jdk.jlink > >>> >>> s/link/jlink/ >>> >>> Instead of RuntimeException, should this error be localized? >>> Does jpackage require jdk.jlink?? Then this would never reach. >>> >>> ?424???????? Files.deleteIfExists(output); // jlink will re-create >>> >>> This would fail if output directory is not empty. >> yes - windows and linux always pass in an empty (but already created) >> directory. Mac (because of the odd layout of an app image: >> ".../Plugins/Java.runtime/Contents/Home") will pass in a non-existant >> directory . >> AppRuntimeImageBuilder was tolerant of an empty directory, but jlink >> itself isn't. >> >> I had looked into not creating this dir on windows and linux, but >> that turned into a mess, since jlink might or might not be invoked, >> and the outputDir passed can be one of 3 places (this is linux or >> windows): >> //runtime - (simple create-image case) >> /images/-//runtime - >> (simple create-installer case) >> /images/-/ - >> (create-installer --runtime-installer case) >> >> Do you think I should do something else here or try to clarify this >> with a better comment ? > > I don't know this code. From what you describe, looks like some lurking > issue. > > I think the code path should ensure that the dir does not exist when > you call jlink? Or you can jlink with a temporary output directory > and rename it to the destination one. > > >>> jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder class is no >>> longer needed.? This should be removed. >> I had discussed this with Kevin, because I wasn't sure of the >> protocol for removing existing non-exported classes from the runtime, >> and he suggested we remove this as a follow-on cleanup bug. >> Do you think I should remove with this change ? > > You should remove this with your patch as this is an internal API. OK, if you prefer it to go in as part of the jpackage work, then that's fine. -- Kevin > > Mandy From vicente.romero at oracle.com Fri Feb 22 16:37:55 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 22 Feb 2019 11:37:55 -0500 Subject: RFR: JDK-8219480: j.l.c.ClassDesc::arrayType(int rank) throws IllegalArgumentException if rank = 0 In-Reply-To: References: Message-ID: <923641ee-568f-07ae-7cbe-ea7faa2f8778@oracle.com> Hi Mandy, Thanks for the review. I have uploaded a new iteration [1], please also review the CSR at [2] Vicente [1] http://cr.openjdk.java.net/~vromero/8219480/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8219587 On 2/21/19 5:22 PM, Mandy Chung wrote: > > > On 2/20/19 3:10 PM, Vicente Romero wrote: >> Please review the simple patch to fix [1] at [2]. The patch is simply >> adding a comment to the API, (javadoc) to sync it with the >> implementation. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8219480 >> [2] http://cr.openjdk.java.net/~vromero/8219480/webrev.00/ > > +???? * @throws IllegalArgumentException if the rank is less or equal > to zero or if the rank of the resulting array type is > > typo: s/less or equal to/less than or equal to/ > > This needs a CSR for the spec fix. > > Mandy From edoardo at aspix.it Fri Feb 22 05:40:59 2019 From: edoardo at aspix.it (Edoardo Panfili) Date: Fri, 22 Feb 2019 06:40:59 +0100 Subject: can't create an image using jpackage and javafx In-Reply-To: <41C36ABE-EC80-4E15-8463-DFD1DC269C31@gmail.com> References: <4b29d567-e037-6960-177a-6d9f37a59826@aspix.it> <41C36ABE-EC80-4E15-8463-DFD1DC269C31@gmail.com> Message-ID: <21dda3d6-c3ae-a8e8-9a77-7584f3ddc83a@aspix.it> Il 21/02/19 22:39, Michael Hall ha scritto: > > >> On Feb 20, 2019, at 12:57 PM, Edoardo Panfili > > wrote: >> >> LSOpenURLsWithRole() failed with error -10810 for the file >> /Users/edoardo/Desktop/java-next/asteroidi/Asteroids.app. > > That sounds like maybe an error from the open command - not > necessarily the application error. > Does this from Terminal show anything different? > > /Users/edoardo/Desktop/java-next/asteroidi/Asteroids.app/Contents/MacOS/Asteroids > module asteroidi does not have a ModuleMainClass attribute, use -m / maybe my command to create the image was wrong? "jpackage create-image --output . --name Asteroids --main-class gioco.Angoli --module asteroidi --module-path $PATH_TO_FX_MODS:mods " thank you Edoardo From andy.herrick at oracle.com Fri Feb 22 17:50:46 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 22 Feb 2019 12:50:46 -0500 Subject: RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder. In-Reply-To: References: <71615f59-bc90-36b4-1c88-6e7dfafc9161@oracle.com> Message-ID: revised webrev t address issues brought up by Mandy: [2] http://cr.openjdk.java.net/~herrick/8218055/webrev.03 /Andy On 2/21/2019 8:54 PM, Mandy Chung wrote: > > > On 2/21/19 4:49 PM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> This enhancement removes the use of >> jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder in favor of >> invoking jlink directly thru the ToolProvider interface, with >> associated code cleanup. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8218055 >> >> [2] http://cr.openjdk.java.net/~herrick/8218055/webrev.02 > > I only skimmed on the patch.? A couple of comments: > > ? 73???????????? () -> new RuntimeException("link tool not found")); > > s/link/jlink/ > > Instead of RuntimeException, should this error be localized? > Does jpackage require jdk.jlink?? Then this would never reach. > > ?424???????? Files.deleteIfExists(output); // jlink will re-create > > This would fail if output directory is not empty. > > ?453???????? args,add("--bind-services"); > > s/,/. (does this compile?) > > jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder class is no > longer needed.? This should be removed. > > Mandy From mandy.chung at oracle.com Fri Feb 22 18:15:52 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Feb 2019 10:15:52 -0800 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> Message-ID: <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> Hi Andrew, Thanks for the stack trace of the issue triggering this. It seems to me that Modifier:: isn't the right place to setLangReflectAccess shared secret. It might have assumed that Modifier should have been initialized when Field/Method or other AccessibleObject is instantiated which isn't true since the modifiers field is an int. While the fix looks okay, would you mind trying a different fix moving Modifier:: to AccessibleObject? See this resolves the issue when running on J9? Mandy On 2/22/19 12:49 AM, Andrew Leonard wrote: > Hi Roger, > I had a think about this and a testcase will be difficult, as it was found > during OpenJ9 testing and occured during VM bootstrap, feel free to read > further details here: > https://github.com/eclipse/openj9/issues/3399#issuecomment-459004840 > So the issue was discovered due to the bootstrap behaviour, it was not > observed with Hotspot, however given the obvious missing initialization > check logic in the class it's not to say there's an untested route with > Hotspot that could hit it... I'm not sure how I could scaffold a jtreg > test to replicate the same? > Thanks > Andrew From mikael.vidstedt at oracle.com Fri Feb 22 18:36:37 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 22 Feb 2019 10:36:37 -0800 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: <2b7fc762-d0a6-3452-c57e-30a4447b5149@oracle.com> References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> <2b7fc762-d0a6-3452-c57e-30a4447b5149@oracle.com> Message-ID: <655CA545-ABBF-4F04-BDC8-779DB7D62880@oracle.com> Let me preface by saying that I don?t have a strong opinion about this. Like, at all. The problem with an inline cast is that it?s not necessarily correct, because it all depends on the ABI. For example, consider this case: double JavaMain(void* args) { ? return 47.11; } int ContinueInNewThread0(?) { pthread_t tid = pthread_create(?, (void (*)(void*))JavaMain, args); ? void* tmp; pthread_join(tid, &tmp); // do something with tmp } The above code will ?typically? not work, since a double isn?t returned in the same register as a void*. The added cast silences the warning, but the warning is there for a reason. Now, for most ABIs I can think of, void* and int are returned in the same register, so using a cast to silence the warning probably works for all platforms and ABIs we support today, and may well work for all platforms we ever end up supporting. Chances are also that if it doesn?t work we?ll also find pretty quickly. That said, I personally don?t like code that makes these implicit assumptions. Sooner or later it always has a tendency to bite back. Is there some way to make it more obvious what the wrapper code does perhaps? In the end though, I don?t feel strongly about this, so if the consensus is that the wrappers are that ugly and complex I?d rather add the cast and make progress on the toolchain upgrade. Cheers, Mikael > On Feb 22, 2019, at 7:32 AM, Roger Riggs wrote: > > Hi, > > If the warning can be addressed with an extra in-line cast then that's > cleaner and easier to understand than replicating that structure in 3 files. > And of course, add a comment. > To make the source more readable, the cast could be factored > into a macro in the same file with the comment about why it is needed. > > Roger > > > On 02/21/2019 11:07 PM, David Holmes wrote: >> On 22/02/2019 4:55 am, Mikael Vidstedt wrote: >>> >>> The wrapper based solution looks much cleaner to me as well. webrev.01 looks good. >> >> Sorry I really don't like it. The wrappers obfuscate and make complicated something that is not at all complicated. I have to re-read the new code 3 times to figure out what it is even doing! >> >> All that complexity to handle the fact one platform wants to return int instead of void* ?? >> >> David >> ----- >> >>> (not a Reviewer) >>> >>> Cheers, >>> Mikael >>> >>>> On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko wrote: >>>> >>>> To me thread function wrappers look preferable to platform specific JavaMain signature. Consider this webrev with wrappers: >>>> >>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ >>>> >>>> In some cases JavaMain is called in the same thread and its result is returned from JLI_Launch. ContinueInNewThread is in shared code. And JavaMain uses macro controlled returns. >>>> So when JavaMain returns THREAD_FUNC_RETURN changes may contain some quite artificial macro parts in java.c: >>>> >>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ >>>> >>>> -Dmitry >>>> >>>> On 12/19/18 9:27 AM, David Holmes wrote: >>>>> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >>>>>> On 12/18/18 3:39 AM, David Holmes wrote: >>>>>>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>>>>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review a small fix in java_md_solinux.c: continuation is not truly compatible with pthread_create start_routine's signature but we control what actually happens. So it makes sense to add intermediate void* cast to silence the error. >>>>>>>>> >>>>>>>>> I'd be tempted to fix the signature and get rid of all the casts. >>>>>>>> >>>>>>>> David, the signature is a signature of >>>>>>>> >>>>>>>> int JNICALL JavaMain(void * _args) >>>>>>>> >>>>>>>> It would be fun to change it. But still on Windows it is correctly passed to _beginthreadex() and then return code is extracted with GetExitCodeThread(). In case we want it to return void* the cast will move there. >>>>>>> >>>>>>> I think the current double cast is truly ugly and an ifdef for windows, or a cast for Windows only would be an improvement. >>>>>> >>>>>> I agree. Maybe making a wrapper function is not so ugly. If there are no objections to changing beginning of the call stack it is quite easy to implement. For consistency it may be done for all 3 points (posix unix, posix mac, windows) or just for posix ones. >>>>>> >>>>>> It looks like ifdef should be better as long as there are already OS-specific parts in libjli. Again, if there are no objections to have different JavaMain signatures on different platforms. In this case there won't be a signature cast for Windows. >>>>> >>>>> How about setting >>>>> >>>>> #define THREAD_FUNC_RETURN int >>>>> >>>>> in windows/java_md.h. >>>>> >>>>> Then: >>>>> >>>>> #ifndef THREAD_FUNC_RETURN >>>>> #define THREAD_FUNC_RETURN void* >>>>> #endif >>>>> >>>>> in java.h (after the other includes). >>>>> >>>>> Then: >>>>> >>>>> THREAD_FUNC_RETURN JNICALL >>>>> JavaMain(void * _args) >>>>> >>>>> in java.c. >>>>> >>>>> ? >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> >>>>>> >>>>>> -Dmitry >>>>>> >>>>>>> >>>>>>> But I won't impose that on you just to silence gcc 8. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>>>>>> testing: submit repo (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>> > From mikhailo.seledtsov at oracle.com Fri Feb 22 18:35:37 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 22 Feb 2019 10:35:37 -0800 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> Message-ID: ? Overall the change looks good; thank you Igor for doing this. I have couple of comments: ? - I am in favor of the approach where we move tests first under corresponding sub-component directories in ??? test/hotspot sub-tree, and then figure out whether to keep them. Even though in general I am in favor ??? of removing tests that are obsolete or of questionable value, this requires time, consideration and discussions. ??? Hence, I recommend filing an RFE for that, which can be addressed after the migration. ? - Runtime normally avoids tests directly in test/hotspot/jtreg/runtime ??? The tests should go into underlying sub-directories which best match functional area or topic of that test. ??? In most cases you did it in your change, but there are several tests that your change places directly under ???? test/hotspot/jtreg/runtime/: ???? ExplicitArithmeticCheck.java ???? MonitorCacheMaybeExpand_DeadLock.java ???? ReflectStackOverflow.java ???? ShiftTest.java - David commented this can go under compiler (a jit test) ???? WideStrictInline.java ???? Since we plan (as discussed) to follow up this work with an RFE to review and consider removal of old and ???? not-that-useful tests, you could place them under 'misc' for now. Alternatively, find the best match ???? or create new sub-directories under runtime/ if necessary. Thank you, Misha On 2/21/19 11:53 AM, Igor Ignatyev wrote: > >> On Feb 21, 2019, at 12:11 AM, David Holmes wrote: >> >> Hi Igor, >> >> On 21/02/2019 3:19 pm, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>> 40 lines changed: 17 ins; 2 del; 21 mod; >>> Hi all, >>> could you please review this small patch which moves tests from test/jdk/vm? >> I find some of these tests - the runtime ones at least - of extremely dubious value. They either cover basic functionality that is already well covered, or are regression tests for bugs in code that hasn't existed for many many years! > as I wrote in another related email: "one of the reason I'm proposing this move is exactly questionable value of these tests, I want to believe that having these tests in hotspot/ test directories will bring more attention to them from corresponding component teams and hence they will be removed/reworked/re-whatever faster and better. and I also believe that one of the reason we got duplications exactly because these tests were located in jdk test suite." > >> BTW: >> >> test/hotspot/jtreg/runtime/ShiftTest.java >> >> is actually a jit test according to the test comment. > sure, I will move it to hotspot/compiler. >>> there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test >> No its a JNI invocation API test - nothing to do with our launcher. It belongs in runtime/jni. But we already have tests in runtime that use the JNI invocation API so this test adds no new coverage. > this is actually was my first reaction, and I even have the webrev which moves it to runtime/jni, but then I looked at the associated bug and it is filed against tools/launcher. and I even got a false (as I know by now) memory that I saw JLI_ method being called from the test. there is actually another test (dk/tools/launcher/exeJliLaunchTest.c) associated w/ this bug which calls JLI_Launch. anyhow, I'll move this test to hotspot/runtime/jni. > > >> I really think the value of these tests needs to be examined before they are brought over. > I'd prefer to have follow-up RFEs/tasks, b/c the longer we keep jdk/vm directory the more tests can end up there and the more rotten these tests become. > > Thanks, > -- Igor > >> Thanks, >> David >> ----- >> >>> and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. >>> webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 >>> testing: tier[1-2] (in progress), all the touched tests locally >>> Thanks, >>> -- Igor From naoto.sato at oracle.com Fri Feb 22 18:53:15 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 22 Feb 2019 10:53:15 -0800 Subject: [13] RFR 8209175: Handle 'B' character introduced in CLDR 33 JDK update for Burmese (my) locale In-Reply-To: <48a1b8bd-7053-5dc8-782a-58fd174b4280@oracle.com> References: <48a1b8bd-7053-5dc8-782a-58fd174b4280@oracle.com> Message-ID: <5fba7e87-8e73-2c9a-d831-94a0be9df3eb@oracle.com> Hi Nishit, Looks good to me. One minor typo: Bundle.java:line 699 "SimpledateFormat" -> "SimpleDateFormat". No further review is needed for this. Naoto On 2/22/19 5:18 AM, Nishit Jain wrote: > Hi, > > Please review the fix for JDK-8209175 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209175 > Webrev: http://cr.openjdk.java.net/~nishjain/8209175/webrev.03/ > > > Issue: In CLDR 33 update, 'B' character has been added in date time > patterns for Burmese locale, which is used to represent the day period. > This character is not supported in DateTimeFormatter or SimpleDateFormat > APIs, so an exception is thrown that an "unknown character is encountered" > > Fix: A workaround is added in which 'B' character appearing in CLDR > date-time pattern is replaced with 'a' character and hence resolved with > am/pm strings. This is based on the LDML specification given for 'B' > character in which it falls back to 'a' character if it is not supported > by any locale. > > > Regards, > Nishit Jain From Roger.Riggs at oracle.com Fri Feb 22 18:55:20 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 22 Feb 2019 13:55:20 -0500 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: <2b7fc762-d0a6-3452-c57e-30a4447b5149@oracle.com> References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> <2b7fc762-d0a6-3452-c57e-30a4447b5149@oracle.com> Message-ID: <2d4ee3bd-b3e0-21d6-7868-745d94e9b354@oracle.com> Hi, After a closer look, I'd take the route of the 01 webrev. It is more localized and does not force the function signature needed by pthread_create to be propagated elsewhere. The code can be a lot more comprehensible by renaming the CallIntFunc function to be specific to ContinueInNewThread0. It looks like a trampoline to me. The data structure being passed is on the stack of the caller of pthread_create. It seems safe to refer to it here because the caller will wait in pthread_join. Also important is to document that the return type is specific to the OS and is needed to cast the return value expected by the start_pthread_create start_routine.? That may still be in question because pthread_create expects void*. $.02, Roger On 02/22/2019 10:32 AM, Roger Riggs wrote: > Hi, > > If the warning can be addressed with an extra in-line cast then that's > cleaner and easier to understand than replicating that structure in 3 > files. > And of course, add a comment. > To make the source more readable, the cast could be factored > into a macro in the same file with the comment about why it is needed. > > Roger > > > On 02/21/2019 11:07 PM, David Holmes wrote: >> On 22/02/2019 4:55 am, Mikael Vidstedt wrote: >>> >>> The wrapper based solution looks much cleaner to me as well. >>> webrev.01 looks good. >> >> Sorry I really don't like it. The wrappers obfuscate and make >> complicated something that is not at all complicated. I have to >> re-read the new code 3 times to figure out what it is even doing! >> >> All that complexity to handle the fact one platform wants to return >> int instead of void* ?? The complexity is due to the function being called in some other thread context and there is a necessary cast/type conversion on the return value from the start_routine that has to come back through pthread to pthread_join. >> >> David >> ----- >> >>> (not a Reviewer) >>> >>> Cheers, >>> Mikael >>> >>>> On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko >>>> wrote: >>>> >>>> To me thread function wrappers look preferable to platform specific >>>> JavaMain signature. Consider this webrev with wrappers: >>>> >>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ >>>> >>>> In some cases JavaMain is called in the same thread and its result >>>> is returned from JLI_Launch. ContinueInNewThread is in shared code. >>>> And JavaMain uses macro controlled returns. >>>> So when JavaMain returns THREAD_FUNC_RETURN changes may contain >>>> some quite artificial macro parts in java.c: >>>> >>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ >>>> >>>> -Dmitry >>>> >>>> On 12/19/18 9:27 AM, David Holmes wrote: >>>>> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >>>>>> On 12/18/18 3:39 AM, David Holmes wrote: >>>>>>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>>>>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review a small fix in java_md_solinux.c: continuation >>>>>>>>>> is not truly compatible with pthread_create start_routine's >>>>>>>>>> signature but we control what actually happens. So it makes >>>>>>>>>> sense to add intermediate void* cast to silence the error. >>>>>>>>> >>>>>>>>> I'd be tempted to fix the signature and get rid of all the casts. >>>>>>>> >>>>>>>> David, the signature is a signature of >>>>>>>> >>>>>>>> int JNICALL JavaMain(void * _args) >>>>>>>> >>>>>>>> It would be fun to change it. But still on Windows it is >>>>>>>> correctly passed to _beginthreadex() and then return code is >>>>>>>> extracted with GetExitCodeThread(). In case we want it to >>>>>>>> return void* the cast will move there. >>>>>>> >>>>>>> I think the current double cast is truly ugly and an ifdef for >>>>>>> windows, or a cast for Windows only would be an improvement. >>>>>> >>>>>> I agree. Maybe making a wrapper function is not so ugly. If there >>>>>> are no objections to changing beginning of the call stack it is >>>>>> quite easy to implement. For consistency it may be done for all 3 >>>>>> points (posix unix, posix mac, windows) or just for posix ones. >>>>>> >>>>>> It looks like ifdef should be better as long as there are already >>>>>> OS-specific parts in libjli. Again, if there are no objections to >>>>>> have different JavaMain signatures on different platforms. In >>>>>> this case there won't be a signature cast for Windows. >>>>> >>>>> How about setting >>>>> >>>>> #define THREAD_FUNC_RETURN int >>>>> >>>>> in windows/java_md.h. >>>>> >>>>> Then: >>>>> >>>>> #ifndef THREAD_FUNC_RETURN >>>>> ?? #define THREAD_FUNC_RETURN void* >>>>> #endif >>>>> >>>>> in java.h (after the other includes). >>>>> >>>>> Then: >>>>> >>>>> THREAD_FUNC_RETURN JNICALL >>>>> JavaMain(void * _args) >>>>> >>>>> in java.c. >>>>> >>>>> ? >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> >>>>>> >>>>>> -Dmitry >>>>>> >>>>>>> >>>>>>> But I won't impose that on you just to silence gcc 8. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>>>>>> testing: submit repo >>>>>>>>>> (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>> > From mandy.chung at oracle.com Fri Feb 22 19:37:36 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Feb 2019 11:37:36 -0800 Subject: RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder. In-Reply-To: References: <71615f59-bc90-36b4-1c88-6e7dfafc9161@oracle.com> Message-ID: <94b77c01-9a1b-cb13-24e9-ab0cf9a5b5a3@oracle.com> On 2/22/19 9:50 AM, Andy Herrick wrote: > revised webrev t address issues brought up by Mandy: > > [2] http://cr.openjdk.java.net/~herrick/8218055/webrev.03 I only looked at JLinkBundlerHelper.java and the removed files that look okay. Nit: can you use "jlink" lower case in the log/exception message (that's the tool's name). Someone else who knows this area should review. Mandy From Roger.Riggs at oracle.com Fri Feb 22 19:34:46 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 22 Feb 2019 14:34:46 -0500 Subject: [13] RFR 8209175: Handle 'B' character introduced in CLDR 33 JDK update for Burmese (my) locale In-Reply-To: <5fba7e87-8e73-2c9a-d831-94a0be9df3eb@oracle.com> References: <48a1b8bd-7053-5dc8-782a-58fd174b4280@oracle.com> <5fba7e87-8e73-2c9a-d831-94a0be9df3eb@oracle.com> Message-ID: +1 On 02/22/2019 01:53 PM, naoto.sato at oracle.com wrote: > Hi Nishit, > > Looks good to me. > > One minor typo: Bundle.java:line 699 "SimpledateFormat" -> > "SimpleDateFormat". No further review is needed for this. > > Naoto > > On 2/22/19 5:18 AM, Nishit Jain wrote: >> Hi, >> >> Please review the fix for JDK-8209175 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8209175 >> Webrev: http://cr.openjdk.java.net/~nishjain/8209175/webrev.03/ >> >> >> Issue: In CLDR 33 update, 'B' character has been added in date time >> patterns for Burmese locale, which is used to represent the day >> period. This character is not supported in DateTimeFormatter or >> SimpleDateFormat APIs, so an exception is thrown that an "unknown >> character is encountered" >> >> Fix: A workaround is added in which 'B' character appearing in CLDR >> date-time pattern is replaced with 'a' character and hence resolved >> with am/pm strings. This is based on the LDML specification given for >> 'B' character in which it falls back to 'a' character if it is not >> supported by any locale. >> >> >> Regards, >> Nishit Jain From mandy.chung at oracle.com Fri Feb 22 19:50:51 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Feb 2019 11:50:51 -0800 Subject: RFR: JDK-8219480: j.l.c.ClassDesc::arrayType(int rank) throws IllegalArgumentException if rank = 0 In-Reply-To: <923641ee-568f-07ae-7cbe-ea7faa2f8778@oracle.com> References: <923641ee-568f-07ae-7cbe-ea7faa2f8778@oracle.com> Message-ID: On 2/22/19 8:37 AM, Vicente Romero wrote: > Hi Mandy, > > Thanks for the review. I have uploaded a new iteration [1], please also > review the CSR at [2] > > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8219480/webrev.01/ Looks good. > [2] https://bugs.openjdk.java.net/browse/JDK-8219587 Reviewed. I set the scope and interface kind of CSR for you. Mandy From vicente.romero at oracle.com Fri Feb 22 20:36:16 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 22 Feb 2019 15:36:16 -0500 Subject: RFR: JDK-8219480: j.l.c.ClassDesc::arrayType(int rank) throws IllegalArgumentException if rank = 0 In-Reply-To: References: <923641ee-568f-07ae-7cbe-ea7faa2f8778@oracle.com> Message-ID: <51edb5e3-2eb6-ca12-0742-b50be1e261d4@oracle.com> thanks :) Vicente On 2/22/19 2:50 PM, Mandy Chung wrote: > > > On 2/22/19 8:37 AM, Vicente Romero wrote: >> Hi Mandy, >> >> Thanks for the review. I have uploaded a new iteration [1], please >> also review the CSR at [2] >> >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8219480/webrev.01/ > > Looks good. > >> [2] https://bugs.openjdk.java.net/browse/JDK-8219587 > > Reviewed.? I set the scope and interface kind of CSR for you. > > Mandy From alexander.matveev at oracle.com Fri Feb 22 22:26:59 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 22 Feb 2019 14:26:59 -0800 Subject: RFR: JDK-8218681 : Windows exe's generated by jpackage have wrong info Message-ID: <15b7aa7e-aec8-846e-f89e-0867076a14b7@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - User provided version was not display, because it was added as additional LANG_ENGLISH resource and Windows Explorer was displaying default one added during build as LANG_NEUTRAL. Fixed by adding/modifying version information as LANG_NEUTRAL resource. - Removed unused fields from WinLauncher.template. - Improved error handling for version swap. - Fixed debug build after JDK-8212091 by removing not needed code from #ifdef DEBUG. [1] https://bugs.openjdk.java.net/browse/JDK-8218681 [2] http://cr.openjdk.java.net/~almatvee/8218681/webrev.00/ Thanks, Alexander From alexander.matveev at oracle.com Fri Feb 22 22:31:25 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 22 Feb 2019 14:31:25 -0800 Subject: RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder. In-Reply-To: References: <71615f59-bc90-36b4-1c88-6e7dfafc9161@oracle.com> Message-ID: <485e56a0-49a5-51d6-d05c-6c0b3a15d1c3@oracle.com> Hi Andy, Updated changes looks fine. Thanks, Alexander On 2/22/2019 9:50 AM, Andy Herrick wrote: > revised webrev t address issues brought up by Mandy: > > [2] http://cr.openjdk.java.net/~herrick/8218055/webrev.03 > > /Andy > > > On 2/21/2019 8:54 PM, Mandy Chung wrote: >> >> >> On 2/21/19 4:49 PM, Andy Herrick wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> This enhancement removes the use of >>> jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder in favor of >>> invoking jlink directly thru the ToolProvider interface, with >>> associated code cleanup. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8218055 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8218055/webrev.02 >> >> I only skimmed on the patch.? A couple of comments: >> >> ? 73???????????? () -> new RuntimeException("link tool not found")); >> >> s/link/jlink/ >> >> Instead of RuntimeException, should this error be localized? >> Does jpackage require jdk.jlink?? Then this would never reach. >> >> ?424???????? Files.deleteIfExists(output); // jlink will re-create >> >> This would fail if output directory is not empty. >> >> ?453???????? args,add("--bind-services"); >> >> s/,/. (does this compile?) >> >> jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder class is no >> longer needed.? This should be removed. >> >> Mandy > From jonathan.gibbons at oracle.com Sat Feb 23 21:32:10 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 23 Feb 2019 13:32:10 -0800 Subject: RFR: 8219548 Re: Faulty Null-Check Suspected in ToolProvider In-Reply-To: References: <1550266989.2497.19.camel@paratix.ch> <2AD267F3-D0D1-4A7A-9068-AE757E918A8D@oracle.com> <1550275179.2497.21.camel@paratix.ch> Message-ID: <9bf3ac3a-1ea2-f4cb-ae8f-2a996dc7cd5d@oracle.com> Looks good to me. -- Jon On 2/21/19 12:34 PM, Lance Andersen wrote: > Here is the webrev of the patch from Philipp. I did not change the name of the test() method as it was not necessary > > http://cr.openjdk.java.net/~lancea/8219548/webrev.00/ > > >> On Feb 15, 2019, at 6:59 PM, Philipp Kunz wrote: >> >> Hi Lance, >> >> See attached patch. >> >> Regards, >> Philipp >> >> >> On Fri, 2019-02-15 at 18:10 -0500, Lance Andersen wrote: >>> Hi Philipp >>> >>> This probably makes sense to update. >>> >>> Can you also update the ToolProviderTest.java to add a test for the changes >>> >>> Thank you >>> >>> Best >>> Lance >>> >>>> On Feb 15, 2019, at 4:43 PM, Philipp Kunz > wrote: >>>> >>>> >>> >>> >>> 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 augustnagro at gmail.com Sat Feb 23 22:27:54 2019 From: augustnagro at gmail.com (August Nagro) Date: Sat, 23 Feb 2019 16:27:54 -0600 Subject: Proposal to enhance Stream.collect Message-ID: Calling Stream.collect(Collector) is a popular terminal stream operation. But because the collect methods provide no detail of the stream's characteristics, collectors are not as efficient as they could be. For example, consider a non-parallel, sized stream that is to be collected as a List. This is a very common case for streams with a Collection source. Because of the stream characteristics, the Collector.supplier() could initialize a list with initial size (since the merging function will never be called), but the current implementation prevents this. I should note that the characteristics important to collectors are those defined by Spliterator, like: Spliterator::characteristics, Spliterator::estimateSize, and Spliterator::getExactSizeIfKnown. One way this enhancement could be implemented is by adding a method Stream.collect(Function collectorBuilder). ReadOnlySpliterator would implement the spliterator methods mentioned above, and Spliterator would be made to implement this interface. For example, here is a gist with what Collectors.toList could look like: https://gist.github.com/AugustNagro/e66a0ddf7d47b4f11fec8760281bb538 ReadOnlySpliterator may need to be replaced with some stream specific abstraction, however, since Stream.spliterator() does not return with the correct characteristics. The below code returns false, for example (is this a bug?): Stream.of(1,2,3).parallel().map(i -> i+1).spliterator().hasCharacteristics(Spliterator.CONCURRENT) Looking forward to your thoughts, - August Nagro From openjdk at icemanx.nl Sun Feb 24 11:29:56 2019 From: openjdk at icemanx.nl (Rob Spoor) Date: Sun, 24 Feb 2019 12:29:56 +0100 Subject: Proposal to enhance Stream.collect In-Reply-To: References: Message-ID: If you already know the size and are not going to parallelize your stream, you can simply use Collectors.toCollection: Stream.of(1,2,3) .map(i -> i+1) .collect(Collectors.toCollection(() -> new ArrayList<>(3))); It could perhaps be a bit easier if Collectors.toList would be overloaded to accept the initial size, but that would restrict the method to always use ArrayList (or another List with a predefined capacity). On 23/02/2019 23:27, August Nagro wrote: > Calling Stream.collect(Collector) is a popular terminal stream operation. > But because the collect methods provide no detail of the stream's > characteristics, collectors are not as efficient as they could be. > > For example, consider a non-parallel, sized stream that is to be collected > as a List. This is a very common case for streams with a Collection source. > Because of the stream characteristics, the Collector.supplier() could > initialize a list with initial size (since the merging function will never > be called), but the current implementation prevents this. > > I should note that the characteristics important to collectors are those > defined by Spliterator, like: Spliterator::characteristics, > Spliterator::estimateSize, and Spliterator::getExactSizeIfKnown. > > One way this enhancement could be implemented is by adding a method > Stream.collect(Function collectorBuilder). > ReadOnlySpliterator would implement the spliterator methods mentioned > above, and Spliterator would be made to implement this interface. > > For example, here is a gist with what Collectors.toList could look like: > https://gist.github.com/AugustNagro/e66a0ddf7d47b4f11fec8760281bb538 > > ReadOnlySpliterator may need to be replaced with some stream specific > abstraction, however, since Stream.spliterator() does not return with the > correct characteristics. The below code returns false, for example (is this > a bug?): > > Stream.of(1,2,3).parallel().map(i -> > i+1).spliterator().hasCharacteristics(Spliterator.CONCURRENT) > > Looking forward to your thoughts, > > - August Nagro From brian.goetz at oracle.com Sun Feb 24 14:51:10 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 24 Feb 2019 09:51:10 -0500 Subject: Proposal to enhance Stream.collect In-Reply-To: References: Message-ID: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> We did consider this problem when designing the Collector API; for example, it would have been nice if we could have a `toArray()` collector that had all the optimizations of `Stream::toArray`. When we looked into it, we found a number of concerning details that caused us to turn back (many of which you've already identified), such as the difficulty of managing parallelism, the intrusion into the API, etc.? What we found is that all this additional complexity was basically in aid of only a few use cases -- such as collecting into a pre-sized ArrayList.? Where are the next hundred use cases for such a mechanism, that would justify this incremental API complexity?? We didn't see them, but maybe there are some. A less intrusive API direction might be a version of Collector whose supplier function took a size-estimate argument; this might even help in parallel since it allows for intermediate results to start with a better initial size guess.? (And this could be implemented as a default that delegates to the existing supplier.)? Still, not really sure this carries its weight. > The below code returns false, for example (is this > a bug?): > > Stream.of(1,2,3).parallel().map(i -> > i+1).spliterator().hasCharacteristics(Spliterator.CONCURRENT) Not a bug.?? The `Stream::spliterator` method (along with `iterator`) is provided as an "escape hatch" for operations that need to get at the elements but which cannot be easily expressed using the Stream API.? This method makes a good-faith attempt to propagate a reasonable set of characteristics (for a stream with no intermediate ops, it does delegate to the underlying source for its spliterator), but, given that `Stream` is not in fact a data structure, when there is nontrivial computation on the actual source, a relatively bare-bones spliterator is provided. While this could probably be improved in specific cases, the return on effort (and risk) is likely to be low, because `Stream::spliterator` is already an infrequently used method, and it would only matter in a small fraction of those cases.? So you're in "corner case of a corner case" territory. On 2/23/2019 5:27 PM, August Nagro wrote: > Calling Stream.collect(Collector) is a popular terminal stream operation. > But because the collect methods provide no detail of the stream's > characteristics, collectors are not as efficient as they could be. > > For example, consider a non-parallel, sized stream that is to be collected > as a List. This is a very common case for streams with a Collection source. > Because of the stream characteristics, the Collector.supplier() could > initialize a list with initial size (since the merging function will never > be called), but the current implementation prevents this. > > I should note that the characteristics important to collectors are those > defined by Spliterator, like: Spliterator::characteristics, > Spliterator::estimateSize, and Spliterator::getExactSizeIfKnown. > > One way this enhancement could be implemented is by adding a method > Stream.collect(Function collectorBuilder). > ReadOnlySpliterator would implement the spliterator methods mentioned > above, and Spliterator would be made to implement this interface. > > For example, here is a gist with what Collectors.toList could look like: > https://gist.github.com/AugustNagro/e66a0ddf7d47b4f11fec8760281bb538 > > ReadOnlySpliterator may need to be replaced with some stream specific > abstraction, however, since Stream.spliterator() does not return with the > correct characteristics. The below code returns false, for example (is this > a bug?): > > Stream.of(1,2,3).parallel().map(i -> > i+1).spliterator().hasCharacteristics(Spliterator.CONCURRENT) > > Looking forward to your thoughts, > > - August Nagro From augustnagro at gmail.com Sun Feb 24 20:28:11 2019 From: augustnagro at gmail.com (August Nagro) Date: Sun, 24 Feb 2019 14:28:11 -0600 Subject: Proposal to enhance Stream.collect In-Reply-To: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> References: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> Message-ID: Thanks for the feedback. I really like Brian's suggestion for a default Collector.supplier(sizeEstimate), since exposing the full stream characteristics is overkill. I don't think the use of this improvement is limited to pre-sizing ArrayLists, though. Some other Collectors that come to mind are StringJoiner (Collectors.joining) and my FutureJoiner [1], which collects a stream of CompletableFuture into a CompletableFuture>. And even if Collectors.toList was the only collector to benefit from pre-sizing, I think it is still worth the effort, as this is perhaps the most used Collector. [1]: https://gist.github.com/AugustNagro/e92c48e39f891f16500f36c33839383a On Sun, Feb 24, 2019 at 8:51 AM Brian Goetz wrote: > We did consider this problem when designing the Collector API; for > example, it would have been nice if we could have a `toArray()` > collector that had all the optimizations of `Stream::toArray`. > > When we looked into it, we found a number of concerning details that > caused us to turn back (many of which you've already identified), such > as the difficulty of managing parallelism, the intrusion into the API, > etc. What we found is that all this additional complexity was basically > in aid of only a few use cases -- such as collecting into a pre-sized > ArrayList. Where are the next hundred use cases for such a mechanism, > that would justify this incremental API complexity? We didn't see them, > but maybe there are some. > > A less intrusive API direction might be a version of Collector whose > supplier function took a size-estimate argument; this might even help in > parallel since it allows for intermediate results to start with a better > initial size guess. (And this could be implemented as a default that > delegates to the existing supplier.) Still, not really sure this > carries its weight. > > > The below code returns false, for example (is this > > a bug?): > > > > Stream.of(1,2,3).parallel().map(i -> > > i+1).spliterator().hasCharacteristics(Spliterator.CONCURRENT) > > Not a bug. The `Stream::spliterator` method (along with `iterator`) is > provided as an "escape hatch" for operations that need to get at the > elements but which cannot be easily expressed using the Stream API. > This method makes a good-faith attempt to propagate a reasonable set of > characteristics (for a stream with no intermediate ops, it does delegate > to the underlying source for its spliterator), but, given that `Stream` > is not in fact a data structure, when there is nontrivial computation on > the actual source, a relatively bare-bones spliterator is provided. > > While this could probably be improved in specific cases, the return on > effort (and risk) is likely to be low, because `Stream::spliterator` is > already an infrequently used method, and it would only matter in a small > fraction of those cases. So you're in "corner case of a corner case" > territory. > > > On 2/23/2019 5:27 PM, August Nagro wrote: > > Calling Stream.collect(Collector) is a popular terminal stream operation. > > But because the collect methods provide no detail of the stream's > > characteristics, collectors are not as efficient as they could be. > > > > For example, consider a non-parallel, sized stream that is to be > collected > > as a List. This is a very common case for streams with a Collection > source. > > Because of the stream characteristics, the Collector.supplier() could > > initialize a list with initial size (since the merging function will > never > > be called), but the current implementation prevents this. > > > > I should note that the characteristics important to collectors are those > > defined by Spliterator, like: Spliterator::characteristics, > > Spliterator::estimateSize, and Spliterator::getExactSizeIfKnown. > > > > One way this enhancement could be implemented is by adding a method > > Stream.collect(Function > collectorBuilder). > > ReadOnlySpliterator would implement the spliterator methods mentioned > > above, and Spliterator would be made to implement this interface. > > > > For example, here is a gist with what Collectors.toList could look like: > > https://gist.github.com/AugustNagro/e66a0ddf7d47b4f11fec8760281bb538 > > > > ReadOnlySpliterator may need to be replaced with some stream specific > > abstraction, however, since Stream.spliterator() does not return with the > > correct characteristics. The below code returns false, for example (is > this > > a bug?): > > > > Stream.of(1,2,3).parallel().map(i -> > > i+1).spliterator().hasCharacteristics(Spliterator.CONCURRENT) > > > > Looking forward to your thoughts, > > > > - August Nagro > > From Alan.Bateman at oracle.com Mon Feb 25 08:31:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Feb 2019 08:31:03 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <953449f0913340f6a94ae3d83611fd92@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <953449f0913340f6a94ae3d83611fd92@sap.com> Message-ID: <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> On 21/02/2019 15:04, Langer, Christoph wrote: > Hi Alan, > > here is the next iteration:http://cr.openjdk.java.net/~clanger/webrevs/8213031.7/ > > I focused on your comments regarding implementation details: > > : > Are there other major implementation points left? If not I guess we should start refining the documentation... I think it would be useful to write down a summary of the proposal as there are several detailed points that we've been discussing in this thread that reviewers will need to understand the proposal before diving into the implementation/patch.? This might also help getting the javadoc aligned, and eventually the CSR. Here's where I think we are: 1. By default, a zip file system will have no support for the "posix" and "owner" views of file attributes, this means the following will fail with UOE: ? PosixFileAttributes attrs = Files.readAttributes(file, PosixFileAttributes.class); and the zip file system's supportedFileAttributView method will not include "posix". 2. Creating a zip file system with configuration parameter XXX set to "true" will create the zip file system that supports PosixFileAttributeView (and FileOwnerAttributeView). The current patch names the configuration parameter "posix". That name might be misleading as a configuration parameter as it conveys more than it actually does. Something like "enablePosixFileAttributes" clear conveys that it enables support for POSIX file attribute but might be a better wordy. The value in the configuration map is documented as Boolean but I think we are allowing it to be the string representation of a Boolean, meaning it can be "true" or "false" like we have with the "create" parameter. 3. The map of configurations parameters can optionally include the parameters "defaultOwner", "defaultGroup", and "defaultPermissions" with the default owner/group/permissions to return. These names seem okay to me. For the owner/group, the parameter type can be UserPrincipal/GroupPrincipal or strings. If the value is a String then we need to decide if there is any validation. If I read the current patch correctly then it doesn't do any validation - that might be okay but minimally maybe we should disallow the empty string. If the defaultXXX parameters aren't present then the zip file owner/group would be a sensible default. If the zip file is on a file store that supports FileOwnerAttributeView then we've got the owner. If the file store supports PosixFileAttributeView then we have a group owner. If PosixFileAttributeView is not supported then using the owner as the group is okay. I see the current patch as a fallback to fallback to "" but I'd prefer not have that because it will be very confusing to diagnose if there are issues. For defaultPermissions, the value is a Set or the string representation. In the implementation, initPermissions can be changed to use PosixFilePermissions.fromString as it does the translation that we need. 4. As an alternative to the type safe access that PosixFileAttributeView provides, the proposal is to document the "zip" view of file attributes. Initially, it will admit to one file attribute for the permissions. The current patch uses the name "storedPermissions" but it might be simpler to use "permissions" so that "zip:permissions" and "posix:permissions" are the same when the zip entry has permissions. With this support you can write code like this: ??? Set perms = (Set) Files.getAttribute(file, "zip:permissions"); The cast is ugly of course but that's the consequence of not exposing ZipFileAttributes in the API so there is no type token to specify on the RHS. Documenting the "zip" view brings up a few issues, e.g. will Files.readAttributes(file, "zip:*") reveal more than "permissions". For this API it is okay for the map to attributes beyond the specified list. 5. There will be no support for specifying as POSIX FileAttribute to createFile or createDirectory to atomically set the permissions when creating a new file/directory, UOE will thrown as is is now. Is this a reasonable summary? -Alan From andy.herrick at oracle.com Mon Feb 25 12:57:59 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 25 Feb 2019 07:57:59 -0500 Subject: RFR: JDK-8218681 : Windows exe's generated by jpackage have wrong info In-Reply-To: <15b7aa7e-aec8-846e-f89e-0867076a14b7@oracle.com> References: <15b7aa7e-aec8-846e-f89e-0867076a14b7@oracle.com> Message-ID: This looks good /Andy On 2/22/2019 5:26 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - User provided version was not display, because it was added as > additional LANG_ENGLISH resource and Windows Explorer was displaying > default one added during build as LANG_NEUTRAL. Fixed by > adding/modifying version information as LANG_NEUTRAL resource. > - Removed unused fields from WinLauncher.template. > - Improved error handling for version swap. > - Fixed debug build after JDK-8212091 by removing not needed code from > #ifdef DEBUG. > > [1] https://bugs.openjdk.java.net/browse/JDK-8218681 > > [2] http://cr.openjdk.java.net/~almatvee/8218681/webrev.00/ > > Thanks, > Alexander From andrew_m_leonard at uk.ibm.com Mon Feb 25 13:12:11 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 25 Feb 2019 13:12:11 +0000 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> Message-ID: Hi Mandy, I must admit I don't completely follow the logic of the existing Modifier init of langReflectAccess, the comment indicates a "protocol between java.lang and java.lang.reflect". I can try moving the clinit code from Modifier to AccessibleObject, but I question is there some reason it is there? Would we be sure in moving it we are not missing something? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Mandy Chung To: Andrew Leonard , Roger Riggs Cc: core-libs-dev at openjdk.java.net Date: 22/02/2019 18:17 Subject: Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized Hi Andrew, Thanks for the stack trace of the issue triggering this. It seems to me that Modifier:: isn't the right place to setLangReflectAccess shared secret. It might have assumed that Modifier should have been initialized when Field/Method or other AccessibleObject is instantiated which isn't true since the modifiers field is an int. While the fix looks okay, would you mind trying a different fix moving Modifier:: to AccessibleObject? See this resolves the issue when running on J9? Mandy On 2/22/19 12:49 AM, Andrew Leonard wrote: > Hi Roger, > I had a think about this and a testcase will be difficult, as it was found > during OpenJ9 testing and occured during VM bootstrap, feel free to read > further details here: > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_openj9_issues_3399-23issuecomment-2D459004840&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=a83hTiGAixSJXbKXDa5xzF-Z_N-iYoFk9QcOrQ3Zgiw&s=nI8avX9tV8iOOqNvlUPGi6avSq5-h2fXeHvlzjFHeBY&e= > So the issue was discovered due to the bootstrap behaviour, it was not > observed with Hotspot, however given the obvious missing initialization > check logic in the class it's not to say there's an untested route with > Hotspot that could hit it... I'm not sure how I could scaffold a jtreg > test to replicate the same? > Thanks > Andrew 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 andrew_m_leonard at uk.ibm.com Mon Feb 25 13:15:58 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 25 Feb 2019 13:15:58 +0000 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> Message-ID: Hi Alan, The J9 tests are run against build "images". Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Alan Bateman To: Andrew Leonard , Roger Riggs Cc: core-libs-dev at openjdk.java.net Date: 22/02/2019 14:56 Subject: Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized On 22/02/2019 08:49, Andrew Leonard wrote: > Hi Roger, > I had a think about this and a testcase will be difficult, as it was found > during OpenJ9 testing and occured during VM bootstrap, Can you say if the J9 failure was with an exploded build or an images build? Just asking as suggest we could trigger this with an exploded build during startup with the right test. If it's too much work then no problem, I agree with Roger that the issue is obvious. -Alan 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 andy.herrick at oracle.com Mon Feb 25 13:19:26 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 25 Feb 2019 08:19:26 -0500 Subject: RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder. In-Reply-To: <94b77c01-9a1b-cb13-24e9-ab0cf9a5b5a3@oracle.com> References: <71615f59-bc90-36b4-1c88-6e7dfafc9161@oracle.com> <94b77c01-9a1b-cb13-24e9-ab0cf9a5b5a3@oracle.com> Message-ID: I uploaded webrev version 04 (http://cr.openjdk.java.net/~herrick/8218055/webrev.04) which is same as version 03 except "JLink" is changed to "jlink" in several messages. /ANdy On 2/22/2019 2:37 PM, Mandy Chung wrote: > > > On 2/22/19 9:50 AM, Andy Herrick wrote: >> revised webrev t address issues brought up by Mandy: >> >> [2] http://cr.openjdk.java.net/~herrick/8218055/webrev.03 > > I only looked at JLinkBundlerHelper.java and the removed > files that look okay.? Nit: can you use "jlink" lower case > in the log/exception message (that's the tool's name). > > Someone else who knows this area should review. > > Mandy From andrew_m_leonard at uk.ibm.com Mon Feb 25 15:00:19 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 25 Feb 2019 15:00:19 +0000 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> Message-ID: Hi Mandy, I can confirm "just" moving the clinit code into AccessibleObject does resolve the J9 issue as well, without changing ReflectionFactory... What's your thoughts? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Mandy Chung To: Andrew Leonard , Roger Riggs Cc: core-libs-dev at openjdk.java.net Date: 22/02/2019 18:17 Subject: Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized Hi Andrew, Thanks for the stack trace of the issue triggering this. It seems to me that Modifier:: isn't the right place to setLangReflectAccess shared secret. It might have assumed that Modifier should have been initialized when Field/Method or other AccessibleObject is instantiated which isn't true since the modifiers field is an int. While the fix looks okay, would you mind trying a different fix moving Modifier:: to AccessibleObject? See this resolves the issue when running on J9? Mandy On 2/22/19 12:49 AM, Andrew Leonard wrote: > Hi Roger, > I had a think about this and a testcase will be difficult, as it was found > during OpenJ9 testing and occured during VM bootstrap, feel free to read > further details here: > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_openj9_issues_3399-23issuecomment-2D459004840&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=a83hTiGAixSJXbKXDa5xzF-Z_N-iYoFk9QcOrQ3Zgiw&s=nI8avX9tV8iOOqNvlUPGi6avSq5-h2fXeHvlzjFHeBY&e= > So the issue was discovered due to the bootstrap behaviour, it was not > observed with Hotspot, however given the obvious missing initialization > check logic in the class it's not to say there's an untested route with > Hotspot that could hit it... I'm not sure how I could scaffold a jtreg > test to replicate the same? > Thanks > Andrew 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 dmitry.chuyko at bell-sw.com Mon Feb 25 17:09:50 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Mon, 25 Feb 2019 20:09:50 +0300 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: <2d4ee3bd-b3e0-21d6-7868-745d94e9b354@oracle.com> References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> <2b7fc762-d0a6-3452-c57e-30a4447b5149@oracle.com> <2d4ee3bd-b3e0-21d6-7868-745d94e9b354@oracle.com> Message-ID: On 2/22/19 9:55 PM, Roger Riggs wrote: > Hi, > > After a closer look, I'd take the route of the 01 webrev. > It is more localized and does not force the function signature needed > by pthread_create to be propagated elsewhere. > > The code can be a lot more comprehensible by renaming the CallIntFunc > function to be specific to ContinueInNewThread0. It looks like a > trampoline to me. > The data structure being passed is on the stack of the caller of > pthread_create. > It seems safe to refer to it here because the caller will wait in > pthread_join. After some hesitation it looks like ContinueInNewThread0 may know about JavaMain just like ContinueInNewThread, no need to work with abstract continuation. Even that abstract continuation is limited to int return type. In webrev.02 continuation gets platform specific signature. But then we have to cast the result where the call is direct. Another approach in that direction could be to add result field in JavaMainArgs, but it will again force ContinueInNewThread0 to know about continuation's parameters structure as there may be a direct call of continuation. If we let ContinueInNewThread0 call only JavaMain, it all can work without extra trampoline structures (just need a wrapper): http://cr.openjdk.java.net/~dchuyko/8215009/webrev.03/ -Dmitry > > Also important is to document that the return type is specific to the OS > and is needed to cast the return value expected by the > start_pthread_create > start_routine.? That may still be in question because pthread_create > expects void*. > > $.02, Roger > > > On 02/22/2019 10:32 AM, Roger Riggs wrote: >> Hi, >> >> If the warning can be addressed with an extra in-line cast then that's >> cleaner and easier to understand than replicating that structure in 3 >> files. >> And of course, add a comment. >> To make the source more readable, the cast could be factored >> into a macro in the same file with the comment about why it is needed. >> >> Roger >> >> >> On 02/21/2019 11:07 PM, David Holmes wrote: >>> On 22/02/2019 4:55 am, Mikael Vidstedt wrote: >>>> >>>> The wrapper based solution looks much cleaner to me as well. >>>> webrev.01 looks good. >>> >>> Sorry I really don't like it. The wrappers obfuscate and make >>> complicated something that is not at all complicated. I have to >>> re-read the new code 3 times to figure out what it is even doing! >>> >>> All that complexity to handle the fact one platform wants to return >>> int instead of void* ?? > The complexity is due to the function being called in some other thread > context and there is a necessary cast/type conversion on the return value > from the start_routine that has to come back through pthread to > pthread_join. > > >>> >>> David >>> ----- >>> >>>> (not a Reviewer) >>>> >>>> Cheers, >>>> Mikael >>>> >>>>> On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko >>>>> wrote: >>>>> >>>>> To me thread function wrappers look preferable to platform >>>>> specific JavaMain signature. Consider this webrev with wrappers: >>>>> >>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ >>>>> >>>>> In some cases JavaMain is called in the same thread and its result >>>>> is returned from JLI_Launch. ContinueInNewThread is in shared >>>>> code. And JavaMain uses macro controlled returns. >>>>> So when JavaMain returns THREAD_FUNC_RETURN changes may contain >>>>> some quite artificial macro parts in java.c: >>>>> >>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ >>>>> >>>>> -Dmitry >>>>> >>>>> On 12/19/18 9:27 AM, David Holmes wrote: >>>>>> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >>>>>>> On 12/18/18 3:39 AM, David Holmes wrote: >>>>>>>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>>>>>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review a small fix in java_md_solinux.c: continuation >>>>>>>>>>> is not truly compatible with pthread_create start_routine's >>>>>>>>>>> signature but we control what actually happens. So it makes >>>>>>>>>>> sense to add intermediate void* cast to silence the error. >>>>>>>>>> >>>>>>>>>> I'd be tempted to fix the signature and get rid of all the >>>>>>>>>> casts. >>>>>>>>> >>>>>>>>> David, the signature is a signature of >>>>>>>>> >>>>>>>>> int JNICALL JavaMain(void * _args) >>>>>>>>> >>>>>>>>> It would be fun to change it. But still on Windows it is >>>>>>>>> correctly passed to _beginthreadex() and then return code is >>>>>>>>> extracted with GetExitCodeThread(). In case we want it to >>>>>>>>> return void* the cast will move there. >>>>>>>> >>>>>>>> I think the current double cast is truly ugly and an ifdef for >>>>>>>> windows, or a cast for Windows only would be an improvement. >>>>>>> >>>>>>> I agree. Maybe making a wrapper function is not so ugly. If >>>>>>> there are no objections to changing beginning of the call stack >>>>>>> it is quite easy to implement. For consistency it may be done >>>>>>> for all 3 points (posix unix, posix mac, windows) or just for >>>>>>> posix ones. >>>>>>> >>>>>>> It looks like ifdef should be better as long as there are >>>>>>> already OS-specific parts in libjli. Again, if there are no >>>>>>> objections to have different JavaMain signatures on different >>>>>>> platforms. In this case there won't be a signature cast for >>>>>>> Windows. >>>>>> >>>>>> How about setting >>>>>> >>>>>> #define THREAD_FUNC_RETURN int >>>>>> >>>>>> in windows/java_md.h. >>>>>> >>>>>> Then: >>>>>> >>>>>> #ifndef THREAD_FUNC_RETURN >>>>>> ?? #define THREAD_FUNC_RETURN void* >>>>>> #endif >>>>>> >>>>>> in java.h (after the other includes). >>>>>> >>>>>> Then: >>>>>> >>>>>> THREAD_FUNC_RETURN JNICALL >>>>>> JavaMain(void * _args) >>>>>> >>>>>> in java.c. >>>>>> >>>>>> ? >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>>> >>>>>>>> But I won't impose that on you just to silence gcc 8. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>>>>>>> testing: submit repo >>>>>>>>>>> (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>> >> > From mikael.vidstedt at oracle.com Mon Feb 25 18:16:22 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 25 Feb 2019 10:16:22 -0800 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> <2b7fc762-d0a6-3452-c57e-30a4447b5149@oracle.com> <2d4ee3bd-b3e0-21d6-7868-745d94e9b354@oracle.com> Message-ID: <3BFFC665-C15F-43B6-AB7D-49D7C3A97677@oracle.com> > On Feb 25, 2019, at 9:09 AM, Dmitry Chuyko wrote: > > On 2/22/19 9:55 PM, Roger Riggs wrote: >> Hi, >> >> After a closer look, I'd take the route of the 01 webrev. >> It is more localized and does not force the function signature needed >> by pthread_create to be propagated elsewhere. >> >> The code can be a lot more comprehensible by renaming the CallIntFunc >> function to be specific to ContinueInNewThread0. It looks like a trampoline to me. >> The data structure being passed is on the stack of the caller of pthread_create. >> It seems safe to refer to it here because the caller will wait in pthread_join. > > After some hesitation it looks like ContinueInNewThread0 may know about JavaMain just like ContinueInNewThread, no need to work with abstract continuation. Even that abstract continuation is limited to int return type. In webrev.02 continuation gets platform specific signature. But then we have to cast the result where the call is direct. Another approach in that direction could be to add result field in JavaMainArgs, but it will again force ContinueInNewThread0 to know about continuation's parameters structure as there may be a direct call of continuation. > > If we let ContinueInNewThread0 call only JavaMain, it all can work without extra trampoline structures (just need a wrapper): > > http://cr.openjdk.java.net/~dchuyko/8215009/webrev.03/ I like it! Since ContinueInNewThread0 is now always calling JavaMain I guess it could be renamed to CallJavaMainInNewThread (or something to that same effect). Minor nit: some consistency in where the ?*? is placed in the various ?void *? places would be nice. Cheers, Mikael > > -Dmitry > >> >> Also important is to document that the return type is specific to the OS >> and is needed to cast the return value expected by the start_pthread_create >> start_routine. That may still be in question because pthread_create >> expects void*. >> >> $.02, Roger >> >> >> On 02/22/2019 10:32 AM, Roger Riggs wrote: >>> Hi, >>> >>> If the warning can be addressed with an extra in-line cast then that's >>> cleaner and easier to understand than replicating that structure in 3 files. >>> And of course, add a comment. >>> To make the source more readable, the cast could be factored >>> into a macro in the same file with the comment about why it is needed. >>> >>> Roger >>> >>> >>> On 02/21/2019 11:07 PM, David Holmes wrote: >>>> On 22/02/2019 4:55 am, Mikael Vidstedt wrote: >>>>> >>>>> The wrapper based solution looks much cleaner to me as well. webrev.01 looks good. >>>> >>>> Sorry I really don't like it. The wrappers obfuscate and make complicated something that is not at all complicated. I have to re-read the new code 3 times to figure out what it is even doing! >>>> >>>> All that complexity to handle the fact one platform wants to return int instead of void* ?? >> The complexity is due to the function being called in some other thread >> context and there is a necessary cast/type conversion on the return value >> from the start_routine that has to come back through pthread to pthread_join. >> >> >>>> >>>> David >>>> ----- >>>> >>>>> (not a Reviewer) >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>>> On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko wrote: >>>>>> >>>>>> To me thread function wrappers look preferable to platform specific JavaMain signature. Consider this webrev with wrappers: >>>>>> >>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ >>>>>> >>>>>> In some cases JavaMain is called in the same thread and its result is returned from JLI_Launch. ContinueInNewThread is in shared code. And JavaMain uses macro controlled returns. >>>>>> So when JavaMain returns THREAD_FUNC_RETURN changes may contain some quite artificial macro parts in java.c: >>>>>> >>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 12/19/18 9:27 AM, David Holmes wrote: >>>>>>> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >>>>>>>> On 12/18/18 3:39 AM, David Holmes wrote: >>>>>>>>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>>>>>>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Please review a small fix in java_md_solinux.c: continuation is not truly compatible with pthread_create start_routine's signature but we control what actually happens. So it makes sense to add intermediate void* cast to silence the error. >>>>>>>>>>> >>>>>>>>>>> I'd be tempted to fix the signature and get rid of all the casts. >>>>>>>>>> >>>>>>>>>> David, the signature is a signature of >>>>>>>>>> >>>>>>>>>> int JNICALL JavaMain(void * _args) >>>>>>>>>> >>>>>>>>>> It would be fun to change it. But still on Windows it is correctly passed to _beginthreadex() and then return code is extracted with GetExitCodeThread(). In case we want it to return void* the cast will move there. >>>>>>>>> >>>>>>>>> I think the current double cast is truly ugly and an ifdef for windows, or a cast for Windows only would be an improvement. >>>>>>>> >>>>>>>> I agree. Maybe making a wrapper function is not so ugly. If there are no objections to changing beginning of the call stack it is quite easy to implement. For consistency it may be done for all 3 points (posix unix, posix mac, windows) or just for posix ones. >>>>>>>> >>>>>>>> It looks like ifdef should be better as long as there are already OS-specific parts in libjli. Again, if there are no objections to have different JavaMain signatures on different platforms. In this case there won't be a signature cast for Windows. >>>>>>> >>>>>>> How about setting >>>>>>> >>>>>>> #define THREAD_FUNC_RETURN int >>>>>>> >>>>>>> in windows/java_md.h. >>>>>>> >>>>>>> Then: >>>>>>> >>>>>>> #ifndef THREAD_FUNC_RETURN >>>>>>> #define THREAD_FUNC_RETURN void* >>>>>>> #endif >>>>>>> >>>>>>> in java.h (after the other includes). >>>>>>> >>>>>>> Then: >>>>>>> >>>>>>> THREAD_FUNC_RETURN JNICALL >>>>>>> JavaMain(void * _args) >>>>>>> >>>>>>> in java.c. >>>>>>> >>>>>>> ? >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>>> >>>>>>>>> But I won't impose that on you just to silence gcc 8. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>>>>>>>> testing: submit repo (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>> >>> >> From Roger.Riggs at oracle.com Mon Feb 25 18:37:07 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 25 Feb 2019 13:37:07 -0500 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: <3BFFC665-C15F-43B6-AB7D-49D7C3A97677@oracle.com> References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> <2b7fc762-d0a6-3452-c57e-30a4447b5149@oracle.com> <2d4ee3bd-b3e0-21d6-7868-745d94e9b354@oracle.com> <3BFFC665-C15F-43B6-AB7D-49D7C3A97677@oracle.com> Message-ID: <7a519513-aa92-269b-f5bb-9bbe1bd1bfe7@oracle.com> +1 Much cleaner, since it does not need to be more general. I'd probably add a comment to the ThreadJavaMain method to say why it is needed. BTW, it looks like the indents have gotten mixed up between 2 spaces and 4. For the libjli it should be 4 spaces. But this change is probably not the place to fix it and it is locally consistent. Thanks, Roger On 02/25/2019 01:16 PM, Mikael Vidstedt wrote: > >> On Feb 25, 2019, at 9:09 AM, Dmitry Chuyko wrote: >> >> On 2/22/19 9:55 PM, Roger Riggs wrote: >>> Hi, >>> >>> After a closer look, I'd take the route of the 01 webrev. >>> It is more localized and does not force the function signature needed >>> by pthread_create to be propagated elsewhere. >>> >>> The code can be a lot more comprehensible by renaming the CallIntFunc >>> function to be specific to ContinueInNewThread0. It looks like a trampoline to me. >>> The data structure being passed is on the stack of the caller of pthread_create. >>> It seems safe to refer to it here because the caller will wait in pthread_join. >> After some hesitation it looks like ContinueInNewThread0 may know about JavaMain just like ContinueInNewThread, no need to work with abstract continuation. Even that abstract continuation is limited to int return type. In webrev.02 continuation gets platform specific signature. But then we have to cast the result where the call is direct. Another approach in that direction could be to add result field in JavaMainArgs, but it will again force ContinueInNewThread0 to know about continuation's parameters structure as there may be a direct call of continuation. >> >> If we let ContinueInNewThread0 call only JavaMain, it all can work without extra trampoline structures (just need a wrapper): >> >> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.03/ > I like it! Since ContinueInNewThread0 is now always calling JavaMain I guess it could be renamed to CallJavaMainInNewThread (or something to that same effect). I'm fine with the rename (no additional review necessary). > > Minor nit: some consistency in where the ?*? is placed in the various ?void *? places would be nice. > > Cheers, > Mikael > >> -Dmitry >> >>> Also important is to document that the return type is specific to the OS >>> and is needed to cast the return value expected by the start_pthread_create >>> start_routine. That may still be in question because pthread_create >>> expects void*. >>> >>> $.02, Roger >>> >>> >>> On 02/22/2019 10:32 AM, Roger Riggs wrote: >>>> Hi, >>>> >>>> If the warning can be addressed with an extra in-line cast then that's >>>> cleaner and easier to understand than replicating that structure in 3 files. >>>> And of course, add a comment. >>>> To make the source more readable, the cast could be factored >>>> into a macro in the same file with the comment about why it is needed. >>>> >>>> Roger >>>> >>>> >>>> On 02/21/2019 11:07 PM, David Holmes wrote: >>>>> On 22/02/2019 4:55 am, Mikael Vidstedt wrote: >>>>>> The wrapper based solution looks much cleaner to me as well. webrev.01 looks good. >>>>> Sorry I really don't like it. The wrappers obfuscate and make complicated something that is not at all complicated. I have to re-read the new code 3 times to figure out what it is even doing! >>>>> >>>>> All that complexity to handle the fact one platform wants to return int instead of void* ?? >>> The complexity is due to the function being called in some other thread >>> context and there is a necessary cast/type conversion on the return value >>> from the start_routine that has to come back through pthread to pthread_join. >>> >>> >>>>> David >>>>> ----- >>>>> >>>>>> (not a Reviewer) >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>>> On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko wrote: >>>>>>> >>>>>>> To me thread function wrappers look preferable to platform specific JavaMain signature. Consider this webrev with wrappers: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ >>>>>>> >>>>>>> In some cases JavaMain is called in the same thread and its result is returned from JLI_Launch. ContinueInNewThread is in shared code. And JavaMain uses macro controlled returns. >>>>>>> So when JavaMain returns THREAD_FUNC_RETURN changes may contain some quite artificial macro parts in java.c: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 12/19/18 9:27 AM, David Holmes wrote: >>>>>>>> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >>>>>>>>> On 12/18/18 3:39 AM, David Holmes wrote: >>>>>>>>>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>>>>>>>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review a small fix in java_md_solinux.c: continuation is not truly compatible with pthread_create start_routine's signature but we control what actually happens. So it makes sense to add intermediate void* cast to silence the error. >>>>>>>>>>>> I'd be tempted to fix the signature and get rid of all the casts. >>>>>>>>>>> David, the signature is a signature of >>>>>>>>>>> >>>>>>>>>>> int JNICALL JavaMain(void * _args) >>>>>>>>>>> >>>>>>>>>>> It would be fun to change it. But still on Windows it is correctly passed to _beginthreadex() and then return code is extracted with GetExitCodeThread(). In case we want it to return void* the cast will move there. >>>>>>>>>> I think the current double cast is truly ugly and an ifdef for windows, or a cast for Windows only would be an improvement. >>>>>>>>> I agree. Maybe making a wrapper function is not so ugly. If there are no objections to changing beginning of the call stack it is quite easy to implement. For consistency it may be done for all 3 points (posix unix, posix mac, windows) or just for posix ones. >>>>>>>>> >>>>>>>>> It looks like ifdef should be better as long as there are already OS-specific parts in libjli. Again, if there are no objections to have different JavaMain signatures on different platforms. In this case there won't be a signature cast for Windows. >>>>>>>> How about setting >>>>>>>> >>>>>>>> #define THREAD_FUNC_RETURN int >>>>>>>> >>>>>>>> in windows/java_md.h. >>>>>>>> >>>>>>>> Then: >>>>>>>> >>>>>>>> #ifndef THREAD_FUNC_RETURN >>>>>>>> #define THREAD_FUNC_RETURN void* >>>>>>>> #endif >>>>>>>> >>>>>>>> in java.h (after the other includes). >>>>>>>> >>>>>>>> Then: >>>>>>>> >>>>>>>> THREAD_FUNC_RETURN JNICALL >>>>>>>> JavaMain(void * _args) >>>>>>>> >>>>>>>> in java.c. >>>>>>>> >>>>>>>> ? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>>> But I won't impose that on you just to silence gcc 8. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>>>>>>>>> testing: submit repo (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>>>>>>>>>> >>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>> From stuart.marks at oracle.com Mon Feb 25 18:40:57 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 25 Feb 2019 10:40:57 -0800 Subject: JDK 13 RFR of JDK-8219561: Update jdeprscan to avoid the need for start-of-release changes In-Reply-To: <41ef2545-6715-9346-be59-917eb645e9f1@oracle.com> References: <41ef2545-6715-9346-be59-917eb645e9f1@oracle.com> Message-ID: <6e7ce170-6ce5-a1fb-8fed-12ef8680c1b5@oracle.com> Hi Joe, Thanks for cleaning up jdeprscan. For computing the set of releases, I'd prefer to see a stream that looks like this: final Set releasesWithForRemoval = IntStream.rangeClosed(9, Runtime.version().feature()) .mapToObj(Integer::toString) .collect(Collectors.toUnmodifiableSet()); This collects the values directly to an unmodifiable set, instead of populating an array which is then passed to Set.of(). Thanks, s'marks On 2/21/19 6:15 PM, Joe Darcy wrote: > Hello, > > Internally jdeprscan initializes a set of strings of releases supporting > deprecation with removal. Currently those releases are JDK 9 and subsequent > values. The lists is explicitly initialized and must be updated at the start of > a release, which adds to the maintenance cost of starting a new release. The > update for JDK 13 was: > > --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Dec 13 > 17:01:15 2018 +0100 > +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Dec 13 > 19:06:11 2018 +0100 > @@ -106,7 +106,7 @@ > ???? // Keep these updated manually until there's a compiler API > ???? // that allows querying of supported releases. > ???? final Set releasesWithoutForRemoval = Set.of("6", "7", "8"); > -??? final Set releasesWithForRemoval = Set.of("9", "10", "11", "12"); > +??? final Set releasesWithForRemoval = Set.of("9", "10", "11", "12", > "13"); > > ???? final Set validReleases; > ???? { > > > Initializing the list more programmatically could avoid the need for an explicit > update for the start of a release. Please review the patch below for the > programmatic initialization: > > --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Feb 21 > 15:17:42 2019 -0800 > +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Feb 21 > 18:01:59 2019 -0800 > @@ -45,6 +45,7 @@ > ?import java.util.NoSuchElementException; > ?import java.util.Set; > ?import java.util.Queue; > +import java.util.stream.IntStream; > ?import java.util.stream.Stream; > ?import java.util.stream.StreamSupport; > ?import java.util.jar.JarEntry; > @@ -106,7 +107,12 @@ > ???? // Keep these updated manually until there's a compiler API > ???? // that allows querying of supported releases. > ???? final Set releasesWithoutForRemoval = Set.of("6", "7", "8"); > -??? final Set releasesWithForRemoval = Set.of("9", "10", "11", "12", > "13"); > +??? // Set.of("9", "10", "11", "12", "13"); > +??? final Set releasesWithForRemoval = Set.of(// "9", "10", "11", ... > +??????? IntStream.rangeClosed(9, Runtime.version().feature()) > +??????? .mapToObj(Integer::toString) > +??????? .toArray(String[]::new)); > + > > ???? final Set validReleases; > ???? { > > Thanks, > > -Joe > From stuart.marks at oracle.com Mon Feb 25 19:06:15 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 25 Feb 2019 11:06:15 -0800 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> <220EE759-20E8-429D-AA4B-CC5D4115CA7E@cbfiddle.com> <6636354e-99af-87d1-e80a-52f8e45f69f1@oracle.com> <143497CB-8EC0-4940-BBAF-4485BC6FC147@cbfiddle.com> Message-ID: On 2/15/19 11:30 AM, Alan Snyder wrote: > I think this situation is a mess. > > The ?general contract? of a Collection, I believe, is that it contains zero > or more identified member objects, as defined by appropriate equals() method. > I know this is hard to specify precisely, but I presume we all ?know it when > we see it?. > > There is value to ?collections? whose members are not objects but are > equivalence classes of objects, as defined by a nonstandard equality test, > but I think it is a mistake to call them Collections. > > If a method takes a parameter of type Collection, it should be free to assume > that the parameter object supports the ?general contract? of Collection. Is > there any plausible alternative? [back from vacation] Yes, this situation is something of a mess. I think the original idea was that the "general contract" was that collections contained elements whose membership was defined by equals(). However, for a very long time now there have been collections in the JDK such as SortedSet and IdentityHashMap (more precisely, IdentityHashMap's keyset). I think we have to accept the fact that these are collections even though their membership semantics differ from those provided by equals(). > Changing one method in the JDK to support a non-standard Collection parameter > does not solve the problem, because non-JDK methods with Collection (etc.) > parameters could have similar ?misbehavior?. How would the developer know > when a specific TreeSet can or cannot be passed to a method? Does every > method that accepts a Collection (etc.) parameter require boilerplate (as in > the disjoint example) explaining its exact requirements or how it can go > wrong? > > Perhaps it would be useful to define specific behaviors that these > nonstandard ?collections? might support. For example, a Membership interface > (with method contains(e)) would be perfect for a removeAll(Membership) method > on Collection, implemented as you propose. The wording on Collections.disjoint() is particularly clumsy. I'm not entirely sure what to do about it and its implementation; suggestions welcome. But I also don't think Collections.disjoint() is a very important problem, compared to what's going on in the rest of the framework. Introducing a new interface type is basically a non-starter. Objects of type Collection get passed around a lot, and users can usefully rely on things like size(), they can iterate the Collection, etc. Once we've admitted to the fact that different collections can have different membership semantics, the main point of this bug (JDK-6982173) is to fix up the semantics of AbstractSet.removeAll() to remove the semantic shifting that can occur based on the relative sizes of the collections. There's another bug JDK-8190545 that needs to be fixed at some point, which is a larger scale cleanup to clarify and remove assumptions about collection membership. It starts out from the point that SortedSet and its ilk define membership using a Comparator; yet TreeSet.contains() still talks about using equals(), which is simply incorrect. Pulling on that thread for a while reveals a bunch of places in the spec that need adjustment. See the comments in the bug report and the linked email discussions. After these are fixed, the specification and implementation will at least be self-consistent. However, it will still be the case that HashSet, TreeSet, and IdentityHashMap's keyset will have different membership semantics, and if you pass them around interchangeably you might get unexpected results. I think we just have to live with that. s'marks From tobias.oelgarte at gmail.com Mon Feb 25 20:00:07 2019 From: tobias.oelgarte at gmail.com (Tobias Oelgarte) Date: Mon, 25 Feb 2019 21:00:07 +0100 Subject: How does jpackage search for modules? Message-ID: <4a75c1e0-709d-1621-c96b-3a0a308c1834@gmail.com> I'm wondering how jpackage searches for modules. I tried to build a very simple example (using Build 17 of jpackage), but jpackage always claims that the module can't be found. ~$ ./jpackage create-image \ ??? --output /data/projects/javam/de.asysgmbh.app.test/target/image \ ??? --name test \ ??? --main-class de.asysgmbh.app.test.Main \ ??? --module de.asysgmbh.app.test \ ??? --module-path /data/projects/javam/de.asysgmbh.app.test/target/modules ~ $ Module de.asysgmbh.app.test does not exist. The modules directory contains the file "de.asysgmbh.app.test-1.0-SNAPSHOT.jar" including the module-info.class with the module named "de.asysgmbh.app.test". ??? module de.asysgmbh.app.test { ... } The following works just fine: ~$ java \ ??? --module-path /data/projects/javam/de.asysgmbh.app.test/target/modules \ ??? --module de.asysgmbh.app.test/de.asysgmbh.app.test.Main -- Tobias Oelgarte Mail: tobias.oelgarte at gmail.com From javalists at cbfiddle.com Mon Feb 25 20:33:56 2019 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 25 Feb 2019 12:33:56 -0800 Subject: JDK-6982173: Small problem causing thousands of wasted CPU hours In-Reply-To: References: <53b9567e-c820-d6d9-1867-de8a48a38314@gmx.de> <0259cf4c-5159-50c5-b4eb-dc688a49766e@oracle.com> <220EE759-20E8-429D-AA4B-CC5D4115CA7E@cbfiddle.com> <6636354e-99af-87d1-e80a-52f8e45f69f1@oracle.com> <143497CB-8EC0-4940-BBAF-4485BC6FC147@cbfiddle.com> Message-ID: <5AFB5475-E023-4AD6-AE91-25C2C9540EE2@cbfiddle.com> > I think the original idea was that the "general contract" was that collections contained elements whose membership was defined by equals(). However, for a very long time now there have been collections in the JDK such as SortedSet and IdentityHashMap (more precisely, IdentityHashMap's keyset). I think we have to accept the fact that these are collections even though their membership semantics differ from those provided by equals(). Perhaps we must accept their placement in the type hierarchy for compatibility reasons, but it seems reasonable to me to declare these exceptional classes to be nonstandard, which means that their behavior when used as a Collection might be unexpected. An alternative, perhaps, would be to add methods that describe the nature of the membership, e.g. whether based on equals/hash or a comparator (or something else?), which would then become part of the general contract. You?ll probably call this a non-starter :-) > After these are fixed, the specification and implementation will at least be self-consistent. However, it will still be the case that HashSet, TreeSet, and IdentityHashMap's keyset will have different membership semantics, and if you pass them around interchangeably you might get unexpected results. I think we just have to live with that. I?m not sure what you mean by interchangeably. A TreeSet could misbehave when passed to a TreeSet if the method assumes the ?general contract? is satisfied by its parameter. Or are you adding a special-case requirement that every method on a Collection that takes a Collection parameter must behave properly when the actual argument is an instance of the same class, or something like that? > Once we've admitted to the fact that different collections can have different membership semantics, the main point of this bug (JDK-6982173) is to fix up the semantics of AbstractSet.removeAll() to remove the semantic shifting that can occur based on the relative sizes of the collections. If we declare that collections can have different membership semantics and still satisfy the general contract of Collection, then we need to come up with a new specification of the general contract. However, if we specify that membership based on anything other than equals/hash is nonstandard, then this ?bug? is not a bug. It is a valid implementation on the assumption that the parameter satisfies the general contract of the parameter type. The behavior that you call a semantic shift, I would call an unexpected behavior resulting from using a nonstandard collection where a Collection was expected. I also believe that the performace penalty of fixing this bug is ?astonishing?. One could argue whether the performance penalty is more or less astonishing than the unexpected behavior when a non-standard collection is used as the parameter. > Introducing a new interface type is basically a non-starter. Hopefully, what you mean is that introducting a new interface type and incompatibly rearranging the type hierarchy is a non-starter. I still think it would be useful to: 1. introduce a Membership interface 2. have Collection extend Membership 3. add a method to Collection: removeAllMembers(Membership) > Objects of type Collection get passed around a lot, and users can usefully rely on things like size(), they can iterate the Collection, etc. Except when they are implementing something like removeAll()? They can iterate but not assume that they are getting all the objects that are members of the collection, but instead they are getting representative objects? Alan > On Feb 25, 2019, at 11:06 AM, Stuart Marks wrote: > > > > On 2/15/19 11:30 AM, Alan Snyder wrote: >> I think this situation is a mess. >> The ?general contract? of a Collection, I believe, is that it contains zero >> or more identified member objects, as defined by appropriate equals() method. >> I know this is hard to specify precisely, but I presume we all ?know it when >> we see it?. >> There is value to ?collections? whose members are not objects but are >> equivalence classes of objects, as defined by a nonstandard equality test, >> but I think it is a mistake to call them Collections. >> If a method takes a parameter of type Collection, it should be free to assume >> that the parameter object supports the ?general contract? of Collection. Is >> there any plausible alternative? > > [back from vacation] > > Yes, this situation is something of a mess. > > I think the original idea was that the "general contract" was that collections contained elements whose membership was defined by equals(). However, for a very long time now there have been collections in the JDK such as SortedSet and IdentityHashMap (more precisely, IdentityHashMap's keyset). I think we have to accept the fact that these are collections even though their membership semantics differ from those provided by equals(). > >> Changing one method in the JDK to support a non-standard Collection parameter >> does not solve the problem, because non-JDK methods with Collection (etc.) >> parameters could have similar ?misbehavior?. How would the developer know >> when a specific TreeSet can or cannot be passed to a method? Does every >> method that accepts a Collection (etc.) parameter require boilerplate (as in >> the disjoint example) explaining its exact requirements or how it can go >> wrong? >> Perhaps it would be useful to define specific behaviors that these >> nonstandard ?collections? might support. For example, a Membership interface >> (with method contains(e)) would be perfect for a removeAll(Membership) method >> on Collection, implemented as you propose. > The wording on Collections.disjoint() is particularly clumsy. I'm not entirely sure what to do about it and its implementation; suggestions welcome. But I also don't think Collections.disjoint() is a very important problem, compared to what's going on in the rest of the framework. > > Introducing a new interface type is basically a non-starter. Objects of type Collection get passed around a lot, and users can usefully rely on things like size(), they can iterate the Collection, etc. > > Once we've admitted to the fact that different collections can have different membership semantics, the main point of this bug (JDK-6982173) is to fix up the semantics of AbstractSet.removeAll() to remove the semantic shifting that can occur based on the relative sizes of the collections. > > There's another bug JDK-8190545 that needs to be fixed at some point, which is a larger scale cleanup to clarify and remove assumptions about collection membership. It starts out from the point that SortedSet and its ilk define membership using a Comparator; yet TreeSet.contains() still talks about using equals(), which is simply incorrect. Pulling on that thread for a while reveals a bunch of places in the spec that need adjustment. See the comments in the bug report and the linked email discussions. > > After these are fixed, the specification and implementation will at least be self-consistent. However, it will still be the case that HashSet, TreeSet, and IdentityHashMap's keyset will have different membership semantics, and if you pass them around interchangeably you might get unexpected results. I think we just have to live with that. > > s'marks > From mandy.chung at oracle.com Mon Feb 25 21:13:31 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Feb 2019 13:13:31 -0800 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> Message-ID: Hi Andrew, I think initializing LangReflectAccess in AccessibleObject is a better fix. Besides moving clinit to AccessibleObject, ReflectionFactory::langReflectAccess can simply assert if langReflectAccess is non-null. Attached is the patch that you can reference. We should do more testing to shake out any issue. Can you run jdk-submit? Mandy On 2/25/19 7:00 AM, Andrew Leonard wrote: > Hi Mandy, > I can confirm "just" moving the clinit code into AccessibleObject does > resolve the J9 issue as well, without changing ReflectionFactory... > What's your thoughts? > Thanks > Andrew -------------- next part -------------- --- old/src/java.base/share/classes/java/lang/reflect/AccessibleObject.java 2019-02-25 11:21:24.000000000 -0800 +++ new/src/java.base/share/classes/java/lang/reflect/AccessibleObject.java 2019-02-25 11:21:23.000000000 -0800 @@ -75,6 +75,16 @@ */ public class AccessibleObject implements AnnotatedElement { + /* + * Bootstrapping protocol between java.lang and java.lang.reflect + * packages + */ + static { + ReflectionFactory factory = AccessController.doPrivileged( + new ReflectionFactory.GetReflectionFactoryAction()); + factory.setLangReflectAccess(new java.lang.reflect.ReflectAccess()); + } + static void checkPermission() { SecurityManager sm = System.getSecurityManager(); if (sm != null) { --- old/src/java.base/share/classes/java/lang/reflect/Modifier.java 2019-02-25 11:21:25.000000000 -0800 +++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java 2019-02-25 11:21:24.000000000 -0800 @@ -47,16 +47,6 @@ */ public class Modifier { - /* - * Bootstrapping protocol between java.lang and java.lang.reflect - * packages - */ - static { - ReflectionFactory factory = AccessController.doPrivileged( - new ReflectionFactory.GetReflectionFactoryAction()); - factory.setLangReflectAccess(new java.lang.reflect.ReflectAccess()); - } - /** * Return {@code true} if the integer argument includes the * {@code public} modifier, {@code false} otherwise. --- old/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java 2019-02-25 11:21:26.000000000 -0800 +++ new/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java 2019-02-25 11:21:25.000000000 -0800 @@ -726,13 +726,7 @@ } private static LangReflectAccess langReflectAccess() { - if (langReflectAccess == null) { - // Call a static method to get class java.lang.reflect.Modifier - // initialized. Its static initializer will cause - // setLangReflectAccess() to be called from the context of the - // java.lang.reflect package. - Modifier.isPublic(Modifier.PUBLIC); - } + assert langReflectAccess != null; return langReflectAccess; } From andy.herrick at oracle.com Mon Feb 25 21:20:49 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 25 Feb 2019 16:20:49 -0500 Subject: How does jpackage search for modules? In-Reply-To: <4a75c1e0-709d-1621-c96b-3a0a308c1834@gmail.com> References: <4a75c1e0-709d-1621-c96b-3a0a308c1834@gmail.com> Message-ID: Tobias: After the latest fix (JDK-8217798: modular jar linking in jpackage) the following now works: jpackage create-image --module de.asysgmbh.app.test/de.asysgmbh.app.test.Main --module-path /data/projects/javam/de.asysgmbh.app.test/target/modules ... will work fine, but jpackage create-image --module de.asysgmbh.app.test --main-class de.asysgmbh.app.test.Main --module-path /data/projects/javam/de.asysgmbh.app.test/target/modules ... will not work. (actually it will build but them not run, saying: "module XXX does not have a ModuleMainClass attribute, use -m /) In any case the latest EA does not work with modular jars, and a future version will prohibit mixing --module with --main-class options. The help text will be re-written to clarify which options are used in which use cases. /Andy On 2/25/2019 3:00 PM, Tobias Oelgarte wrote: > I'm wondering how jpackage searches for modules. I tried to build a > very simple example (using Build 17 of jpackage), but jpackage always > claims that the module can't be found. > > ~$ ./jpackage create-image \ > ??? --output /data/projects/javam/de.asysgmbh.app.test/target/image \ > ??? --name test \ > ??? --main-class de.asysgmbh.app.test.Main \ > ??? --module de.asysgmbh.app.test \ > ??? --module-path > /data/projects/javam/de.asysgmbh.app.test/target/modules > ~ $ Module de.asysgmbh.app.test does not exist. > > The modules directory contains the file > "de.asysgmbh.app.test-1.0-SNAPSHOT.jar" including the > module-info.class with the module named "de.asysgmbh.app.test". > > ??? module de.asysgmbh.app.test { ... } > > The following works just fine: > > ~$ java \ > ??? --module-path > /data/projects/javam/de.asysgmbh.app.test/target/modules \ > ??? --module de.asysgmbh.app.test/de.asysgmbh.app.test.Main > From tobias.oelgarte at gmail.com Mon Feb 25 21:58:36 2019 From: tobias.oelgarte at gmail.com (Tobias Oelgarte) Date: Mon, 25 Feb 2019 22:58:36 +0100 Subject: How does jpackage search for modules? In-Reply-To: References: <4a75c1e0-709d-1621-c96b-3a0a308c1834@gmail.com> Message-ID: Thank you Andy, for clarifying. I thought i was missing some detail. Guess, I will have to be a bit more patient. ;-) /Tobias Oelgarte On 25.02.19 22:20, Andy Herrick wrote: > Tobias: > > After the latest fix (JDK-8217798: modular jar linking in jpackage) > the following now works: > > jpackage create-image --module > de.asysgmbh.app.test/de.asysgmbh.app.test.Main --module-path > /data/projects/javam/de.asysgmbh.app.test/target/modules ... > > will work fine, but > > jpackage create-image --module de.asysgmbh.app.test --main-class > de.asysgmbh.app.test.Main --module-path > /data/projects/javam/de.asysgmbh.app.test/target/modules ... > > will not work. (actually it will build but them not run, saying: > "module XXX does not have a ModuleMainClass attribute, use -m > /) > > In any case the latest EA does not work with modular jars, and a > future version will prohibit mixing --module with --main-class options. > > The help text will be re-written to clarify which options are used in > which use cases. > > /Andy > > > > On 2/25/2019 3:00 PM, Tobias Oelgarte wrote: >> I'm wondering how jpackage searches for modules. I tried to build a >> very simple example (using Build 17 of jpackage), but jpackage always >> claims that the module can't be found. >> >> ~$ ./jpackage create-image \ >> ??? --output /data/projects/javam/de.asysgmbh.app.test/target/image \ >> ??? --name test \ >> ??? --main-class de.asysgmbh.app.test.Main \ >> ??? --module de.asysgmbh.app.test \ >> ??? --module-path >> /data/projects/javam/de.asysgmbh.app.test/target/modules >> ~ $ Module de.asysgmbh.app.test does not exist. >> >> The modules directory contains the file >> "de.asysgmbh.app.test-1.0-SNAPSHOT.jar" including the >> module-info.class with the module named "de.asysgmbh.app.test". >> >> ??? module de.asysgmbh.app.test { ... } >> >> The following works just fine: >> >> ~$ java \ >> ??? --module-path >> /data/projects/javam/de.asysgmbh.app.test/target/modules \ >> ??? --module de.asysgmbh.app.test/de.asysgmbh.app.test.Main >> > From joe.darcy at oracle.com Mon Feb 25 22:42:29 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 25 Feb 2019 14:42:29 -0800 Subject: JDK 13 RFR of JDK-8219561: Update jdeprscan to avoid the need for start-of-release changes In-Reply-To: <6e7ce170-6ce5-a1fb-8fed-12ef8680c1b5@oracle.com> References: <41ef2545-6715-9346-be59-917eb645e9f1@oracle.com> <6e7ce170-6ce5-a1fb-8fed-12ef8680c1b5@oracle.com> Message-ID: <8b268208-120f-875f-7c10-aa05f0283d55@oracle.com> Hi Stuart, Will push with suggested refactoring; thanks for the review, -Joe On 2/25/2019 10:40 AM, Stuart Marks wrote: > Hi Joe, > > Thanks for cleaning up jdeprscan. > > For computing the set of releases, I'd prefer to see a stream that > looks like this: > > ??????? final Set releasesWithForRemoval = > ??????????? IntStream.rangeClosed(9, Runtime.version().feature()) > ???????????????????? .mapToObj(Integer::toString) > ???????????????????? .collect(Collectors.toUnmodifiableSet()); > > This collects the values directly to an unmodifiable set, instead of > populating an array which is then passed to Set.of(). > > Thanks, > > s'marks > > On 2/21/19 6:15 PM, Joe Darcy wrote: >> Hello, >> >> Internally jdeprscan initializes a set of strings of releases >> supporting deprecation with removal. Currently those releases are JDK >> 9 and subsequent values. The lists is explicitly initialized and must >> be updated at the start of a release, which adds to the maintenance >> cost of starting a new release. The update for JDK 13 was: >> >> --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java >> Thu Dec 13 17:01:15 2018 +0100 >> +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java >> Thu Dec 13 19:06:11 2018 +0100 >> @@ -106,7 +106,7 @@ >> ????? // Keep these updated manually until there's a compiler API >> ????? // that allows querying of supported releases. >> ????? final Set releasesWithoutForRemoval = Set.of("6", "7", >> "8"); >> -??? final Set releasesWithForRemoval = Set.of("9", "10", >> "11", "12"); >> +??? final Set releasesWithForRemoval = Set.of("9", "10", >> "11", "12", "13"); >> >> ????? final Set validReleases; >> ????? { >> >> >> Initializing the list more programmatically could avoid the need for >> an explicit update for the start of a release. Please review the >> patch below for the programmatic initialization: >> >> --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java >> Thu Feb 21 15:17:42 2019 -0800 >> +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java >> Thu Feb 21 18:01:59 2019 -0800 >> @@ -45,6 +45,7 @@ >> ??import java.util.NoSuchElementException; >> ??import java.util.Set; >> ??import java.util.Queue; >> +import java.util.stream.IntStream; >> ??import java.util.stream.Stream; >> ??import java.util.stream.StreamSupport; >> ??import java.util.jar.JarEntry; >> @@ -106,7 +107,12 @@ >> ????? // Keep these updated manually until there's a compiler API >> ????? // that allows querying of supported releases. >> ????? final Set releasesWithoutForRemoval = Set.of("6", "7", >> "8"); >> -??? final Set releasesWithForRemoval = Set.of("9", "10", >> "11", "12", "13"); >> +??? // Set.of("9", "10", "11", "12", "13"); >> +??? final Set releasesWithForRemoval = Set.of(// "9", "10", >> "11", ... >> +??????? IntStream.rangeClosed(9, Runtime.version().feature()) >> +??????? .mapToObj(Integer::toString) >> +??????? .toArray(String[]::new)); >> + >> >> ????? final Set validReleases; >> ????? { >> >> Thanks, >> >> -Joe >> From alexander.matveev at oracle.com Mon Feb 25 22:55:50 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 25 Feb 2019 14:55:50 -0800 Subject: RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder. In-Reply-To: References: <71615f59-bc90-36b4-1c88-6e7dfafc9161@oracle.com> <94b77c01-9a1b-cb13-24e9-ab0cf9a5b5a3@oracle.com> Message-ID: <7e54ad71-2bfc-1b44-2781-8ce6305eac58@oracle.com> Hi Andy, Updated version looks fine as well. Thank, Alexander On 2/25/2019 5:19 AM, Andy Herrick wrote: > I uploaded webrev version 04 > (http://cr.openjdk.java.net/~herrick/8218055/webrev.04) which is same > as version 03 except "JLink" is changed to "jlink" in several messages. > > /ANdy > > > On 2/22/2019 2:37 PM, Mandy Chung wrote: >> >> >> On 2/22/19 9:50 AM, Andy Herrick wrote: >>> revised webrev t address issues brought up by Mandy: >>> >>> [2] http://cr.openjdk.java.net/~herrick/8218055/webrev.03 >> >> I only looked at JLinkBundlerHelper.java and the removed >> files that look okay.? Nit: can you use "jlink" lower case >> in the log/exception message (that's the tool's name). >> >> Someone else who knows this area should review. >> >> Mandy > From mandy.chung at oracle.com Tue Feb 26 00:16:13 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Feb 2019 16:16:13 -0800 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> Message-ID: <04c24776-3b1b-c31e-5532-f82aee02ae8c@oracle.com> On 2/25/19 5:12 AM, Andrew Leonard wrote: > Hi Mandy, > I must admit I don't completely follow the logic of the existing > Modifier init of langReflectAccess, the comment indicates a "protocol > between java.lang and java.lang.reflect". That sets up the shared secret for ReflectionFactory to access non-public members in java.lang.reflect. > I can try moving the clinit > code from Modifier to AccessibleObject, but I question is there some > reason it is there? Would we be sure in moving it we are not missing > something? ReflectionFactory is the internal support for reflection. The methods that access LangReflectAccess shared secrets should have a Method, Field or Constructor in hand. The ReflectionFactory::newField and newMethod that don't take Field/Method parameter are unused (I suspect they were used by the VM native reflection implementation previously. That led me to suggest to move setLangReflectAccess to AccessibleObject. AccessibleObject is initialized very early during startup by the VM. My proposed fix would change the list of classes loaded during early startup but it would need to look at closely. Having a second thought, my proposed fix can be a follow-on clean up. I'm okay with your point fix that resolves JDK-8219378. I will file a JBS issue for the follow-on clean up. What do you think? thanks Mandy From andy.herrick at oracle.com Tue Feb 26 13:15:07 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 26 Feb 2019 08:15:07 -0500 Subject: RFR: JDK-8217902: jpackage fails with --app-image option on mac Message-ID: <8540cf7b-ce07-e827-54c1-80f1cfa86959@oracle.com> ?JDK-8217902: jpackage fails with --app-image option on mac Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). The fix is to remove the over-aggressive validation in DeployParams.validate() and update WinAppBundler to be the same as Mac code. [1] https://bugs.openjdk.java.net/browse/JDK-8217902 [2] http://cr.openjdk.java.net/~herrick/8217902/webrev.01/ /ANdy From andy.herrick at oracle.com Tue Feb 26 13:20:35 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 26 Feb 2019 08:20:35 -0500 Subject: RFR: JDK-8219695: Use a copy of javac's implementation of @argfile in jpackager Message-ID: <7308cee6-7d7e-fb7e-9be9-b0bae8374348@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). The fix is to include the code for processing @argfile from javac into jpackage. [1] https://bugs.openjdk.java.net/browse/JDK-8219695 [2] http://cr.openjdk.java.net/~herrick/8219695/ /Andy From kevin.rushforth at oracle.com Tue Feb 26 13:35:18 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Feb 2019 05:35:18 -0800 Subject: RFR: JDK-8219695: Use a copy of javac's implementation of @argfile in jpackager In-Reply-To: <7308cee6-7d7e-fb7e-9be9-b0bae8374348@oracle.com> References: <7308cee6-7d7e-fb7e-9be9-b0bae8374348@oracle.com> Message-ID: Looks good to me. -- Kevin On 2/26/2019 5:20 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > The fix is to include the code for processing @argfile from javac into > jpackage. > > [1] https://bugs.openjdk.java.net/browse/JDK-8219695 > > [2] http://cr.openjdk.java.net/~herrick/8219695/ > > /Andy > From Roger.Riggs at oracle.com Tue Feb 26 15:55:23 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 26 Feb 2019 10:55:23 -0500 Subject: RFR: JDK-8219695: Use a copy of javac's implementation of @argfile in jpackager In-Reply-To: References: <7308cee6-7d7e-fb7e-9be9-b0bae8374348@oracle.com> Message-ID: <2858398f-175e-33d9-9c6d-dd9c26e35831@oracle.com> Hi, The copyright in CommandLine.java should be 2019, the package declaration changed, though probably nothing else. $.02, Roger On 02/26/2019 08:35 AM, Kevin Rushforth wrote: > Looks good to me. > > -- Kevin > > > On 2/26/2019 5:20 AM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> The fix is to include the code for processing @argfile from javac >> into jpackage. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8219695 >> >> [2] http://cr.openjdk.java.net/~herrick/8219695/ >> >> /Andy >> > From andrew_m_leonard at uk.ibm.com Tue Feb 26 16:46:29 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 26 Feb 2019 16:46:29 +0000 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: <04c24776-3b1b-c31e-5532-f82aee02ae8c@oracle.com> References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> <04c24776-3b1b-c31e-5532-f82aee02ae8c@oracle.com> Message-ID: Hi Mandy, I think your last proposal sounds a good plan, push 8219378 to fix the immediate issue and create a new change to refactor the clinit location... As I am not a "Committer" (yet! working on it!) I can't use the Submit repo. I have built your patch and run a bunch of tests locally and it works great. I have also tested it successfully with J9. So I am happy with your change. If Roger & yourself are happy with 8219378, can we Submit-repo it for final test and get that one merged? Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Mandy Chung To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net, Roger Riggs Date: 26/02/2019 00:16 Subject: Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized On 2/25/19 5:12 AM, Andrew Leonard wrote: > Hi Mandy, > I must admit I don't completely follow the logic of the existing > Modifier init of langReflectAccess, the comment indicates a "protocol > between java.lang and java.lang.reflect". That sets up the shared secret for ReflectionFactory to access non-public members in java.lang.reflect. > I can try moving the clinit > code from Modifier to AccessibleObject, but I question is there some > reason it is there? Would we be sure in moving it we are not missing > something? ReflectionFactory is the internal support for reflection. The methods that access LangReflectAccess shared secrets should have a Method, Field or Constructor in hand. The ReflectionFactory::newField and newMethod that don't take Field/Method parameter are unused (I suspect they were used by the VM native reflection implementation previously. That led me to suggest to move setLangReflectAccess to AccessibleObject. AccessibleObject is initialized very early during startup by the VM. My proposed fix would change the list of classes loaded during early startup but it would need to look at closely. Having a second thought, my proposed fix can be a follow-on clean up. I'm okay with your point fix that resolves JDK-8219378. I will file a JBS issue for the follow-on clean up. What do you think? thanks Mandy 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 Roger.Riggs at oracle.com Tue Feb 26 16:56:50 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 26 Feb 2019 11:56:50 -0500 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> <04c24776-3b1b-c31e-5532-f82aee02ae8c@oracle.com> Message-ID: <85abfac7-5908-34c9-448e-fe425e7124f8@oracle.com> Hi Andrew, I've got the changeset you sent earlier and have tested it as well. I'll push it today unless there any objections. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reflectionfactory-8219378-2/ Roger On 02/26/2019 11:46 AM, Andrew Leonard wrote: > Hi Mandy, > I think your last proposal sounds a good plan, push 8219378 to fix the > immediate issue and create a new change to refactor the clinit > location... > As I am not a "Committer" (yet! working on it!) I can't use the Submit > repo. > I have built your patch and run a bunch of tests locally and it works > great. I have also tested it successfully with J9. So I am happy with > your change. > > If Roger & yourself are happy with 8219378, can we Submit-repo it for > final test and get that one merged? > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Mandy Chung > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net, Roger Riggs > Date: 26/02/2019 00:16 > Subject: Re: Fix proposal: JDK-8219378 NPE in > ReflectionFactory.newMethodAccessor when langReflectAccess not > initialized > ------------------------------------------------------------------------ > > > > > > On 2/25/19 5:12 AM, Andrew Leonard wrote: > > Hi Mandy, > > I must admit I don't completely follow the logic of the existing > > Modifier init of langReflectAccess, the comment indicates a "protocol > > between java.lang and java.lang.reflect". > > That sets up the shared secret for ReflectionFactory to access > non-public members in java.lang.reflect. > > > I can try moving the clinit > > code from Modifier to AccessibleObject, but I question is there some > > reason it is there? Would we be sure in moving it we are not missing > > something? > > ReflectionFactory is the internal support for reflection. > The methods that access LangReflectAccess shared secrets > should have a Method, Field or Constructor in hand. ?The > ReflectionFactory::newField and newMethod that don't take > Field/Method parameter are unused (I suspect they were > used by the VM native reflection implementation previously. > That led me to suggest to move setLangReflectAccess to > AccessibleObject. > > AccessibleObject is initialized very early during startup > by the VM. ?My proposed fix would change the list of > classes loaded during early startup but it would need to > look at closely. > > Having a second thought, my proposed fix can be a follow-on > clean up. I'm okay with your point fix that resolves JDK-8219378. > I will file a JBS issue for the follow-on clean up. ?What do > you think? > > thanks > Mandy > > > > > 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 mandy.chung at oracle.com Tue Feb 26 17:01:31 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 26 Feb 2019 09:01:31 -0800 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: <85abfac7-5908-34c9-448e-fe425e7124f8@oracle.com> References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> <04c24776-3b1b-c31e-5532-f82aee02ae8c@oracle.com> <85abfac7-5908-34c9-448e-fe425e7124f8@oracle.com> Message-ID: On 2/26/19 8:56 AM, Roger Riggs wrote: > Hi Andrew, > > I've got the changeset you sent earlier and have tested it as well. > > I'll push it today unless there any objections. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-reflectionfactory-8219378-2/ > +1 Mandy > Roger > > > On 02/26/2019 11:46 AM, Andrew Leonard wrote: >> Hi Mandy, >> I think your last proposal sounds a good plan, push 8219378 to fix >> the immediate issue and create a new change to refactor the clinit >> location... >> As I am not a "Committer" (yet! working on it!) I can't use the >> Submit repo. >> I have built your patch and run a bunch of tests locally and it works >> great. I have also tested it successfully with J9. So I am happy with >> your change. >> >> If Roger & yourself are happy with 8219378, can we Submit-repo it for >> final test and get that one merged? >> Many thanks >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> Phone internal: 245913, external: 01962 815913 >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> >> >> From: Mandy Chung >> To: Andrew Leonard >> Cc: core-libs-dev at openjdk.java.net, Roger Riggs >> Date: 26/02/2019 00:16 >> Subject: Re: Fix proposal: JDK-8219378 NPE in >> ReflectionFactory.newMethodAccessor when langReflectAccess not >> initialized >> ------------------------------------------------------------------------ >> >> >> >> >> >> On 2/25/19 5:12 AM, Andrew Leonard wrote: >> > Hi Mandy, >> > I must admit I don't completely follow the logic of the existing >> > Modifier init of langReflectAccess, the comment indicates a "protocol >> > between java.lang and java.lang.reflect". >> >> That sets up the shared secret for ReflectionFactory to access >> non-public members in java.lang.reflect. >> >> > I can try moving the clinit >> > code from Modifier to AccessibleObject, but I question is there some >> > reason it is there? Would we be sure in moving it we are not missing >> > something? >> >> ReflectionFactory is the internal support for reflection. >> The methods that access LangReflectAccess shared secrets >> should have a Method, Field or Constructor in hand. ?The >> ReflectionFactory::newField and newMethod that don't take >> Field/Method parameter are unused (I suspect they were >> used by the VM native reflection implementation previously. >> That led me to suggest to move setLangReflectAccess to >> AccessibleObject. >> >> AccessibleObject is initialized very early during startup >> by the VM. ?My proposed fix would change the list of >> classes loaded during early startup but it would need to >> look at closely. >> >> Having a second thought, my proposed fix can be a follow-on >> clean up. I'm okay with your point fix that resolves JDK-8219378. >> I will file a JBS issue for the follow-on clean up. ?What do >> you think? >> >> thanks >> Mandy >> >> >> >> >> 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 mandy.chung at oracle.com Tue Feb 26 17:20:21 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 26 Feb 2019 09:20:21 -0800 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> <04c24776-3b1b-c31e-5532-f82aee02ae8c@oracle.com> Message-ID: <7145d8cb-0cfb-047d-fe04-cf4306d92e00@oracle.com> Hi Andrew, Thanks for verifying the suggested patch.? I created https://bugs.openjdk.java.net/browse/JDK-8219774 to follow up this. Mandy On 2/26/19 8:46 AM, Andrew Leonard wrote: > Hi Mandy, > I think your last proposal sounds a good plan, push 8219378 to fix the > immediate issue and create a new change to refactor the clinit > location... > As I am not a "Committer" (yet! working on it!) I can't use the Submit > repo. > I have built your patch and run a bunch of tests locally and it works > great. I have also tested it successfully with J9. So I am happy with > your change. > > If Roger & yourself are happy with 8219378, can we Submit-repo it for > final test and get that one merged? > Many thanks > Andrew From dmitry.chuyko at bell-sw.com Tue Feb 26 20:23:25 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 26 Feb 2019 23:23:25 +0300 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: <7a519513-aa92-269b-f5bb-9bbe1bd1bfe7@oracle.com> References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> <2b7fc762-d0a6-3452-c57e-30a4447b5149@oracle.com> <2d4ee3bd-b3e0-21d6-7868-745d94e9b354@oracle.com> <3BFFC665-C15F-43B6-AB7D-49D7C3A97677@oracle.com> <7a519513-aa92-269b-f5bb-9bbe1bd1bfe7@oracle.com> Message-ID: I made mentioned cleanups in changed code, just in case here is a webrev without functional changes: function renaming, comments, indents (just a couple), void*. http://cr.openjdk.java.net/~dchuyko/8215009/webrev.04/ Started dev-submit for that patch. -Dmitry On 2/25/19 9:37 PM, Roger Riggs wrote: > +1 > > Much cleaner, since it does not need to be more general. > > I'd probably add a comment to the ThreadJavaMain method > to say why it is needed. > > BTW, it looks like the indents have gotten mixed up between 2 spaces > and 4. > For the libjli it should be 4 spaces. > But this change is probably not the place to fix it and it is locally > consistent. > > Thanks, Roger > > On 02/25/2019 01:16 PM, Mikael Vidstedt wrote: >> >>> On Feb 25, 2019, at 9:09 AM, Dmitry Chuyko >>> wrote: >>> >>> On 2/22/19 9:55 PM, Roger Riggs wrote: >>>> Hi, >>>> >>>> After a closer look, I'd take the route of the 01 webrev. >>>> It is more localized and does not force the function signature needed >>>> by pthread_create to be propagated elsewhere. >>>> >>>> The code can be a lot more comprehensible by renaming the CallIntFunc >>>> function to be specific to ContinueInNewThread0. It looks like a >>>> trampoline to me. >>>> The data structure being passed is on the stack of the caller of >>>> pthread_create. >>>> It seems safe to refer to it here because the caller will wait in >>>> pthread_join. >>> After some hesitation it looks like ContinueInNewThread0 may know >>> about JavaMain just like ContinueInNewThread, no need to work with >>> abstract continuation. Even that abstract continuation is limited to >>> int return type. In webrev.02 continuation gets platform specific >>> signature. But then we have to cast the result where the call is >>> direct. Another approach in that direction could be to add result >>> field in JavaMainArgs, but it will again force ContinueInNewThread0 >>> to know about continuation's parameters structure as there may be a >>> direct call of continuation. >>> >>> If we let ContinueInNewThread0 call only JavaMain, it all can work >>> without extra trampoline structures (just need a wrapper): >>> >>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.03/ >>> >> I like it! Since ContinueInNewThread0 is now always calling JavaMain >> I guess it could be renamed to CallJavaMainInNewThread (or something >> to that same effect). > I'm fine with the rename (no additional review necessary). > >> >> Minor nit: some consistency in where the ?*? is placed in the various >> ?void *? places would be nice. >> >> Cheers, >> Mikael >> >>> -Dmitry >>> >>>> Also important is to document that the return type is specific to >>>> the OS >>>> and is needed to cast the return value expected by the >>>> start_pthread_create >>>> start_routine.? That may still be in question because pthread_create >>>> expects void*. >>>> >>>> $.02, Roger >>>> >>>> >>>> On 02/22/2019 10:32 AM, Roger Riggs wrote: >>>>> Hi, >>>>> >>>>> If the warning can be addressed with an extra in-line cast then >>>>> that's >>>>> cleaner and easier to understand than replicating that structure >>>>> in 3 files. >>>>> And of course, add a comment. >>>>> To make the source more readable, the cast could be factored >>>>> into a macro in the same file with the comment about why it is >>>>> needed. >>>>> >>>>> Roger >>>>> >>>>> >>>>> On 02/21/2019 11:07 PM, David Holmes wrote: >>>>>> On 22/02/2019 4:55 am, Mikael Vidstedt wrote: >>>>>>> The wrapper based solution looks much cleaner to me as well. >>>>>>> webrev.01 looks good. >>>>>> Sorry I really don't like it. The wrappers obfuscate and make >>>>>> complicated something that is not at all complicated. I have to >>>>>> re-read the new code 3 times to figure out what it is even doing! >>>>>> >>>>>> All that complexity to handle the fact one platform wants to >>>>>> return int instead of void* ?? >>>> The complexity is due to the function being called in some other >>>> thread >>>> context and there is a necessary cast/type conversion on the return >>>> value >>>> from the start_routine that has to come back through pthread to >>>> pthread_join. >>>> >>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> (not a Reviewer) >>>>>>> >>>>>>> Cheers, >>>>>>> Mikael >>>>>>> >>>>>>>> On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko >>>>>>>> wrote: >>>>>>>> >>>>>>>> To me thread function wrappers look preferable to platform >>>>>>>> specific JavaMain signature. Consider this webrev with wrappers: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ >>>>>>>> >>>>>>>> In some cases JavaMain is called in the same thread and its >>>>>>>> result is returned from JLI_Launch. ContinueInNewThread is in >>>>>>>> shared code. And JavaMain uses macro controlled returns. >>>>>>>> So when JavaMain returns THREAD_FUNC_RETURN changes may contain >>>>>>>> some quite artificial macro parts in java.c: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 12/19/18 9:27 AM, David Holmes wrote: >>>>>>>>> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >>>>>>>>>> On 12/18/18 3:39 AM, David Holmes wrote: >>>>>>>>>>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>>>>>>>>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review a small fix in java_md_solinux.c: >>>>>>>>>>>>>> continuation is not truly compatible with pthread_create >>>>>>>>>>>>>> start_routine's signature but we control what actually >>>>>>>>>>>>>> happens. So it makes sense to add intermediate void* cast >>>>>>>>>>>>>> to silence the error. >>>>>>>>>>>>> I'd be tempted to fix the signature and get rid of all the >>>>>>>>>>>>> casts. >>>>>>>>>>>> David, the signature is a signature of >>>>>>>>>>>> >>>>>>>>>>>> int JNICALL JavaMain(void * _args) >>>>>>>>>>>> >>>>>>>>>>>> It would be fun to change it. But still on Windows it is >>>>>>>>>>>> correctly passed to _beginthreadex() and then return code >>>>>>>>>>>> is extracted with GetExitCodeThread(). In case we want it >>>>>>>>>>>> to return void* the cast will move there. >>>>>>>>>>> I think the current double cast is truly ugly and an ifdef >>>>>>>>>>> for windows, or a cast for Windows only would be an >>>>>>>>>>> improvement. >>>>>>>>>> I agree. Maybe making a wrapper function is not so ugly. If >>>>>>>>>> there are no objections to changing beginning of the call >>>>>>>>>> stack it is quite easy to implement. For consistency it may >>>>>>>>>> be done for all 3 points (posix unix, posix mac, windows) or >>>>>>>>>> just for posix ones. >>>>>>>>>> >>>>>>>>>> It looks like ifdef should be better as long as there are >>>>>>>>>> already OS-specific parts in libjli. Again, if there are no >>>>>>>>>> objections to have different JavaMain signatures on different >>>>>>>>>> platforms. In this case there won't be a signature cast for >>>>>>>>>> Windows. >>>>>>>>> How about setting >>>>>>>>> >>>>>>>>> #define THREAD_FUNC_RETURN int >>>>>>>>> >>>>>>>>> in windows/java_md.h. >>>>>>>>> >>>>>>>>> Then: >>>>>>>>> >>>>>>>>> #ifndef THREAD_FUNC_RETURN >>>>>>>>> ??? #define THREAD_FUNC_RETURN void* >>>>>>>>> #endif >>>>>>>>> >>>>>>>>> in java.h (after the other includes). >>>>>>>>> >>>>>>>>> Then: >>>>>>>>> >>>>>>>>> THREAD_FUNC_RETURN JNICALL >>>>>>>>> JavaMain(void * _args) >>>>>>>>> >>>>>>>>> in java.c. >>>>>>>>> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>>> But I won't impose that on you just to silence gcc 8. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>>>>>>>>>> testing: submit repo >>>>>>>>>>>>>> (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>> > From david.holmes at oracle.com Tue Feb 26 21:07:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2019 07:07:34 +1000 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> <2b7fc762-d0a6-3452-c57e-30a4447b5149@oracle.com> <2d4ee3bd-b3e0-21d6-7868-745d94e9b354@oracle.com> <3BFFC665-C15F-43B6-AB7D-49D7C3A97677@oracle.com> <7a519513-aa92-269b-f5bb-9bbe1bd1bfe7@oracle.com> Message-ID: <745bbfc7-1e82-c11e-a7a8-ba6ed50e6d21@oracle.com> Hi Dmitry, This seems fine to me too - much simpler. Thanks, David On 27/02/2019 6:23 am, Dmitry Chuyko wrote: > I made mentioned cleanups in changed code, just in case here is a webrev > without functional changes: function renaming, comments, indents (just a > couple), void*. > > http://cr.openjdk.java.net/~dchuyko/8215009/webrev.04/ > > Started dev-submit for that patch. > > -Dmitry > > On 2/25/19 9:37 PM, Roger Riggs wrote: >> +1 >> >> Much cleaner, since it does not need to be more general. >> >> I'd probably add a comment to the ThreadJavaMain method >> to say why it is needed. >> >> BTW, it looks like the indents have gotten mixed up between 2 spaces >> and 4. >> For the libjli it should be 4 spaces. >> But this change is probably not the place to fix it and it is locally >> consistent. >> >> Thanks, Roger >> >> On 02/25/2019 01:16 PM, Mikael Vidstedt wrote: >>> >>>> On Feb 25, 2019, at 9:09 AM, Dmitry Chuyko >>>> wrote: >>>> >>>> On 2/22/19 9:55 PM, Roger Riggs wrote: >>>>> Hi, >>>>> >>>>> After a closer look, I'd take the route of the 01 webrev. >>>>> It is more localized and does not force the function signature needed >>>>> by pthread_create to be propagated elsewhere. >>>>> >>>>> The code can be a lot more comprehensible by renaming the CallIntFunc >>>>> function to be specific to ContinueInNewThread0. It looks like a >>>>> trampoline to me. >>>>> The data structure being passed is on the stack of the caller of >>>>> pthread_create. >>>>> It seems safe to refer to it here because the caller will wait in >>>>> pthread_join. >>>> After some hesitation it looks like ContinueInNewThread0 may know >>>> about JavaMain just like ContinueInNewThread, no need to work with >>>> abstract continuation. Even that abstract continuation is limited to >>>> int return type. In webrev.02 continuation gets platform specific >>>> signature. But then we have to cast the result where the call is >>>> direct. Another approach in that direction could be to add result >>>> field in JavaMainArgs, but it will again force ContinueInNewThread0 >>>> to know about continuation's parameters structure as there may be a >>>> direct call of continuation. >>>> >>>> If we let ContinueInNewThread0 call only JavaMain, it all can work >>>> without extra trampoline structures (just need a wrapper): >>>> >>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.03/ >>>> >>> I like it! Since ContinueInNewThread0 is now always calling JavaMain >>> I guess it could be renamed to CallJavaMainInNewThread (or something >>> to that same effect). >> I'm fine with the rename (no additional review necessary). >> >>> >>> Minor nit: some consistency in where the ?*? is placed in the various >>> ?void *? places would be nice. >>> >>> Cheers, >>> Mikael >>> >>>> -Dmitry >>>> >>>>> Also important is to document that the return type is specific to >>>>> the OS >>>>> and is needed to cast the return value expected by the >>>>> start_pthread_create >>>>> start_routine.? That may still be in question because pthread_create >>>>> expects void*. >>>>> >>>>> $.02, Roger >>>>> >>>>> >>>>> On 02/22/2019 10:32 AM, Roger Riggs wrote: >>>>>> Hi, >>>>>> >>>>>> If the warning can be addressed with an extra in-line cast then >>>>>> that's >>>>>> cleaner and easier to understand than replicating that structure >>>>>> in 3 files. >>>>>> And of course, add a comment. >>>>>> To make the source more readable, the cast could be factored >>>>>> into a macro in the same file with the comment about why it is >>>>>> needed. >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> On 02/21/2019 11:07 PM, David Holmes wrote: >>>>>>> On 22/02/2019 4:55 am, Mikael Vidstedt wrote: >>>>>>>> The wrapper based solution looks much cleaner to me as well. >>>>>>>> webrev.01 looks good. >>>>>>> Sorry I really don't like it. The wrappers obfuscate and make >>>>>>> complicated something that is not at all complicated. I have to >>>>>>> re-read the new code 3 times to figure out what it is even doing! >>>>>>> >>>>>>> All that complexity to handle the fact one platform wants to >>>>>>> return int instead of void* ?? >>>>> The complexity is due to the function being called in some other >>>>> thread >>>>> context and there is a necessary cast/type conversion on the return >>>>> value >>>>> from the start_routine that has to come back through pthread to >>>>> pthread_join. >>>>> >>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> (not a Reviewer) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Mikael >>>>>>>> >>>>>>>>> On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> To me thread function wrappers look preferable to platform >>>>>>>>> specific JavaMain signature. Consider this webrev with wrappers: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ >>>>>>>>> >>>>>>>>> In some cases JavaMain is called in the same thread and its >>>>>>>>> result is returned from JLI_Launch. ContinueInNewThread is in >>>>>>>>> shared code. And JavaMain uses macro controlled returns. >>>>>>>>> So when JavaMain returns THREAD_FUNC_RETURN changes may contain >>>>>>>>> some quite artificial macro parts in java.c: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 12/19/18 9:27 AM, David Holmes wrote: >>>>>>>>>> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >>>>>>>>>>> On 12/18/18 3:39 AM, David Holmes wrote: >>>>>>>>>>>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>>>>>>>>>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review a small fix in java_md_solinux.c: >>>>>>>>>>>>>>> continuation is not truly compatible with pthread_create >>>>>>>>>>>>>>> start_routine's signature but we control what actually >>>>>>>>>>>>>>> happens. So it makes sense to add intermediate void* cast >>>>>>>>>>>>>>> to silence the error. >>>>>>>>>>>>>> I'd be tempted to fix the signature and get rid of all the >>>>>>>>>>>>>> casts. >>>>>>>>>>>>> David, the signature is a signature of >>>>>>>>>>>>> >>>>>>>>>>>>> int JNICALL JavaMain(void * _args) >>>>>>>>>>>>> >>>>>>>>>>>>> It would be fun to change it. But still on Windows it is >>>>>>>>>>>>> correctly passed to _beginthreadex() and then return code >>>>>>>>>>>>> is extracted with GetExitCodeThread(). In case we want it >>>>>>>>>>>>> to return void* the cast will move there. >>>>>>>>>>>> I think the current double cast is truly ugly and an ifdef >>>>>>>>>>>> for windows, or a cast for Windows only would be an >>>>>>>>>>>> improvement. >>>>>>>>>>> I agree. Maybe making a wrapper function is not so ugly. If >>>>>>>>>>> there are no objections to changing beginning of the call >>>>>>>>>>> stack it is quite easy to implement. For consistency it may >>>>>>>>>>> be done for all 3 points (posix unix, posix mac, windows) or >>>>>>>>>>> just for posix ones. >>>>>>>>>>> >>>>>>>>>>> It looks like ifdef should be better as long as there are >>>>>>>>>>> already OS-specific parts in libjli. Again, if there are no >>>>>>>>>>> objections to have different JavaMain signatures on different >>>>>>>>>>> platforms. In this case there won't be a signature cast for >>>>>>>>>>> Windows. >>>>>>>>>> How about setting >>>>>>>>>> >>>>>>>>>> #define THREAD_FUNC_RETURN int >>>>>>>>>> >>>>>>>>>> in windows/java_md.h. >>>>>>>>>> >>>>>>>>>> Then: >>>>>>>>>> >>>>>>>>>> #ifndef THREAD_FUNC_RETURN >>>>>>>>>> ??? #define THREAD_FUNC_RETURN void* >>>>>>>>>> #endif >>>>>>>>>> >>>>>>>>>> in java.h (after the other includes). >>>>>>>>>> >>>>>>>>>> Then: >>>>>>>>>> >>>>>>>>>> THREAD_FUNC_RETURN JNICALL >>>>>>>>>> JavaMain(void * _args) >>>>>>>>>> >>>>>>>>>> in java.c. >>>>>>>>>> >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>>> But I won't impose that on you just to silence gcc 8. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>>>>>>>>>>> testing: submit repo >>>>>>>>>>>>>>> (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: PASSED) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>>> >> From alexander.matveev at oracle.com Tue Feb 26 23:25:45 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 26 Feb 2019 15:25:45 -0800 Subject: RFR: JDK-8191709 : javapackager detects WiX 3.10 as 3.1 and fails to use WiX 3.6+ compatible code Message-ID: <47d999e3-9fda-15f1-0188-6965be154473@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Problem was in how we compare versions. We used to compare it as float number, so 3.10 -> 3.1 which was less then 3.6. - Fixed by comparing major and minor version separately. - Fixed minor spelling error in resources. [1] https://bugs.openjdk.java.net/browse/JDK-8191709 [2] http://cr.openjdk.java.net/~almatvee/8191709/webrev.00/ Thanks, Alexander From kevin.rushforth at oracle.com Wed Feb 27 00:17:10 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Feb 2019 16:17:10 -0800 Subject: RFR: JDK-8191709 : javapackager detects WiX 3.10 as 3.1 and fails to use WiX 3.6+ compatible code In-Reply-To: <47d999e3-9fda-15f1-0188-6965be154473@oracle.com> References: <47d999e3-9fda-15f1-0188-6965be154473@oracle.com> Message-ID: The comparison isn't quite right. It will fail if either the major or minor is less than the minimum. This means, for example, that 4.1 will be considered less than 3.6. -- Kevin On 2/26/2019 3:25 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Problem was in how we compare versions. We used to compare it as > float number, so 3.10 -> 3.1 which was less then 3.6. > - Fixed by comparing major and minor version separately. > - Fixed minor spelling error in resources. > > [1] https://bugs.openjdk.java.net/browse/JDK-8191709 > > [2] http://cr.openjdk.java.net/~almatvee/8191709/webrev.00/ > > Thanks, > Alexander From amy.lu at oracle.com Wed Feb 27 01:41:06 2019 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 27 Feb 2019 09:41:06 +0800 Subject: [JDK 13] RFR 8219802: Problem list java/net/MulticastSocket/SetGetNetworkInterfaceTest.java Message-ID: <3b4093a8-766d-b611-30eb-f7478217d82a@oracle.com> java/net/MulticastSocket/SetGetNetworkInterfaceTest.java Test fails due to JDK-8219083 (failures observed on windows-x64) and should be problem listed before mentioned issue fixed. Please review the patch. bug: https://bugs.openjdk.java.net/browse/JDK-8219802 Thanks, Amy --- old/test/jdk/ProblemList.txt??? 2019-02-27 09:37:33.000000000 +0800 +++ new/test/jdk/ProblemList.txt??? 2019-02-27 09:37:32.000000000 +0800 @@ -556,6 +556,8 @@ ?java/net/MulticastSocket/Test.java 7145658 macosx-all +java/net/MulticastSocket/SetGetNetworkInterfaceTest.java 8219083 windows-all + ?java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all ?java/net/ServerSocket/AcceptInheritHandle.java 8211854 aix-ppc64 From alexander.matveev at oracle.com Wed Feb 27 02:31:24 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 26 Feb 2019 18:31:24 -0800 Subject: RFR: JDK-8217902: jpackage fails with --app-image option on mac In-Reply-To: <8540cf7b-ce07-e827-54c1-80f1cfa86959@oracle.com> References: <8540cf7b-ce07-e827-54c1-80f1cfa86959@oracle.com> Message-ID: <983d5587-72d7-c20d-b256-ded8de85c020@oracle.com> Hi Andy, http://cr.openjdk.java.net/~herrick/8217902/webrev.01/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinAppBundler.java.frames.html Line 135 - Did you mean to put error message in else statement before throwing exception? Otherwise looks fine. Thanks, Alexander On 2/26/2019 5:15 AM, Andy Herrick wrote: > ?JDK-8217902: jpackage fails with --app-image option on mac > > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > The fix is to remove the over-aggressive validation in > DeployParams.validate() and update WinAppBundler to be the same as Mac > code. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217902 > > [2] http://cr.openjdk.java.net/~herrick/8217902/webrev.01/ > > > /ANdy > From alexander.matveev at oracle.com Wed Feb 27 03:10:26 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 26 Feb 2019 19:10:26 -0800 Subject: RFR: JDK-8219144 : Cannot find installed application on Mac Message-ID: <60e37239-a955-6f69-54d1-951483198478@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). By default pkgbuild generates package with BundleIsRelocatable set to true, which means if an application already exist on system (installed, generated on given system or just copied from somewhere else), installer will not install into default location (/Application), but instead will update the existing version in place. This is why installed application was not found in default location, since it was already exist on system. Fixed by generating package with BundleIsRelocatable set to false. Note: We used --component option for pkgbuild and in this case pkgbuild was considered app as single component. With --root (required when using component property list), pkgbuild was considered Java runtime as child component of application. This is why child sub-component is removed from cpl. Java runtime is still part of app and will be installed. [1] https://bugs.openjdk.java.net/browse/JDK-8219144 [2] http://cr.openjdk.java.net/~almatvee/8219144/webrev.00/ Thanks, Alexander From amaembo at gmail.com Wed Feb 27 07:05:54 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 27 Feb 2019 14:05:54 +0700 Subject: Proposal to enhance Stream.collect In-Reply-To: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> References: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> Message-ID: Hello! > A less intrusive API direction might be a version of Collector whose > supplier function took a size-estimate argument; this might even help in > parallel since it allows for intermediate results to start with a better > initial size guess. (And this could be implemented as a default that > delegates to the existing supplier.) Still, not really sure this > carries its weight. It's interesting that such optimization is possible without API change, using the "hidden knowledge". While public API stays the same, the collect method implementation may check if custom non-public Collector implementation is supplied, and in this case may use the sized supplier. I think it's the best solution given the fact that very few collectors may benefit from the exact known size, and this benefit usually disappears when collectors are composed (e.g. using groupingBy: downstream toList() would not win anything if it provides a sizedSupplier). I created a quick patch and launched a quick benchmark like this: return new SplittableRandom(0).ints(length, 0, 100).boxed().collect(Collectors.toList()); For length = 100, 10000, 1000000 Here's results for vanilla 13-ea+8: length = 100, avg time = 1434,469 ? 27,147 ns/op, alloc rate = 1712 B/op length = 10000, avg time = 155032,390 ? 2657,927 ns/op, alloc rate = 169280 B/op length = 1000000, avg time = 27099621,763 ? 1979054,500 ns/op, alloc rate = 14586750 B/op Patched: length = 100, avg time = 1414,480 ? 30,040 ns/op, alloc rate = 768 B/op length = 10000, avg time = 137338,320 ? 1316,789 ns/op, alloc rate = 40368 B/op length = 1000000, avg time = 17654635,871 ? 210607,441 ns/op, alloc rate = 4000382 B/op As you can see, exact allocation really helps to reduce alloc pressure and produces better performance for big lists. If such kind of patch is acceptable for Stream API, I can file a ticket and submit a webrev. With best regards, Tagir Valeev The patch follows: --- src/java.base/share/classes/java/util/stream/Collectors.java (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) +++ src/java.base/share/classes/java/util/stream/Collectors.java (revision 53626+:e2fc434b410a+) @@ -50,6 +50,7 @@ import java.util.function.BinaryOperator; import java.util.function.Consumer; import java.util.function.Function; +import java.util.function.IntFunction; import java.util.function.Predicate; import java.util.function.Supplier; import java.util.function.ToDoubleFunction; @@ -194,23 +195,34 @@ */ static class CollectorImpl implements Collector { private final Supplier supplier; + private final IntFunction sizedSupplier; private final BiConsumer accumulator; private final BinaryOperator combiner; private final Function finisher; private final Set characteristics; CollectorImpl(Supplier supplier, + IntFunction sizedSupplier, BiConsumer accumulator, BinaryOperator combiner, Function finisher, Set characteristics) { this.supplier = supplier; + this.sizedSupplier = sizedSupplier; this.accumulator = accumulator; this.combiner = combiner; this.finisher = finisher; this.characteristics = characteristics; } + CollectorImpl(Supplier supplier, + BiConsumer accumulator, + BinaryOperator combiner, + Function finisher, + Set characteristics) { + this(supplier, null, accumulator, combiner, finisher, characteristics); + } + CollectorImpl(Supplier supplier, BiConsumer accumulator, BinaryOperator combiner, @@ -228,6 +240,10 @@ return supplier; } + IntFunction sizedSupplier() { + return sizedSupplier; + } + @Override public BinaryOperator combiner() { return combiner; @@ -275,8 +291,11 @@ */ public static Collector> toList() { - return new CollectorImpl<>((Supplier>) ArrayList::new, List::add, + return new CollectorImpl<>((Supplier>) ArrayList::new, + ArrayList::new, + List::add, (left, right) -> { left.addAll(right); return left; }, + castingIdentity(), CH_ID); } Index: src/java.base/share/classes/java/util/stream/ReduceOps.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/java/util/stream/ReduceOps.java (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) +++ src/java.base/share/classes/java/util/stream/ReduceOps.java (revision 53626+:e2fc434b410a+) @@ -36,6 +36,7 @@ import java.util.function.BinaryOperator; import java.util.function.DoubleBinaryOperator; import java.util.function.IntBinaryOperator; +import java.util.function.IntFunction; import java.util.function.LongBinaryOperator; import java.util.function.ObjDoubleConsumer; import java.util.function.ObjIntConsumer; @@ -155,13 +156,20 @@ public static TerminalOp makeRef(Collector collector) { Supplier supplier = Objects.requireNonNull(collector).supplier(); + @SuppressWarnings("unchecked") + IntFunction sizedSupplier = collector instanceof Collectors.CollectorImpl ? + ((Collectors.CollectorImpl) collector).sizedSupplier() : null; BiConsumer accumulator = collector.accumulator(); BinaryOperator combiner = collector.combiner(); class ReducingSink extends Box implements AccumulatingSink { @Override public void begin(long size) { - state = supplier.get(); + if (sizedSupplier != null && size >= 0 && size <= Integer.MAX_VALUE) { + state = sizedSupplier.apply((int) size); + } else { + state = supplier.get(); + } } @Override From christoph.langer at sap.com Wed Feb 27 09:31:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 27 Feb 2019 09:31:10 +0000 Subject: [JDK 13] RFR 8219802: Problem list java/net/MulticastSocket/SetGetNetworkInterfaceTest.java In-Reply-To: <3b4093a8-766d-b611-30eb-f7478217d82a@oracle.com> References: <3b4093a8-766d-b611-30eb-f7478217d82a@oracle.com> Message-ID: <3f287b512c6248bb8dbe6013ed08c3c1@sap.com> Hi Amy, seems reasonable to me. +1 Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Amy Lu > Sent: Mittwoch, 27. Februar 2019 02:41 > To: OpenJDK Dev list ; Core-Libs-Dev libs-dev at openjdk.java.net> > Subject: [JDK 13] RFR 8219802: Problem list > java/net/MulticastSocket/SetGetNetworkInterfaceTest.java > > java/net/MulticastSocket/SetGetNetworkInterfaceTest.java > > Test fails due to JDK-8219083 (failures observed on windows-x64) and > should be problem listed before mentioned issue fixed. > > Please review the patch. > > bug: https://bugs.openjdk.java.net/browse/JDK-8219802 > > Thanks, > Amy > > --- old/test/jdk/ProblemList.txt??? 2019-02-27 09:37:33.000000000 +0800 > +++ new/test/jdk/ProblemList.txt??? 2019-02-27 09:37:32.000000000 +0800 > @@ -556,6 +556,8 @@ > > ?java/net/MulticastSocket/Test.java 7145658 macosx-all > > +java/net/MulticastSocket/SetGetNetworkInterfaceTest.java 8219083 > windows-all > + > ?java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 > macosx-all > > ?java/net/ServerSocket/AcceptInheritHandle.java 8211854 aix-ppc64 From chris.hegarty at oracle.com Wed Feb 27 10:03:18 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 27 Feb 2019 10:03:18 +0000 Subject: [JDK 13] RFR 8219802: Problem list java/net/MulticastSocket/SetGetNetworkInterfaceTest.java In-Reply-To: <3f287b512c6248bb8dbe6013ed08c3c1@sap.com> References: <3b4093a8-766d-b611-30eb-f7478217d82a@oracle.com> <3f287b512c6248bb8dbe6013ed08c3c1@sap.com> Message-ID: +1 -Chris. On 27/02/2019 09:31, Langer, Christoph wrote: > Hi Amy, > > seems reasonable to me. +1 > > Best regards > Christoph > >> -----Original Message----- >> From: core-libs-dev On Behalf >> Of Amy Lu >> Sent: Mittwoch, 27. Februar 2019 02:41 >> To: OpenJDK Dev list ; Core-Libs-Dev > libs-dev at openjdk.java.net> >> Subject: [JDK 13] RFR 8219802: Problem list >> java/net/MulticastSocket/SetGetNetworkInterfaceTest.java >> >> java/net/MulticastSocket/SetGetNetworkInterfaceTest.java >> >> Test fails due to JDK-8219083 (failures observed on windows-x64) and >> should be problem listed before mentioned issue fixed. >> >> Please review the patch. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8219802 >> >> Thanks, >> Amy >> >> --- old/test/jdk/ProblemList.txt??? 2019-02-27 09:37:33.000000000 +0800 >> +++ new/test/jdk/ProblemList.txt??? 2019-02-27 09:37:32.000000000 +0800 >> @@ -556,6 +556,8 @@ >> >> ?java/net/MulticastSocket/Test.java 7145658 macosx-all >> >> +java/net/MulticastSocket/SetGetNetworkInterfaceTest.java 8219083 >> windows-all >> + >> ?java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 >> macosx-all >> >> ?java/net/ServerSocket/AcceptInheritHandle.java 8211854 aix-ppc64 > From dmitry.chuyko at bell-sw.com Wed Feb 27 10:17:08 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 27 Feb 2019 13:17:08 +0300 Subject: RFR(XS): 8215009: GCC 8 compilation eror in libjli In-Reply-To: <745bbfc7-1e82-c11e-a7a8-ba6ed50e6d21@oracle.com> References: <81207627-9063-8352-855e-97f458e66e8d@bell-sw.com> <0407f01a-f0e8-e1ad-6978-f311bd44a723@oracle.com> <951755ee-4f54-46ea-312b-ca014a6bef4a@bell-sw.com> <17bc8938-dfd7-f622-ad80-80c0273677e1@oracle.com> <6047BD3F-6B2A-4513-88AA-2DA79781A237@oracle.com> <2b7fc762-d0a6-3452-c57e-30a4447b5149@oracle.com> <2d4ee3bd-b3e0-21d6-7868-745d94e9b354@oracle.com> <3BFFC665-C15F-43B6-AB7D-49D7C3A97677@oracle.com> <7a519513-aa92-269b-f5bb-9bbe1bd1bfe7@oracle.com> <745bbfc7-1e82-c11e-a7a8-ba6ed50e6d21@oracle.com> Message-ID: Thanks for all the reviews. mach5-one-dchuyko-JDK-8215009-4-20190226-2029-850647: PASSED. Pushed. -Dmitry On 2/27/19 12:07 AM, David Holmes wrote: > Hi Dmitry, > > This seems fine to me too - much simpler. > > Thanks, > David > > On 27/02/2019 6:23 am, Dmitry Chuyko wrote: >> I made mentioned cleanups in changed code, just in case here is a >> webrev without functional changes: function renaming, comments, >> indents (just a couple), void*. >> >> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.04/ >> >> Started dev-submit for that patch. >> >> -Dmitry >> >> On 2/25/19 9:37 PM, Roger Riggs wrote: >>> +1 >>> >>> Much cleaner, since it does not need to be more general. >>> >>> I'd probably add a comment to the ThreadJavaMain method >>> to say why it is needed. >>> >>> BTW, it looks like the indents have gotten mixed up between 2 spaces >>> and 4. >>> For the libjli it should be 4 spaces. >>> But this change is probably not the place to fix it and it is >>> locally consistent. >>> >>> Thanks, Roger >>> >>> On 02/25/2019 01:16 PM, Mikael Vidstedt wrote: >>>> >>>>> On Feb 25, 2019, at 9:09 AM, Dmitry Chuyko >>>>> wrote: >>>>> >>>>> On 2/22/19 9:55 PM, Roger Riggs wrote: >>>>>> Hi, >>>>>> >>>>>> After a closer look, I'd take the route of the 01 webrev. >>>>>> It is more localized and does not force the function signature >>>>>> needed >>>>>> by pthread_create to be propagated elsewhere. >>>>>> >>>>>> The code can be a lot more comprehensible by renaming the >>>>>> CallIntFunc >>>>>> function to be specific to ContinueInNewThread0. It looks like a >>>>>> trampoline to me. >>>>>> The data structure being passed is on the stack of the caller of >>>>>> pthread_create. >>>>>> It seems safe to refer to it here because the caller will wait in >>>>>> pthread_join. >>>>> After some hesitation it looks like ContinueInNewThread0 may know >>>>> about JavaMain just like ContinueInNewThread, no need to work with >>>>> abstract continuation. Even that abstract continuation is limited >>>>> to int return type. In webrev.02 continuation gets platform >>>>> specific signature. But then we have to cast the result where the >>>>> call is direct. Another approach in that direction could be to add >>>>> result field in JavaMainArgs, but it will again force >>>>> ContinueInNewThread0 to know about continuation's parameters >>>>> structure as there may be a direct call of continuation. >>>>> >>>>> If we let ContinueInNewThread0 call only JavaMain, it all can work >>>>> without extra trampoline structures (just need a wrapper): >>>>> >>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.03/ >>>>> >>>> I like it! Since ContinueInNewThread0 is now always calling >>>> JavaMain I guess it could be renamed to CallJavaMainInNewThread (or >>>> something to that same effect). >>> I'm fine with the rename (no additional review necessary). >>> >>>> >>>> Minor nit: some consistency in where the ?*? is placed in the >>>> various ?void *? places would be nice. >>>> >>>> Cheers, >>>> Mikael >>>> >>>>> -Dmitry >>>>> >>>>>> Also important is to document that the return type is specific to >>>>>> the OS >>>>>> and is needed to cast the return value expected by the >>>>>> start_pthread_create >>>>>> start_routine.? That may still be in question because pthread_create >>>>>> expects void*. >>>>>> >>>>>> $.02, Roger >>>>>> >>>>>> >>>>>> On 02/22/2019 10:32 AM, Roger Riggs wrote: >>>>>>> Hi, >>>>>>> >>>>>>> If the warning can be addressed with an extra in-line cast then >>>>>>> that's >>>>>>> cleaner and easier to understand than replicating that structure >>>>>>> in 3 files. >>>>>>> And of course, add a comment. >>>>>>> To make the source more readable, the cast could be factored >>>>>>> into a macro in the same file with the comment about why it is >>>>>>> needed. >>>>>>> >>>>>>> Roger >>>>>>> >>>>>>> >>>>>>> On 02/21/2019 11:07 PM, David Holmes wrote: >>>>>>>> On 22/02/2019 4:55 am, Mikael Vidstedt wrote: >>>>>>>>> The wrapper based solution looks much cleaner to me as well. >>>>>>>>> webrev.01 looks good. >>>>>>>> Sorry I really don't like it. The wrappers obfuscate and make >>>>>>>> complicated something that is not at all complicated. I have to >>>>>>>> re-read the new code 3 times to figure out what it is even doing! >>>>>>>> >>>>>>>> All that complexity to handle the fact one platform wants to >>>>>>>> return int instead of void* ?? >>>>>> The complexity is due to the function being called in some other >>>>>> thread >>>>>> context and there is a necessary cast/type conversion on the >>>>>> return value >>>>>> from the start_routine that has to come back through pthread to >>>>>> pthread_join. >>>>>> >>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> (not a Reviewer) >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Mikael >>>>>>>>> >>>>>>>>>> On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> To me thread function wrappers look preferable to platform >>>>>>>>>> specific JavaMain signature. Consider this webrev with wrappers: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ >>>>>>>>>> >>>>>>>>>> In some cases JavaMain is called in the same thread and its >>>>>>>>>> result is returned from JLI_Launch. ContinueInNewThread is in >>>>>>>>>> shared code. And JavaMain uses macro controlled returns. >>>>>>>>>> So when JavaMain returns THREAD_FUNC_RETURN changes may >>>>>>>>>> contain some quite artificial macro parts in java.c: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.02/ >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 12/19/18 9:27 AM, David Holmes wrote: >>>>>>>>>>> On 19/12/2018 1:56 am, Dmitry Chuyko wrote: >>>>>>>>>>>> On 12/18/18 3:39 AM, David Holmes wrote: >>>>>>>>>>>>> On 11/12/2018 9:30 pm, Dmitry Chuyko wrote: >>>>>>>>>>>>>> On 12/11/18 4:03 AM, David Holmes wrote: >>>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/12/2018 12:16 am, Dmitry Chuyko wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review a small fix in java_md_solinux.c: >>>>>>>>>>>>>>>> continuation is not truly compatible with >>>>>>>>>>>>>>>> pthread_create start_routine's signature but we control >>>>>>>>>>>>>>>> what actually happens. So it makes sense to add >>>>>>>>>>>>>>>> intermediate void* cast to silence the error. >>>>>>>>>>>>>>> I'd be tempted to fix the signature and get rid of all >>>>>>>>>>>>>>> the casts. >>>>>>>>>>>>>> David, the signature is a signature of >>>>>>>>>>>>>> >>>>>>>>>>>>>> int JNICALL JavaMain(void * _args) >>>>>>>>>>>>>> >>>>>>>>>>>>>> It would be fun to change it. But still on Windows it is >>>>>>>>>>>>>> correctly passed to _beginthreadex() and then return code >>>>>>>>>>>>>> is extracted with GetExitCodeThread(). In case we want it >>>>>>>>>>>>>> to return void* the cast will move there. >>>>>>>>>>>>> I think the current double cast is truly ugly and an ifdef >>>>>>>>>>>>> for windows, or a cast for Windows only would be an >>>>>>>>>>>>> improvement. >>>>>>>>>>>> I agree. Maybe making a wrapper function is not so ugly. If >>>>>>>>>>>> there are no objections to changing beginning of the call >>>>>>>>>>>> stack it is quite easy to implement. For consistency it may >>>>>>>>>>>> be done for all 3 points (posix unix, posix mac, windows) >>>>>>>>>>>> or just for posix ones. >>>>>>>>>>>> >>>>>>>>>>>> It looks like ifdef should be better as long as there are >>>>>>>>>>>> already OS-specific parts in libjli. Again, if there are no >>>>>>>>>>>> objections to have different JavaMain signatures on >>>>>>>>>>>> different platforms. In this case there won't be a >>>>>>>>>>>> signature cast for Windows. >>>>>>>>>>> How about setting >>>>>>>>>>> >>>>>>>>>>> #define THREAD_FUNC_RETURN int >>>>>>>>>>> >>>>>>>>>>> in windows/java_md.h. >>>>>>>>>>> >>>>>>>>>>> Then: >>>>>>>>>>> >>>>>>>>>>> #ifndef THREAD_FUNC_RETURN >>>>>>>>>>> ??? #define THREAD_FUNC_RETURN void* >>>>>>>>>>> #endif >>>>>>>>>>> >>>>>>>>>>> in java.h (after the other includes). >>>>>>>>>>> >>>>>>>>>>> Then: >>>>>>>>>>> >>>>>>>>>>> THREAD_FUNC_RETURN JNICALL >>>>>>>>>>> JavaMain(void * _args) >>>>>>>>>>> >>>>>>>>>>> in java.c. >>>>>>>>>>> >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>>> But I won't impose that on you just to silence gcc 8. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215009 >>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dchuyko/8215009/webrev.00/ >>>>>>>>>>>>>>>> testing: submit repo >>>>>>>>>>>>>>>> (mach5-one-dchuyko-JDK-8215009-20181207-1625-13615: >>>>>>>>>>>>>>>> PASSED) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>>>> >>> From andrew_m_leonard at uk.ibm.com Wed Feb 27 10:18:21 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 27 Feb 2019 10:18:21 +0000 Subject: LTS releases and JEP 182: Policy for Retiring javac -source and -target Options ? Message-ID: Hi, Does anyone know if this JEP will be modified to cater for the shorter release cycles and LTS releases? https://bugs.openjdk.java.net/browse/JDK-8046172 The original Impact statement stated: "but even with this new policy source code 10 or more years old should still be able to be compiled" however now, for example with JDK12 this policy will only support 1+3 = 12, 11, 10, 9, which means LTS JDK8 would not be recognised? "1+3" is essentially only 18 months now! Thoughts? or is there a new JEP I have missed that covers this? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 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 andrew_m_leonard at uk.ibm.com Wed Feb 27 10:23:25 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 27 Feb 2019 10:23:25 +0000 Subject: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized In-Reply-To: <85abfac7-5908-34c9-448e-fe425e7124f8@oracle.com> References: <01be6f5f-7836-98d4-378f-cf08f3e10781@oracle.com> <41ced57e-2026-6dee-1cbb-74b7be192ff2@oracle.com> <6e013cc4-d1da-0be2-e06f-9441a05014b9@oracle.com> <04c24776-3b1b-c31e-5532-f82aee02ae8c@oracle.com> <85abfac7-5908-34c9-448e-fe425e7124f8@oracle.com> Message-ID: Thanks for merging Roger Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Roger Riggs To: Andrew Leonard , Mandy Chung Cc: core-libs-dev at openjdk.java.net Date: 26/02/2019 17:00 Subject: Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized Hi Andrew, I've got the changeset you sent earlier and have tested it as well. I'll push it today unless there any objections. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reflectionfactory-8219378-2/ Roger On 02/26/2019 11:46 AM, Andrew Leonard wrote: Hi Mandy, I think your last proposal sounds a good plan, push 8219378 to fix the immediate issue and create a new change to refactor the clinit location... As I am not a "Committer" (yet! working on it!) I can't use the Submit repo. I have built your patch and run a bunch of tests locally and it works great. I have also tested it successfully with J9. So I am happy with your change. If Roger & yourself are happy with 8219378, can we Submit-repo it for final test and get that one merged? Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Mandy Chung To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net, Roger Riggs Date: 26/02/2019 00:16 Subject: Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized On 2/25/19 5:12 AM, Andrew Leonard wrote: > Hi Mandy, > I must admit I don't completely follow the logic of the existing > Modifier init of langReflectAccess, the comment indicates a "protocol > between java.lang and java.lang.reflect". That sets up the shared secret for ReflectionFactory to access non-public members in java.lang.reflect. > I can try moving the clinit > code from Modifier to AccessibleObject, but I question is there some > reason it is there? Would we be sure in moving it we are not missing > something? ReflectionFactory is the internal support for reflection. The methods that access LangReflectAccess shared secrets should have a Method, Field or Constructor in hand. The ReflectionFactory::newField and newMethod that don't take Field/Method parameter are unused (I suspect they were used by the VM native reflection implementation previously. That led me to suggest to move setLangReflectAccess to AccessibleObject. AccessibleObject is initialized very early during startup by the VM. My proposed fix would change the list of classes loaded during early startup but it would need to look at closely. Having a second thought, my proposed fix can be a follow-on clean up. I'm okay with your point fix that resolves JDK-8219378. I will file a JBS issue for the follow-on clean up. What do you think? thanks Mandy 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 Alan.Bateman at oracle.com Wed Feb 27 10:48:07 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Feb 2019 10:48:07 +0000 Subject: LTS releases and JEP 182: Policy for Retiring javac -source and -target Options ? In-Reply-To: References: Message-ID: On 27/02/2019 10:18, Andrew Leonard wrote: > Hi, > Does anyone know if this JEP will be modified to cater for the shorter > release cycles and LTS releases? > https://bugs.openjdk.java.net/browse/JDK-8046172 > The original Impact statement stated: "but even with this new policy > source code 10 or more years old should still be able to be compiled" > however now, for example with JDK12 this policy will only support 1+3 = > 12, 11, 10, 9, which means LTS JDK8 would not be recognised? > "1+3" is essentially only 18 months now! > JDK 12 dropped support for compiling to --release 6, see JDK-8028563 [1]. You shouldn't have any issue compiling to --release 8. The policy documented in JEP 182 pre-dates the more rapid cadence, the policy hasn't been updated yet. The topic has come up on jdk-dev, discuss, and other places. Joe Darcy's recent mail to jdk-dev [2] might be useful. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8028563 [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002628.html From amy.lu at oracle.com Wed Feb 27 11:08:25 2019 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 27 Feb 2019 19:08:25 +0800 Subject: [JDK 13] RFR 8219802: Problem list java/net/MulticastSocket/SetGetNetworkInterfaceTest.java In-Reply-To: References: <3b4093a8-766d-b611-30eb-f7478217d82a@oracle.com> <3f287b512c6248bb8dbe6013ed08c3c1@sap.com> Message-ID: <3c94558b-3591-d0ad-08e2-818b3dde366d@oracle.com> Thank you Christoph and Chris! Change pushed. Thanks, Amy On 2/27/19 6:03 PM, Chris Hegarty wrote: > +1 > > -Chris. > > On 27/02/2019 09:31, Langer, Christoph wrote: >> Hi Amy, >> >> seems reasonable to me. +1 >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: core-libs-dev On Behalf >>> Of Amy Lu >>> Sent: Mittwoch, 27. Februar 2019 02:41 >>> To: OpenJDK Dev list ; Core-Libs-Dev >> libs-dev at openjdk.java.net> >>> Subject: [JDK 13] RFR 8219802: Problem list >>> java/net/MulticastSocket/SetGetNetworkInterfaceTest.java >>> >>> java/net/MulticastSocket/SetGetNetworkInterfaceTest.java >>> >>> Test fails due to JDK-8219083 (failures observed on windows-x64) and >>> should be problem listed before mentioned issue fixed. >>> >>> Please review the patch. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8219802 >>> >>> Thanks, >>> Amy >>> >>> --- old/test/jdk/ProblemList.txt??? 2019-02-27 09:37:33.000000000 +0800 >>> +++ new/test/jdk/ProblemList.txt??? 2019-02-27 09:37:32.000000000 +0800 >>> @@ -556,6 +556,8 @@ >>> >>> ? ?java/net/MulticastSocket/Test.java 7145658 macosx-all >>> >>> +java/net/MulticastSocket/SetGetNetworkInterfaceTest.java 8219083 >>> windows-all >>> + >>> ? ?java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 >>> macosx-all >>> >>> ? ?java/net/ServerSocket/AcceptInheritHandle.java 8211854 aix-ppc64 >> From andy.herrick at oracle.com Wed Feb 27 13:47:50 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 27 Feb 2019 08:47:50 -0500 Subject: RFR: JDK-8219144 : Cannot find installed application on Mac In-Reply-To: <60e37239-a955-6f69-54d1-951483198478@oracle.com> References: <60e37239-a955-6f69-54d1-951483198478@oracle.com> Message-ID: <7bfdc143-adb8-322f-b22f-9ec714a27dc7@oracle.com> this looks good - at least for now. I would like to eventually override the generated cpl.plist with a user defined resource file. /Andy On 2/26/2019 10:10 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > By default pkgbuild generates package with BundleIsRelocatable set to > true, which means if an application already exist on system > (installed, generated on given system or just copied from somewhere > else), installer will not install into default location > (/Application), but instead will update the existing version in place. > This is why installed application was not found in default location, > since it was already exist on system. Fixed by generating package with > BundleIsRelocatable set to false. Note: We used --component option for > pkgbuild and in this case pkgbuild was considered app as single > component. With --root (required when using component property list), > pkgbuild was considered Java runtime as child component of > application. This is why child sub-component is removed from cpl. Java > runtime is still part of app and will be installed. > > [1] https://bugs.openjdk.java.net/browse/JDK-8219144 > > [2] http://cr.openjdk.java.net/~almatvee/8219144/webrev.00/ > > Thanks, > Alexander From joe.darcy at oracle.com Wed Feb 27 20:11:05 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 27 Feb 2019 12:11:05 -0800 Subject: JDK 13 RFR of JDK-8218726: Minor Throwable.printStackTrace() typos Message-ID: <7f0ae8cb-d88c-8c7f-cec6-b06ce799434a@oracle.com> Hello, Please review the patch below to fix a small typo ("at" -> "as") in text of Throwable introduced with some of the Project Coin changes. Thanks, -Joe diff -r 2c50e900e8af src/java.base/share/classes/java/lang/Throwable.java --- a/src/java.base/share/classes/java/lang/Throwable.java??? Wed Feb 27 11:33:57 2019 -0800 +++ b/src/java.base/share/classes/java/lang/Throwable.java??? Wed Feb 27 12:09:29 2019 -0800 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 1994, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -616,7 +616,7 @@ ????? *????????? ... 1 more ????? * ????? * Note that the "... n more" notation is used on suppressed exceptions -???? * just at it is used on causes. Unlike causes, suppressed exceptions are +???? * just as it is used on causes. Unlike causes, suppressed exceptions are ????? * indented beyond their "containing exceptions." ????? * ????? *

              An exception can have both a cause and one or more suppressed From brian.burkhalter at oracle.com Wed Feb 27 20:16:47 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 27 Feb 2019 12:16:47 -0800 Subject: JDK 13 RFR of JDK-8218726: Minor Throwable.printStackTrace() typos In-Reply-To: <7f0ae8cb-d88c-8c7f-cec6-b06ce799434a@oracle.com> References: <7f0ae8cb-d88c-8c7f-cec6-b06ce799434a@oracle.com> Message-ID: Hi Joe, +1 Brian > On Feb 27, 2019, at 12:11 PM, Joe Darcy wrote: > > Please review the patch below to fix a small typo ("at" -> "as") in text of Throwable introduced with some of the Project Coin changes. From mandy.chung at oracle.com Wed Feb 27 21:07:40 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 Feb 2019 13:07:40 -0800 Subject: JDK 13 RFR of JDK-8218726: Minor Throwable.printStackTrace() typos In-Reply-To: <7f0ae8cb-d88c-8c7f-cec6-b06ce799434a@oracle.com> References: <7f0ae8cb-d88c-8c7f-cec6-b06ce799434a@oracle.com> Message-ID: +1 Mandy On 2/27/19 12:11 PM, Joe Darcy wrote: > Hello, > > Please review the patch below to fix a small typo ("at" -> "as") in text > of Throwable introduced with some of the Project Coin changes. > > Thanks, > > -Joe > > diff -r 2c50e900e8af src/java.base/share/classes/java/lang/Throwable.java > --- a/src/java.base/share/classes/java/lang/Throwable.java??? Wed Feb 27 > 11:33:57 2019 -0800 > +++ b/src/java.base/share/classes/java/lang/Throwable.java??? Wed Feb 27 > 12:09:29 2019 -0800 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 1994, 2016, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -616,7 +616,7 @@ > ????? *????????? ... 1 more > ????? * > ????? * Note that the "... n more" notation is used on suppressed > exceptions > -???? * just at it is used on causes. Unlike causes, suppressed > exceptions are > +???? * just as it is used on causes. Unlike causes, suppressed > exceptions are > ????? * indented beyond their "containing exceptions." > ????? * > ????? *

              An exception can have both a cause and one or more suppressed > From ecki at zusammenkunft.net Wed Feb 27 21:23:36 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 27 Feb 2019 21:23:36 +0000 Subject: LTS releases and JEP 182: Policy for Retiring javac -source and -target Options ? In-Reply-To: References: , Message-ID: I had the same doubts about the @deprecation N+1 Policy. In both cases a ?must be deprecated in at least a LTS version? would be more conservative (but understandable very expensive) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Alan Bateman Gesendet: Mittwoch, Februar 27, 2019 2:18 PM An: Andrew Leonard; core-libs-dev at openjdk.java.net Betreff: Re: LTS releases and JEP 182: Policy for Retiring javac -source and -target Options ? On 27/02/2019 10:18, Andrew Leonard wrote: > Hi, > Does anyone know if this JEP will be modified to cater for the shorter > release cycles and LTS releases? > https://bugs.openjdk.java.net/browse/JDK-8046172 > The original Impact statement stated: "but even with this new policy > source code 10 or more years old should still be able to be compiled" > however now, for example with JDK12 this policy will only support 1+3 = > 12, 11, 10, 9, which means LTS JDK8 would not be recognised? > "1+3" is essentially only 18 months now! > JDK 12 dropped support for compiling to --release 6, see JDK-8028563 [1]. You shouldn't have any issue compiling to --release 8. The policy documented in JEP 182 pre-dates the more rapid cadence, the policy hasn't been updated yet. The topic has come up on jdk-dev, discuss, and other places. Joe Darcy's recent mail to jdk-dev [2] might be useful. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8028563 [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002628.html From chris.w.dennis at gmail.com Wed Feb 27 22:11:17 2019 From: chris.w.dennis at gmail.com (Chris Dennis) Date: Wed, 27 Feb 2019 17:11:17 -0500 Subject: RFR: jsr166 integration 2019-02 In-Reply-To: <056e1b45-0440-448b-aa6b-3e2225cdbc27@oracle.com> References: <056e1b45-0440-448b-aa6b-3e2225cdbc27@oracle.com> Message-ID: Hi All, Apologies for dredging up an older mail thread. I lurk and follow along with various JDK development threads and this 166 integration change jumped out at me. I have to confess although I understood the intent of the change and the explanation in the comments, like David I found it very difficult to navigate the actual changeset itself. I was hoping that there would be continued discussion that I could follow along with and that this would help me too. I was surprised therefore when I didn?t see any further discussion, and then noticed that the change had actually been committed (http://hg.openjdk.java.net/jdk/jdk/rev/d04f72c354e9 ). Was there some further discussion on another list/thread that I missed that someone could direct me to? Thanks, Chris > On Feb 10, 2019, at 10:41 PM, David Holmes wrote: > >> >> 8215363: needless signals in ForkJoinPool >> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/forkjoin-signals/index.html >> https://bugs.openjdk.java.net/browse/JDK-8215363 > > Can't comment - the code is unfathomable. From joe.darcy at oracle.com Wed Feb 27 22:32:19 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 27 Feb 2019 14:32:19 -0800 Subject: RFR: jsr166 integration 2019-02 In-Reply-To: References: <056e1b45-0440-448b-aa6b-3e2225cdbc27@oracle.com> <03a50a16-e99f-fd70-c32d-6465af198487@oracle.com> Message-ID: <5C770FF3.6030708@oracle.com> On 2/10/2019 8:27 PM, Martin Buchholz wrote: > On Sun, Feb 10, 2019 at 8:24 PM David Holmes > wrote: > >> On 11/02/2019 2:20 pm, Martin Buchholz wrote: >>> On Sun, Feb 10, 2019 at 7:41 PM David Holmes >> > wrote: >>> >>> >>> > Still in limbo: >>> > 8203662: remove increment of modCount from ArrayList and Vector >>> replaceAll() >>> > >>> >> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html >>> > https://bugs.openjdk.java.net/browse/JDK-8203662 >>> >>> If still in limbo why is this here? >>> >>> >>> It remains in jsr166 CVS. >> Okay but what does that mean for this integration request? I assume you >> are not actually going to push this change? >> >> > It's a vague reminder that someday we need to resolve it one way or the > other. Reminder acknowledged; sorry for the delay. -Joe From ecki at zusammenkunft.net Wed Feb 27 23:26:35 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 28 Feb 2019 00:26:35 +0100 Subject: "java.lang.Error: Probable fatal error:No fonts found" does not show on 11 In-Reply-To: References: Message-ID: <5c771cab.1c69fb81.bd016.d65b@mx.google.com> Hello, (please let me know in case I picked the wrong list.) Since OpenJDK does not ship Default *.ttf font files the change that a JRE is installed in a way that no System Fonts can be found is quite high. In OpenJDK8 it is a bit unfortunate that in this situation even for the headless graphics context that you can can a Java.lang.Error: I wonder if this is intentional. How About returnign an empty Array or Maybe a RntimeException instead? In my case by upgrading from Oracle JRE to Open JDK (in my case Azul) a perfectly fine working Installation is not aborting. The JasperReports component used is failing does not even need the System Fonts (which I will report to them seperately). For Zulu it is enough to install Dejavu Fonts in System Directory or copy them to JRE/lib/fonts/, but I have also seen OpenJDK builds which seem to use fontmanager libraries instead of fixed file path. Here I guess the dependency on System config is even higher. I tested on a minimal System with no X11: > ls /usr/share/fonts > cat /etc/centos-release CentOS Linux release 7.3.1611 (Core) And my test program (below) Returns for Java 8: > zulu8*x64/bin/java -cp . FontTest Are we headless? true g = sun.java2d.HeadlessGraphicsEnvironment headless: true Exception in thread "main" java.lang.Error: Probable fatal error:No fonts found. at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1236) at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) ? at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1220) at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) at sun.font.SunFontManager.initialiseDeferredFonts(SunFontManager.java:927) at sun.font.SunFontManager.loadFonts(SunFontManager.java:3302) at sun.awt.X11FontManager.loadFonts(X11FontManager.java:466) at sun.font.SunFontManager.loadFontFiles(SunFontManager.java:3429) at sun.font.SunFontManager.getInstalledFontFamilyNames(SunFontManager.java:3766) at sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:225) at sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:252) at sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:94) at FontTest.main(FontTest.java:15) So the error in itself is one topic I wanted to inquire About. However, even worse in OpenJDK 11 the error seems to have degenerated quite a bit, it Looks for me: > zulu11*x64/bin/java -cp . FontTest Are we headless? true g = sun.java2d.HeadlessGraphicsEnvironment headless: true Exception in thread "main" java.lang.InternalError: java.lang.reflect.InvocationTargetException at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189) at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223) at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251) at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75) at FontTest.main(FontTest.java:15) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:84) ... 7 more Caused by: java.lang.NullPointerException at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1262) at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225) at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107) at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:719) at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:367) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.desktop/sun.font.SunFontManager.(SunFontManager.java:312) at java.desktop/sun.awt.FcFontManager.(FcFontManager.java:35) at java.desktop/sun.awt.X11FontManager.(X11FontManager.java:56) ... 12 mor If there is no known issue for that, is it worth to file a Bug for it? (I Need to recreate it with a Oracle OpenJDK binary yet if it is only a fontconfig Problem ? but in that case a null check is probably also a good thing?) Gruss Bernd From martinrb at google.com Wed Feb 27 23:35:29 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Feb 2019 15:35:29 -0800 Subject: RFR: jsr166 integration 2019-02 In-Reply-To: References: <056e1b45-0440-448b-aa6b-3e2225cdbc27@oracle.com> Message-ID: jsr166 is sort-of an upstream project of openjdk and has its own mailing list. It looks like forkjoin changes were discussed here: https://markmail.org/thread/ezvo7xf3xh6q2u2c (and yeah, everyone has trouble understanding forkjoin implementation) On Wed, Feb 27, 2019 at 2:10 PM Chris Dennis wrote: > Hi All, > > Apologies for dredging up an older mail thread. I lurk and follow along > with various JDK development threads and this 166 integration change jumped > out at me. I have to confess although I understood the intent of the change > and the explanation in the comments, like David I found it very difficult > to navigate the actual changeset itself. I was hoping that there would be > continued discussion that I could follow along with and that this would > help me too. I was surprised therefore when I didn?t see any further > discussion, and then noticed that the change had actually been committed ( > http://hg.openjdk.java.net/jdk/jdk/rev/d04f72c354e9). Was there some > further discussion on another list/thread that I missed that someone could > direct me to? > > Thanks, > > Chris > > On Feb 10, 2019, at 10:41 PM, David Holmes > wrote: > > > 8215363: needless signals in ForkJoinPool > > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/forkjoin-signals/index.html > https://bugs.openjdk.java.net/browse/JDK-8215363 > > > Can't comment - the code is unfathomable. > > > From philip.race at oracle.com Wed Feb 27 23:45:43 2019 From: philip.race at oracle.com (Philip Race) Date: Wed, 27 Feb 2019 15:45:43 -0800 Subject: "java.lang.Error: Probable fatal error:No fonts found" does not show on 11 In-Reply-To: <5c771cab.1c69fb81.bd016.d65b@mx.google.com> References: <5c771cab.1c69fb81.bd016.d65b@mx.google.com> Message-ID: <5C772127.9090706@oracle.com> Wrong list. You want 2d-dev. -phil. On 2/27/19, 3:26 PM, Bernd Eckenfels wrote: > Hello, > > (please let me know in case I picked the wrong list.) > > Since OpenJDK does not ship Default *.ttf font files the change that a JRE is installed in a way that no System Fonts can be found is quite high. > > In OpenJDK8 it is a bit unfortunate that in this situation even for the headless graphics context that you can can a Java.lang.Error: > > I wonder if this is intentional. How About returnign an empty Array or Maybe a RntimeException instead? In my case by upgrading from Oracle JRE to Open JDK (in my case Azul) a perfectly fine working Installation is not aborting. > > The JasperReports component used is failing does not even need the System Fonts (which I will report to them seperately). For Zulu it is enough to install Dejavu Fonts in System Directory or copy them to JRE/lib/fonts/, but I have also seen OpenJDK builds which seem to use fontmanager libraries instead of fixed file path. Here I guess the dependency on System config is even higher. > > I tested on a minimal System with no X11: > >> ls /usr/share/fonts >> cat /etc/centos-release > CentOS Linux release 7.3.1611 (Core) > > And my test program (below) Returns for Java 8: > >> zulu8*x64/bin/java -cp . FontTest > Are we headless? true > g = sun.java2d.HeadlessGraphicsEnvironment headless: true > Exception in thread "main" java.lang.Error: Probable fatal error:No fonts found. > at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1236) > at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) > ? > at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1220) > at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) > at sun.font.SunFontManager.initialiseDeferredFonts(SunFontManager.java:927) > at sun.font.SunFontManager.loadFonts(SunFontManager.java:3302) > at sun.awt.X11FontManager.loadFonts(X11FontManager.java:466) > at sun.font.SunFontManager.loadFontFiles(SunFontManager.java:3429) > at sun.font.SunFontManager.getInstalledFontFamilyNames(SunFontManager.java:3766) > at sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:225) > at sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:252) > at sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:94) > at FontTest.main(FontTest.java:15) > > So the error in itself is one topic I wanted to inquire About. However, even worse in OpenJDK 11 the error seems to have degenerated quite a bit, it Looks for me: > >> zulu11*x64/bin/java -cp . FontTest > Are we headless? true > g = sun.java2d.HeadlessGraphicsEnvironment headless: true > Exception in thread "main" java.lang.InternalError: java.lang.reflect.InvocationTargetException > at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) > at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189) > at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223) > at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251) > at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75) > at FontTest.main(FontTest.java:15) > Caused by: java.lang.reflect.InvocationTargetException > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:84) > ... 7 more > Caused by: java.lang.NullPointerException > at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1262) > at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225) > at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107) > at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:719) > at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:367) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.desktop/sun.font.SunFontManager.(SunFontManager.java:312) > at java.desktop/sun.awt.FcFontManager.(FcFontManager.java:35) > at java.desktop/sun.awt.X11FontManager.(X11FontManager.java:56) > ... 12 mor > > If there is no known issue for that, is it worth to file a Bug for it? (I Need to recreate it with a Oracle OpenJDK binary yet if it is only a fontconfig Problem ? but in that case a null check is probably also a good thing?) > > Gruss > Bernd From alexander.matveev at oracle.com Thu Feb 28 00:24:24 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 27 Feb 2019 16:24:24 -0800 Subject: RFR: JDK-8191709 : javapackager detects WiX 3.10 as 3.1 and fails to use WiX 3.6+ compatible code In-Reply-To: References: <47d999e3-9fda-15f1-0188-6965be154473@oracle.com> Message-ID: <52db4e1e-3ead-3e81-f2d5-8d197649eb98@oracle.com> Hi Kevin, You right, comparison was not right. I fixed it. http://cr.openjdk.java.net/~almatvee/8191709/webrev.01/ Thanks, Alexander On 2/26/2019 4:17 PM, Kevin Rushforth wrote: > The comparison isn't quite right. It will fail if either the major or > minor is less than the minimum. This means, for example, that 4.1 will > be considered less than 3.6. > > -- Kevin > > > On 2/26/2019 3:25 PM, Alexander Matveev wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> - Problem was in how we compare versions. We used to compare it as >> float number, so 3.10 -> 3.1 which was less then 3.6. >> - Fixed by comparing major and minor version separately. >> - Fixed minor spelling error in resources. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8191709 >> >> [2] http://cr.openjdk.java.net/~almatvee/8191709/webrev.00/ >> >> Thanks, >> Alexander > From andy.herrick at oracle.com Thu Feb 28 00:34:41 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 27 Feb 2019 19:34:41 -0500 Subject: RFR: JDK-8191709 : javapackager detects WiX 3.10 as 3.1 and fails to use WiX 3.6+ compatible code In-Reply-To: <52db4e1e-3ead-3e81-f2d5-8d197649eb98@oracle.com> References: <47d999e3-9fda-15f1-0188-6965be154473@oracle.com> <52db4e1e-3ead-3e81-f2d5-8d197649eb98@oracle.com> Message-ID: <2ab05b3e-459c-7d89-abb6-d73e3fc19bd8@oracle.com> looks good now. /Andy On 2/27/2019 7:24 PM, Alexander Matveev wrote: > Hi Kevin, > > You right, comparison was not right. I fixed it. > http://cr.openjdk.java.net/~almatvee/8191709/webrev.01/ > > Thanks, > Alexander > > > On 2/26/2019 4:17 PM, Kevin Rushforth wrote: >> The comparison isn't quite right. It will fail if either the major or >> minor is less than the minimum. This means, for example, that 4.1 >> will be considered less than 3.6. >> >> -- Kevin >> >> >> On 2/26/2019 3:25 PM, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - Problem was in how we compare versions. We used to compare it as >>> float number, so 3.10 -> 3.1 which was less then 3.6. >>> - Fixed by comparing major and minor version separately. >>> - Fixed minor spelling error in resources. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8191709 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8191709/webrev.00/ >>> >>> Thanks, >>> Alexander >> > From kevin.rushforth at oracle.com Thu Feb 28 00:36:43 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 27 Feb 2019 16:36:43 -0800 Subject: RFR: JDK-8191709 : javapackager detects WiX 3.10 as 3.1 and fails to use WiX 3.6+ compatible code In-Reply-To: <52db4e1e-3ead-3e81-f2d5-8d197649eb98@oracle.com> References: <47d999e3-9fda-15f1-0188-6965be154473@oracle.com> <52db4e1e-3ead-3e81-f2d5-8d197649eb98@oracle.com> Message-ID: That looks better. Btw, the copyright header should only have a single "2019" (we don't repeat the year for a file created and last modified in the same year). You can fix this when you push. Thanks. -- Kevin On 2/27/2019 4:24 PM, Alexander Matveev wrote: > Hi Kevin, > > You right, comparison was not right. I fixed it. > http://cr.openjdk.java.net/~almatvee/8191709/webrev.01/ > > Thanks, > Alexander > > > On 2/26/2019 4:17 PM, Kevin Rushforth wrote: >> The comparison isn't quite right. It will fail if either the major or >> minor is less than the minimum. This means, for example, that 4.1 >> will be considered less than 3.6. >> >> -- Kevin >> >> >> On 2/26/2019 3:25 PM, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - Problem was in how we compare versions. We used to compare it as >>> float number, so 3.10 -> 3.1 which was less then 3.6. >>> - Fixed by comparing major and minor version separately. >>> - Fixed minor spelling error in resources. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8191709 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8191709/webrev.00/ >>> >>> Thanks, >>> Alexander >> > From andy.herrick at oracle.com Thu Feb 28 00:41:10 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 27 Feb 2019 19:41:10 -0500 Subject: RFR: JDK-8217902: jpackage fails with --app-image option on mac In-Reply-To: <8540cf7b-ce07-e827-54c1-80f1cfa86959@oracle.com> References: <8540cf7b-ce07-e827-54c1-80f1cfa86959@oracle.com> Message-ID: <16396d65-146c-0f99-fd42-a4e8428ce353@oracle.com> revised webrev at http://cr.openjdk.java.net/~herrick/8217902/webrev.02/ Do not Log a verbose message when cfg not found in getAppName() - just use APP_NAME parameter as is done on Linux and Mac /Andy On 2/26/2019 8:15 AM, Andy Herrick wrote: > ?JDK-8217902: jpackage fails with --app-image option on mac > > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > The fix is to remove the over-aggressive validation in > DeployParams.validate() and update WinAppBundler to be the same as Mac > code. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217902 > > [2] http://cr.openjdk.java.net/~herrick/8217902/webrev.01/ > > > /ANdy > From alexander.matveev at oracle.com Thu Feb 28 00:56:56 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 27 Feb 2019 16:56:56 -0800 Subject: RFR: JDK-8217902: jpackage fails with --app-image option on mac In-Reply-To: <16396d65-146c-0f99-fd42-a4e8428ce353@oracle.com> References: <8540cf7b-ce07-e827-54c1-80f1cfa86959@oracle.com> <16396d65-146c-0f99-fd42-a4e8428ce353@oracle.com> Message-ID: <4f0ccd39-66b5-d7bc-61cd-771c7200f332@oracle.com> Hi Andy, Revised webrev looks good. Thanks, Alexander On 2/27/2019 4:41 PM, Andy Herrick wrote: > revised webrev at http://cr.openjdk.java.net/~herrick/8217902/webrev.02/ > > Do not Log a verbose message when cfg not found in getAppName() - just > use APP_NAME parameter as is done on Linux and Mac > > /Andy > > On 2/26/2019 8:15 AM, Andy Herrick wrote: >> ?JDK-8217902: jpackage fails with --app-image option on mac >> >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> The fix is to remove the over-aggressive validation in >> DeployParams.validate() and update WinAppBundler to be the same as >> Mac code. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217902 >> >> [2] http://cr.openjdk.java.net/~herrick/8217902/webrev.01/ >> >> >> /ANdy >> > From augustnagro at gmail.com Thu Feb 28 04:38:40 2019 From: augustnagro at gmail.com (August Nagro) Date: Wed, 27 Feb 2019 22:38:40 -0600 Subject: Proposal to enhance Stream.collect In-Reply-To: References: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> Message-ID: Tagir, Great to see the validating benchmarks. > I think it's the best solution given the fact that very few collectors may benefit from the exact known size, and this benefit usually disappears when collectors are composed (e.g. using groupingBy: downstream toList() would not win anything if it provides a sizedSupplier). I would like to see your benchmarks for that statement too. After all, Hashmap, HashSet, etc all have presizing constructors, aren't those there for a reason? So I am still convinced that presizing is important for other collector types, including custom collectors. Although I'm open to having my mind changed. I'm happy to contribute an implementation as well, I was hoping that this this (smallish) patch would help me learn the OpenJdk process and make future contributions easier! - August On Wed, Feb 27, 2019 at 1:06 AM Tagir Valeev wrote: > Hello! > > > A less intrusive API direction might be a version of Collector whose > > supplier function took a size-estimate argument; this might even help in > > parallel since it allows for intermediate results to start with a better > > initial size guess. (And this could be implemented as a default that > > delegates to the existing supplier.) Still, not really sure this > > carries its weight. > > It's interesting that such optimization is possible without API > change, using the "hidden knowledge". > While public API stays the same, the collect method implementation may > check if custom > non-public Collector implementation is supplied, and in this case may > use the sized supplier. > I think it's the best solution given the fact that very few collectors > may benefit from the exact > known size, and this benefit usually disappears when collectors are > composed (e.g. using groupingBy: > downstream toList() would not win anything if it provides a sizedSupplier). > > I created a quick patch and launched a quick benchmark like this: > return new SplittableRandom(0).ints(length, 0, > 100).boxed().collect(Collectors.toList()); > For length = 100, 10000, 1000000 > > Here's results for vanilla 13-ea+8: > length = 100, avg time = 1434,469 ? 27,147 ns/op, alloc rate = 1712 B/op > length = 10000, avg time = 155032,390 ? 2657,927 ns/op, alloc rate = > 169280 B/op > length = 1000000, avg time = 27099621,763 ? 1979054,500 ns/op, alloc > rate = 14586750 B/op > > Patched: > length = 100, avg time = 1414,480 ? 30,040 ns/op, alloc rate = 768 B/op > length = 10000, avg time = 137338,320 ? 1316,789 ns/op, alloc rate = > 40368 B/op > length = 1000000, avg time = 17654635,871 ? 210607,441 ns/op, alloc > rate = 4000382 B/op > > As you can see, exact allocation really helps to reduce alloc pressure > and produces better performance for big lists. > > If such kind of patch is acceptable for Stream API, I can file a > ticket and submit a webrev. > > With best regards, > Tagir Valeev > > The patch follows: > > --- src/java.base/share/classes/java/util/stream/Collectors.java > (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) > +++ src/java.base/share/classes/java/util/stream/Collectors.java > (revision 53626+:e2fc434b410a+) > @@ -50,6 +50,7 @@ > import java.util.function.BinaryOperator; > import java.util.function.Consumer; > import java.util.function.Function; > +import java.util.function.IntFunction; > import java.util.function.Predicate; > import java.util.function.Supplier; > import java.util.function.ToDoubleFunction; > @@ -194,23 +195,34 @@ > */ > static class CollectorImpl implements Collector { > private final Supplier supplier; > + private final IntFunction sizedSupplier; > private final BiConsumer accumulator; > private final BinaryOperator combiner; > private final Function finisher; > private final Set characteristics; > > CollectorImpl(Supplier supplier, > + IntFunction sizedSupplier, > BiConsumer accumulator, > BinaryOperator combiner, > Function finisher, > Set characteristics) { > this.supplier = supplier; > + this.sizedSupplier = sizedSupplier; > this.accumulator = accumulator; > this.combiner = combiner; > this.finisher = finisher; > this.characteristics = characteristics; > } > > + CollectorImpl(Supplier supplier, > + BiConsumer accumulator, > + BinaryOperator combiner, > + Function finisher, > + Set characteristics) { > + this(supplier, null, accumulator, combiner, finisher, > characteristics); > + } > + > CollectorImpl(Supplier supplier, > BiConsumer accumulator, > BinaryOperator combiner, > @@ -228,6 +240,10 @@ > return supplier; > } > > + IntFunction sizedSupplier() { > + return sizedSupplier; > + } > + > @Override > public BinaryOperator combiner() { > return combiner; > @@ -275,8 +291,11 @@ > */ > public static > Collector> toList() { > - return new CollectorImpl<>((Supplier>) > ArrayList::new, List::add, > + return new CollectorImpl<>((Supplier>) ArrayList::new, > + ArrayList::new, > + List::add, > (left, right) -> { > left.addAll(right); return left; }, > + castingIdentity(), > CH_ID); > } > > Index: src/java.base/share/classes/java/util/stream/ReduceOps.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- src/java.base/share/classes/java/util/stream/ReduceOps.java > (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) > +++ src/java.base/share/classes/java/util/stream/ReduceOps.java > (revision 53626+:e2fc434b410a+) > @@ -36,6 +36,7 @@ > import java.util.function.BinaryOperator; > import java.util.function.DoubleBinaryOperator; > import java.util.function.IntBinaryOperator; > +import java.util.function.IntFunction; > import java.util.function.LongBinaryOperator; > import java.util.function.ObjDoubleConsumer; > import java.util.function.ObjIntConsumer; > @@ -155,13 +156,20 @@ > public static TerminalOp > makeRef(Collector collector) { > Supplier supplier = > Objects.requireNonNull(collector).supplier(); > + @SuppressWarnings("unchecked") > + IntFunction sizedSupplier = collector instanceof > Collectors.CollectorImpl ? > + ((Collectors.CollectorImpl) > collector).sizedSupplier() : null; > BiConsumer accumulator = collector.accumulator(); > BinaryOperator combiner = collector.combiner(); > class ReducingSink extends Box > implements AccumulatingSink { > @Override > public void begin(long size) { > - state = supplier.get(); > + if (sizedSupplier != null && size >= 0 && size <= > Integer.MAX_VALUE) { > + state = sizedSupplier.apply((int) size); > + } else { > + state = supplier.get(); > + } > } > > @Override > From amaembo at gmail.com Thu Feb 28 06:55:52 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 28 Feb 2019 13:55:52 +0700 Subject: Proposal to enhance Stream.collect In-Reply-To: References: <523ce108-4ce6-5fca-5ade-95d622a14e20@oracle.com> Message-ID: Hello! I wouldn't use presized HashSet, because you never know how many duplicates are expected. What if the input stream has a million of elements, but only two of them are distinct? Do you really want to allocate a hash table for million elements in advance? For toMap() without custom supplier and merger preallocation sounds reasonable as in this case duplicating key is an exceptional case, so we may expect a specific number of elements. ??, 28 ????. 2019 ?., 11:38 August Nagro augustnagro at gmail.com: > Tagir, > > Great to see the validating benchmarks. > > > I think it's the best solution given the fact that very few collectors may > benefit from the exact known size, and this benefit usually disappears > when collectors are composed (e.g. using groupingBy: downstream toList() > would not win anything if it provides a sizedSupplier). > > I would like to see your benchmarks for that statement too. After all, > Hashmap, HashSet, etc all have presizing constructors, aren't those there > for a reason? > > So I am still convinced that presizing is important for other collector > types, including custom collectors. Although I'm open to having my mind > changed. > > I'm happy to contribute an implementation as well, I was hoping that > this this (smallish) patch would help me learn the OpenJdk process and make > future contributions easier! > > - August > > On Wed, Feb 27, 2019 at 1:06 AM Tagir Valeev wrote: > >> Hello! >> >> > A less intrusive API direction might be a version of Collector whose >> > supplier function took a size-estimate argument; this might even help in >> > parallel since it allows for intermediate results to start with a better >> > initial size guess. (And this could be implemented as a default that >> > delegates to the existing supplier.) Still, not really sure this >> > carries its weight. >> >> It's interesting that such optimization is possible without API >> change, using the "hidden knowledge". >> While public API stays the same, the collect method implementation may >> check if custom >> non-public Collector implementation is supplied, and in this case may >> use the sized supplier. >> I think it's the best solution given the fact that very few collectors >> may benefit from the exact >> known size, and this benefit usually disappears when collectors are >> composed (e.g. using groupingBy: >> downstream toList() would not win anything if it provides a >> sizedSupplier). >> >> I created a quick patch and launched a quick benchmark like this: >> return new SplittableRandom(0).ints(length, 0, >> 100).boxed().collect(Collectors.toList()); >> For length = 100, 10000, 1000000 >> >> Here's results for vanilla 13-ea+8: >> length = 100, avg time = 1434,469 ? 27,147 ns/op, alloc rate = 1712 B/op >> length = 10000, avg time = 155032,390 ? 2657,927 ns/op, alloc rate = >> 169280 B/op >> length = 1000000, avg time = 27099621,763 ? 1979054,500 ns/op, alloc >> rate = 14586750 B/op >> >> Patched: >> length = 100, avg time = 1414,480 ? 30,040 ns/op, alloc rate = 768 B/op >> length = 10000, avg time = 137338,320 ? 1316,789 ns/op, alloc rate = >> 40368 B/op >> length = 1000000, avg time = 17654635,871 ? 210607,441 ns/op, alloc >> rate = 4000382 B/op >> >> As you can see, exact allocation really helps to reduce alloc pressure >> and produces better performance for big lists. >> >> If such kind of patch is acceptable for Stream API, I can file a >> ticket and submit a webrev. >> >> With best regards, >> Tagir Valeev >> >> The patch follows: >> >> --- src/java.base/share/classes/java/util/stream/Collectors.java >> (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) >> +++ src/java.base/share/classes/java/util/stream/Collectors.java >> (revision 53626+:e2fc434b410a+) >> @@ -50,6 +50,7 @@ >> import java.util.function.BinaryOperator; >> import java.util.function.Consumer; >> import java.util.function.Function; >> +import java.util.function.IntFunction; >> import java.util.function.Predicate; >> import java.util.function.Supplier; >> import java.util.function.ToDoubleFunction; >> @@ -194,23 +195,34 @@ >> */ >> static class CollectorImpl implements Collector { >> private final Supplier supplier; >> + private final IntFunction sizedSupplier; >> private final BiConsumer accumulator; >> private final BinaryOperator combiner; >> private final Function finisher; >> private final Set characteristics; >> >> CollectorImpl(Supplier supplier, >> + IntFunction sizedSupplier, >> BiConsumer accumulator, >> BinaryOperator combiner, >> Function finisher, >> Set characteristics) { >> this.supplier = supplier; >> + this.sizedSupplier = sizedSupplier; >> this.accumulator = accumulator; >> this.combiner = combiner; >> this.finisher = finisher; >> this.characteristics = characteristics; >> } >> >> + CollectorImpl(Supplier supplier, >> + BiConsumer accumulator, >> + BinaryOperator combiner, >> + Function finisher, >> + Set characteristics) { >> + this(supplier, null, accumulator, combiner, finisher, >> characteristics); >> + } >> + >> CollectorImpl(Supplier supplier, >> BiConsumer accumulator, >> BinaryOperator combiner, >> @@ -228,6 +240,10 @@ >> return supplier; >> } >> >> + IntFunction sizedSupplier() { >> + return sizedSupplier; >> + } >> + >> @Override >> public BinaryOperator combiner() { >> return combiner; >> @@ -275,8 +291,11 @@ >> */ >> public static >> Collector> toList() { >> - return new CollectorImpl<>((Supplier>) >> ArrayList::new, List::add, >> + return new CollectorImpl<>((Supplier>) ArrayList::new, >> + ArrayList::new, >> + List::add, >> (left, right) -> { >> left.addAll(right); return left; }, >> + castingIdentity(), >> CH_ID); >> } >> >> Index: src/java.base/share/classes/java/util/stream/ReduceOps.java >> IDEA additional info: >> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >> <+>UTF-8 >> =================================================================== >> --- src/java.base/share/classes/java/util/stream/ReduceOps.java >> (revision 53626:e2fc434b410a35b28ab433c29863c8a26e4e813a) >> +++ src/java.base/share/classes/java/util/stream/ReduceOps.java >> (revision 53626+:e2fc434b410a+) >> @@ -36,6 +36,7 @@ >> import java.util.function.BinaryOperator; >> import java.util.function.DoubleBinaryOperator; >> import java.util.function.IntBinaryOperator; >> +import java.util.function.IntFunction; >> import java.util.function.LongBinaryOperator; >> import java.util.function.ObjDoubleConsumer; >> import java.util.function.ObjIntConsumer; >> @@ -155,13 +156,20 @@ >> public static TerminalOp >> makeRef(Collector collector) { >> Supplier supplier = >> Objects.requireNonNull(collector).supplier(); >> + @SuppressWarnings("unchecked") >> + IntFunction sizedSupplier = collector instanceof >> Collectors.CollectorImpl ? >> + ((Collectors.CollectorImpl) >> collector).sizedSupplier() : null; >> BiConsumer accumulator = collector.accumulator(); >> BinaryOperator combiner = collector.combiner(); >> class ReducingSink extends Box >> implements AccumulatingSink { >> @Override >> public void begin(long size) { >> - state = supplier.get(); >> + if (sizedSupplier != null && size >= 0 && size <= >> Integer.MAX_VALUE) { >> + state = sizedSupplier.apply((int) size); >> + } else { >> + state = supplier.get(); >> + } >> } >> >> @Override >> > From ecki at zusammenkunft.net Thu Feb 28 08:56:25 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 28 Feb 2019 08:56:25 +0000 Subject: "java.lang.Error: Probable fatal error:No fonts found" does not show on 11 In-Reply-To: <5C772127.9090706@oracle.com> References: <5c771cab.1c69fb81.bd016.d65b@mx.google.com>,<5C772127.9090706@oracle.com> Message-ID: Hello, I can confirm the same ugly error stack with 12-b33 EA, this time with debug: $ jdk-12/bin/java -cp . -Dsun.java2d.debugfonts=true FontTest Are we headless? true g = sun.java2d.HeadlessGraphicsEnvironment headless: true Feb 28, 2019 9:50:32 AM sun.awt.X11FontManager registerFontDir INFO: ParseFontDir /home/vagrant/jdk-12/lib/fonts Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration INFO: Creating standard Font Configuration Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findFontConfigFile INFO: Did not find a fontconfig file. Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration INFO: Creating standard Font Configuration Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findFontConfigFile INFO: Did not find a fontconfig file. Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for sans:regular:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for sans:bold:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for sans:regular:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for sans:bold:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for serif:regular:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for serif:bold:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for serif:regular:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for serif:bold:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:regular:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:bold:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:regular:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:bold:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no fonts at all. Feb 28, 2019 9:50:32 AM sun.font.FcFontConfiguration warning WARNING: Failed to get info from libfontconfig Feb 28, 2019 9:50:32 AM sun.font.FcFontConfiguration warning WARNING: Failed to get info from libfontconfig Exception in thread "main" java.lang.InternalError: java.lang.reflect.InvocationTargetException at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86) at java.base/java.security.AccessController.doPrivileged(AccessController.java:310) at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189) at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223) at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251) at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Philip Race Gesendet: Donnerstag, Februar 28, 2019 12:45 AM An: Bernd Eckenfels; 2d-dev Cc: awt-dev at openjdk.java.net; Java Core Libs Betreff: Re: "java.lang.Error: Probable fatal error:No fonts found" does not show on 11 Wrong list. You want 2d-dev. -phil. On 2/27/19, 3:26 PM, Bernd Eckenfels wrote: > Hello, > > (please let me know in case I picked the wrong list.) > > Since OpenJDK does not ship Default *.ttf font files the change that a JRE is installed in a way that no System Fonts can be found is quite high. > > In OpenJDK8 it is a bit unfortunate that in this situation even for the headless graphics context that you can can a Java.lang.Error: > > I wonder if this is intentional. How About returnign an empty Array or Maybe a RntimeException instead? In my case by upgrading from Oracle JRE to Open JDK (in my case Azul) a perfectly fine working Installation is not aborting. > > The JasperReports component used is failing does not even need the System Fonts (which I will report to them seperately). For Zulu it is enough to install Dejavu Fonts in System Directory or copy them to JRE/lib/fonts/, but I have also seen OpenJDK builds which seem to use fontmanager libraries instead of fixed file path. Here I guess the dependency on System config is even higher. > > I tested on a minimal System with no X11: > >> ls /usr/share/fonts >> cat /etc/centos-release > CentOS Linux release 7.3.1611 (Core) > > And my test program (below) Returns for Java 8: > >> zulu8*x64/bin/java -cp . FontTest > Are we headless? true > g = sun.java2d.HeadlessGraphicsEnvironment headless: true > Exception in thread "main" java.lang.Error: Probable fatal error:No fonts found. > at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1236) > at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) > ? > at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1220) > at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) > at sun.font.SunFontManager.initialiseDeferredFonts(SunFontManager.java:927) > at sun.font.SunFontManager.loadFonts(SunFontManager.java:3302) > at sun.awt.X11FontManager.loadFonts(X11FontManager.java:466) > at sun.font.SunFontManager.loadFontFiles(SunFontManager.java:3429) > at sun.font.SunFontManager.getInstalledFontFamilyNames(SunFontManager.java:3766) > at sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:225) > at sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:252) > at sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:94) > at FontTest.main(FontTest.java:15) > > So the error in itself is one topic I wanted to inquire About. However, even worse in OpenJDK 11 the error seems to have degenerated quite a bit, it Looks for me: > >> zulu11*x64/bin/java -cp . FontTest > Are we headless? true > g = sun.java2d.HeadlessGraphicsEnvironment headless: true > Exception in thread "main" java.lang.InternalError: java.lang.reflect.InvocationTargetException > at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) > at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189) > at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223) > at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251) > at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75) > at FontTest.main(FontTest.java:15) > Caused by: java.lang.reflect.InvocationTargetException > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:84) > ... 7 more > Caused by: java.lang.NullPointerException > at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1262) > at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225) > at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107) > at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:719) > at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:367) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.desktop/sun.font.SunFontManager.(SunFontManager.java:312) > at java.desktop/sun.awt.FcFontManager.(FcFontManager.java:35) > at java.desktop/sun.awt.X11FontManager.(X11FontManager.java:56) > ... 12 mor > > If there is no known issue for that, is it worth to file a Bug for it? (I Need to recreate it with a Oracle OpenJDK binary yet if it is only a fontconfig Problem ? but in that case a null check is probably also a good thing?) > > Gruss > Bernd From deepak.kejriwal at oracle.com Thu Feb 28 11:12:55 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Thu, 28 Feb 2019 03:12:55 -0800 (PST) Subject: [8u-dev] Request for Approval: Backport of JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 Message-ID: <93782021-9223-428c-93d6-63d314c2d7ad@default> Hi All, Please approve the backport of following bugs to 8u-dev. JDK-8202088 : Japanese new era implementation JDK-8207152 : Placeholder for Japanese new era should be two characters JDK-8211398 : Square character support for the Japanese new era JDK-8180469 : Wrong short form text for supplemental Japanese era JDK-8206120 : Add test cases for lenient Japanese era parsing JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points JDK-8217710 : Add 5 currency code points to Java SE 8uX JDK Review Thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058595.html All the related testing is done and is a pass. Regards, Deepak From hohensee at amazon.com Thu Feb 28 12:04:07 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 28 Feb 2019 12:04:07 +0000 Subject: [8u-dev] Request for Approval: Backport of JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710 In-Reply-To: <93782021-9223-428c-93d6-63d314c2d7ad@default> References: <93782021-9223-428c-93d6-63d314c2d7ad@default> Message-ID: I added the 'jdk8u-fix-request' tag to these issues. Paul ?On 2/28/19, 3:13 AM, "core-libs-dev on behalf of Deepak Kejriwal" wrote: Hi All, Please approve the backport of following bugs to 8u-dev. JDK-8202088 : Japanese new era implementation JDK-8207152 : Placeholder for Japanese new era should be two characters JDK-8211398 : Square character support for the Japanese new era JDK-8180469 : Wrong short form text for supplemental Japanese era JDK-8206120 : Add test cases for lenient Japanese era parsing JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points JDK-8217710 : Add 5 currency code points to Java SE 8uX JDK Review Thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058595.html All the related testing is done and is a pass. Regards, Deepak From dkwakkel at gmail.com Thu Feb 28 16:41:41 2019 From: dkwakkel at gmail.com (Donald Kwakkel) Date: Thu, 28 Feb 2019 17:41:41 +0100 Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs Message-ID: a Hi All, This is my first contribution to openjdk, so hope to learn a lot! I first posted this to compiler-dev, but they explained that I better can discuss this first on this list. I created a fix + tests for https://bugs.openjdk.java.net/browse/JDK-8218268 (I will rewrite the test to java using langtools, but added them below to get an idea what they do). Now the manifest classpath is behaving the same in javac and java for file paths as it was in java 8. See at the end of this mail the patch. So this fixes: 1. The Java Compiler treats the entries as URLs, according to spec: https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#class-path-attribute 2. The behavior of the JVM ClassLoader and the Java Compiler is equal (for file urls) 3. The behavior is backwards compatible (it was broken in javac 9-13) Now I understood from these links that class-path attribute has become more strict, and fallback to old behaviour is provided: [1] https://bugs.openjdk.java.net/browse/JDK-8217215 [2] https://bugs.openjdk.java.net/browse/JDK-8216401 Question 1: Where can I find the tests for these changes? These fixes seems already been committed, but javac has not been taken along. In my opinion it would be best if the new behaviour can be used both in javac and java (maybe with same properties). Question 2: Do you agree? And if so where should this code be located? (I am not in java 11 modules yet) Now is 8218268 about breaking of manifest classpath attribute in javac between java 8 => 9. I would like that this is asap fixed in e.g. java 11 because I depend on this behaviour. Question 3: Is it an idea to first implement below patch and backport that, and in addition as new ticket implement the new behaviour also for javac? The current patch contains a System.err because I do not know how to (debug) log information in the jdk. I saw for java they used a property and then write to System.err. Question 4:Is this they way to do it, or is there a better way to provide debug information to users running javac? Kind Regards, Donald Kwakkel ps: Looking forward for a sponsor to adopt/work on my change! diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java @@ -26,7 +26,10 @@ package com.sun.tools.javac.file; import java.io.IOException; -import java.nio.file.FileSystems; +import java.net.MalformedURLException; +import java.net.URI; +import java.net.URISyntaxException; +import java.net.URL; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.spi.FileSystemProvider; @@ -90,7 +93,6 @@ } public List getJarClassPath(Path file) throws IOException { - Path parent = file.getParent(); try (JarFile jarFile = new JarFile(file.toFile())) { Manifest man = jarFile.getManifest(); if (man == null) @@ -100,22 +102,27 @@ if (attr == null) return Collections.emptyList(); - String path = attr.getValue(Attributes.Name.CLASS_PATH); - if (path == null) + String classpath = attr.getValue(Attributes.Name.CLASS_PATH); + if (classpath == null) return Collections.emptyList(); - List list = new ArrayList<>(); + // TODO: Must use the same code as jdk.internal.loader.URLClassPath.JarLoader.parseClassPath(base, path) + StringTokenizer st = new StringTokenizer(classpath); + List paths = new ArrayList<>(st.countTokens()); + while (st.hasMoreTokens()) { + String path = st.nextToken(); + try { + // Use getCanonicalFile just as jdk.internal.loader.URLClassPath.toFileURL + URL base = file.toFile().getCanonicalFile().toURI().toURL(); + URI uri = new URL(base, path).toURI(); - for (StringTokenizer st = new StringTokenizer(path); - st.hasMoreTokens(); ) { - String elt = st.nextToken(); - Path f = FileSystems.getDefault().getPath(elt); - if (!f.isAbsolute() && parent != null) - f = parent.resolve(f).toAbsolutePath(); - list.add(f); + // Should return uri, see comment on com.sun.tools.javac.file.Locations.SearchPath.addJarClassPath + paths.add(Path.of(uri)); + } catch (MalformedURLException | URISyntaxException e) { + System.err.println("Class-Path entry: \"" + path + "\" ignored in JAR file \"" + file + "\": " + e.getMessage()); + } } - - return list; + return paths; } } diff --git a/test/langtools/tools/javac/Paths/UrlClassPath.sh b/test/langtools/tools/javac/Paths/UrlClassPath.sh new file mode 100755 --- /dev/null +++ b/test/langtools/tools/javac/Paths/UrlClassPath.sh @@ -0,0 +1,112 @@ +#!/bin/sh +# +# Copyright (c) 2011, Oracle and/or its affiliates. All rights reserved. +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. +# +# This code is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License version 2 only, as +# published by the Free Software Foundation. +# +# This code is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +# version 2 for more details (a copy is included in the LICENSE file that +# accompanied this code). +# +# You should have received a copy of the GNU General Public License version +# 2 along with this work; if not, write to the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +# +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA +# or visit www.oracle.com if you need additional information or have any +# questions. +# + +# @test +# @bug 8218268 +# @summary Test handling of urls (with spaces) in the Class-Path attribute in jar file manifests +# @author Donald Kwakkel +# +# @run shell UrlClassPath.sh + +# To run this test manually, simply do ./UrlClassPath.sh + +. ${TESTSRC-.}/Util.sh + +set -u + +Cleanup() { + Sys rm -rf "x y" z Hello.java Hello.class Main.java Main.class MANIFEST.MF hellocp.jar +} + +Cleanup +Sys mkdir "x y" + +#---------------------------------------------------------------- +# Create mutually referential jar files +#---------------------------------------------------------------- +cat >Hello.java <Main.java < References: <1550266210.2497.16.camel@paratix.ch> Message-ID: <851D742E-0BEE-4022-98F6-CD8A9484A8C6@oracle.com> Hi Philipp, Thank you for looking into this issue and proposing a fix. I ran the JCK and encountered 9 failures similar to the JavaClassPathTest failure. The JCK tests that I looked at did not validate all of the attributes which is one of the reasons this was not caught earlier Given the fact that this code dates back to JDK 1.1/2 and with this fix, an Exception is now encountered I am reluctant to integrate the patch as is into the JDK as I think there is a compatibility risk that I am not comfortable with. I believe the best course of action is to look to develop additional tests in this area and we look to further clarify the JAR specification. Best Lance > On Feb 15, 2019, at 4:30 PM, Philipp Kunz wrote: > > Hi, > > Manifest parsing an input stream given to the constructor or the read > method ignores the contents of the last line unless terminated with a > line break. > > In course of my attempt to fix 8217375, I found that Manifest ignores > the last line when not terminated with a line break whereas > ManifestDigester throws an exception. > Without ManifestDigester's different behavior, I'd have opted for > parsing the last line also without a line break (or the last line being > empty). > But ManifestDigester cannot easily be changed that way, too, because > the line breaks are part of the digested manifest portions. > I don't think Manifest should accept any manifests that cannot later as > well be signed and should therefore raise an error when there is no > line break at the end of a manifest. > Adding a new error condition adds potential for compatibility issues. > On the other hand, I don't think the last 'ill'-terminated line should > really be ignored silently. > A good example how things can go wrong this way is > JavaClassPathTest.java. It uses a one-line manifest without a trailing > line break and m1.jar does not contain the expected Class-Path entry. > In the long term the best option would probably be to re-unite > Manifest's and ManifestDigester's parsing-related code the biggest > challenge of which is not to change digests and thereby break existing > jar signatures. > > Attached is a patch with a proposed fix. > > The bug number in > test/jdk/java/util/jar/Manifest/NoLineBreakAtEndOfManifestFile.java is > from another bug that lead me to it. If someone creates another bug it > can be replaced. I haven't found an existing issue that matches. > In test/jdk/tools/launcher/modules/classpath/JavaClassPathTest.java is > a test case testJARManifestClassPathAttribute/testClassPathAttribute > which I have no clue how this should really work. As far as I can tell > the test is and was wrong but nevertheless passes. > > Is there a chance to find a sponsor for fixing this? > > Regards, > Philipp 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 jonathan.gibbons at oracle.com Thu Feb 28 20:58:26 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 28 Feb 2019 12:58:26 -0800 Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: References: Message-ID: Looking at the revised JAR specification, approved in [1], it is disappointing that the spec contains text which is specific to a JAR file being used in a classloader: |The resulting URLs are inserted into the search path of the class loader opening the context JAR immediately following the path of the context JAR. Any duplicated URLs are omitted.| That text would seem not to apply to javac and other tools that may wish to process the class files in a JAR file. -- Jon https://bugs.openjdk.java.net/browse/JDK-8217215 On 02/28/2019 08:41 AM, Donald Kwakkel wrote: > a > Hi All, > > This is my first contribution to openjdk, so hope to learn a lot! > > I first posted this to compiler-dev, but they explained that I better > can discuss this first on this list. > > I created a fix + tests for > https://bugs.openjdk.java.net/browse/JDK-8218268 (I will rewrite the > test to java using langtools, but added them below to get an idea what > they do). > Now the manifest classpath is behaving the same in javac and java for > file paths as it was in java 8. See at the end of this mail the patch. > > So this fixes: > 1. The Java Compiler treats the entries as URLs, according to spec: > https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#class-path-attribute > 2. The behavior of the JVM ClassLoader and the Java Compiler is equal > (for file urls) > 3. The behavior is backwards compatible (it was broken in javac 9-13) > > Now I understood from these links that class-path attribute has become > more strict, > and fallback to old behaviour is provided: > [1] https://bugs.openjdk.java.net/browse/JDK-8217215 > [2] https://bugs.openjdk.java.net/browse/JDK-8216401 > > Question 1: Where can I find the tests for these changes? > > These fixes seems already been committed, but javac has not been taken along. > In my opinion it would be best if the new behaviour can be used both > in javac and java (maybe with same properties). > > Question 2: Do you agree? And if so where should this code be located? > (I am not in java 11 modules yet) > > Now is 8218268 about breaking of manifest classpath attribute in javac > between java 8 => 9. > I would like that this is asap fixed in e.g. java 11 because I depend > on this behaviour. > > Question 3: Is it an idea to first implement below patch and backport > that, and in addition as new ticket implement the new behaviour also > for javac? > > The current patch contains a System.err because I do not know how to > (debug) log information in the jdk. I saw for java they used a > property and then write to System.err. > > Question 4:Is this they way to do it, or is there a better way to > provide debug information to users running javac? > > Kind Regards, Donald Kwakkel > > ps: Looking forward for a sponsor to adopt/work on my change! > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java > @@ -26,7 +26,10 @@ > package com.sun.tools.javac.file; > > import java.io.IOException; > -import java.nio.file.FileSystems; > +import java.net.MalformedURLException; > +import java.net.URI; > +import java.net.URISyntaxException; > +import java.net.URL; > import java.nio.file.Files; > import java.nio.file.Path; > import java.nio.file.spi.FileSystemProvider; > @@ -90,7 +93,6 @@ > } > > public List getJarClassPath(Path file) throws IOException { > - Path parent = file.getParent(); > try (JarFile jarFile = new JarFile(file.toFile())) { > Manifest man = jarFile.getManifest(); > if (man == null) > @@ -100,22 +102,27 @@ > if (attr == null) > return Collections.emptyList(); > > - String path = attr.getValue(Attributes.Name.CLASS_PATH); > - if (path == null) > + String classpath = attr.getValue(Attributes.Name.CLASS_PATH); > + if (classpath == null) > return Collections.emptyList(); > > - List list = new ArrayList<>(); > + // TODO: Must use the same code as > jdk.internal.loader.URLClassPath.JarLoader.parseClassPath(base, path) > + StringTokenizer st = new StringTokenizer(classpath); > + List paths = new ArrayList<>(st.countTokens()); > + while (st.hasMoreTokens()) { > + String path = st.nextToken(); > + try { > + // Use getCanonicalFile just as > jdk.internal.loader.URLClassPath.toFileURL > + URL base = > file.toFile().getCanonicalFile().toURI().toURL(); > + URI uri = new URL(base, path).toURI(); > > - for (StringTokenizer st = new StringTokenizer(path); > - st.hasMoreTokens(); ) { > - String elt = st.nextToken(); > - Path f = FileSystems.getDefault().getPath(elt); > - if (!f.isAbsolute() && parent != null) > - f = parent.resolve(f).toAbsolutePath(); > - list.add(f); > + // Should return uri, see comment on > com.sun.tools.javac.file.Locations.SearchPath.addJarClassPath > + paths.add(Path.of(uri)); > + } catch (MalformedURLException | URISyntaxException e) { > + System.err.println("Class-Path entry: \"" + path > + "\" ignored in JAR file \"" + file + "\": " + e.getMessage()); > + } > } > - > - return list; > + return paths; > } > } > > diff --git a/test/langtools/tools/javac/Paths/UrlClassPath.sh > b/test/langtools/tools/javac/Paths/UrlClassPath.sh > new file mode 100755 > --- /dev/null > +++ b/test/langtools/tools/javac/Paths/UrlClassPath.sh > @@ -0,0 +1,112 @@ > +#!/bin/sh > +# > +# Copyright (c) 2011, Oracle and/or its affiliates. All rights reserved. > +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > +# > +# This code is free software; you can redistribute it and/or modify it > +# under the terms of the GNU General Public License version 2 only, as > +# published by the Free Software Foundation. > +# > +# This code is distributed in the hope that it will be useful, but WITHOUT > +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > +# version 2 for more details (a copy is included in the LICENSE file that > +# accompanied this code). > +# > +# You should have received a copy of the GNU General Public License version > +# 2 along with this work; if not, write to the Free Software Foundation, > +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > +# > +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > +# or visit www.oracle.com if you need additional information or have any > +# questions. > +# > + > +# @test > +# @bug 8218268 > +# @summary Test handling of urls (with spaces) in the Class-Path > attribute in jar file manifests > +# @author Donald Kwakkel > +# > +# @run shell UrlClassPath.sh > + > +# To run this test manually, simply do ./UrlClassPath.sh > + > +. ${TESTSRC-.}/Util.sh > + > +set -u > + > +Cleanup() { > + Sys rm -rf "x y" z Hello.java Hello.class Main.java Main.class > MANIFEST.MF hellocp.jar > +} > + > +Cleanup > +Sys mkdir "x y" > + > +#---------------------------------------------------------------- > +# Create mutually referential jar files > +#---------------------------------------------------------------- > +cat >Hello.java < +public class Hello { > + public static String hello() { > + return "hello"; > + } > +} > +EOF > + > +cat >Main.java < +public class Main { > + public static void main(String[] args) { > + System.out.println(Hello.hello()); > + } > +} > +EOF > + > +Sys "$javac" Hello.java > +Sys "$jar" cf "x y/hello.jar" Hello.class > +Sys rm -rf Hello.class Hello.java > + > +createManifestJar() { > + MkManifestWithClassPath "${1}" > + Sys "$jar" cmf MANIFEST.MF "${2}" > +} > + > +runJava() { > + Success "$javac" ${TESTTOOLVMOPTS} -cp ".:${1}" Main.java > + # Bug: jdk.net.URLClassPath.disableClassPathURLCheck meaning is > inverted and should be default enabled according to spec > + Success "$java" ${TESTVMOPTS} > -Djdk.net.URLClassPath.disableClassPathURLCheck=false -cp ".:${1}" > Main > +} > + > +doTest() { > + createManifestJar "${1}" hellocp.jar > + runJava "${2}" > +} > + > +# Test 1: Compiling and run with directly adding classpath with space > +doTest "x%20y/hello.jar" "x y/hello.jar" > + > +# Test 2: Compiling and run with adding classpath with space via manifest > +doTest "x%20y/hello.jar" "hellocp.jar" > + > +# Test 3: classpath with file url path > +doTest "file:"`pwd`"/x%20y/hello.jar" "hellocp.jar" > + > +# Test 4: classpath with file uri path > +doTest "file://"`pwd`"/x%20y/hello.jar" "hellocp.jar" > + > +# Test 5: garbage before, right jar must still be used > +doTest "notexisting://garbage x%20y/hello.jar" "hellocp.jar" > + > +# Test 6: linked jar > +Sys mkdir "z" > +createManifestJar "x%20y/hello.jar" hellocp.jar > +Sys ln -s ../hellocp.jar z/hellocp.jar > +runJava "z/hellocp.jar" > + > +# Test 7: only garbage, should fail > +createManifestJar "notexisting://garbage" hellocp.jar > +Failure "$javac" ${TESTTOOLVMOPTS} -cp ".:hellocp.jar" Main.java > +Failure "$java" ${TESTVMOPTS} -cp ".:hellocp.jar" Main.java > + > +Cleanup > + > +Bottom Line From Alan.Bateman at oracle.com Thu Feb 28 21:06:13 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Feb 2019 21:06:13 +0000 Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: References: Message-ID: On 28/02/2019 20:58, Jonathan Gibbons wrote: > Looking at the revised JAR specification, approved in [1], it is > disappointing that the spec contains text which is specific to > a JAR file being used in a classloader: > > |The resulting URLs are inserted into the search path of the class > loader opening the context JAR immediately following the path of the > context JAR. Any duplicated URLs are omitted.| > > That text would seem not to apply to javac and other tools that may wish > to process the class files in a JAR file. That should be fixed as it should apply at compile-time too. -Alan From naoto.sato at oracle.com Thu Feb 28 21:15:07 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 28 Feb 2019 13:15:07 -0800 Subject: [13] RFR: 8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales Message-ID: <53771d80-ac68-5a85-846b-3599f45fdb08@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8219890 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8219890/webrev.00/ After the fix for 8217609, some locales return empty string for the display name for the new era. Providing the fallback name from Era instance in such a case. Naoto From lance.andersen at oracle.com Thu Feb 28 21:27:38 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 28 Feb 2019 16:27:38 -0500 Subject: [13] RFR: 8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales In-Reply-To: <53771d80-ac68-5a85-846b-3599f45fdb08@oracle.com> References: <53771d80-ac68-5a85-846b-3599f45fdb08@oracle.com> Message-ID: <90C2C2AD-388C-45C0-9391-6FFF05BC9E54@oracle.com> looks fine Naoto > On Feb 28, 2019, at 4:15 PM, Naoto Sato wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8219890 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8219890/webrev.00/ > > After the fix for 8217609, some locales return empty string for the display name for the new era. Providing the fallback name from Era instance in such a case. > > Naoto 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 jonathan.gibbons at oracle.com Thu Feb 28 21:38:06 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 28 Feb 2019 13:38:06 -0800 Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: References: Message-ID: On 02/28/2019 01:06 PM, Alan Bateman wrote: > On 28/02/2019 20:58, Jonathan Gibbons wrote: >> Looking at the revised JAR specification, approved in [1], it is >> disappointing that the spec contains text which is specific to >> a JAR file being used in a classloader: >> >> |The resulting URLs are inserted into the search path of the class >> loader opening the context JAR immediately following the path of the >> context JAR. Any duplicated URLs are omitted.| >> >> That text would seem not to apply to javac and other tools that may wish >> to process the class files in a JAR file. > That should be fixed as it should apply at compile-time too. > > -Alan |Agreed it might be good to fix it if possible. All the preceding text is good, and can be handled by javac. The only questionable bit is the text "Any duplicated URLs are omitted" which could be moved up a bit in the spec to a new paragraph, and maybe rephrased to use "ignored" instead of "omitted". If that were done, all the stuff about class loaders could be taken as non-normative text. -- Jon |